为何std::condition_variable仅能与std::unique_lock配合使用？

• std::condition_variable绑定std::unique_lock<std::mutex>的核心原因：平台原生支持与效率
  多数操作系统的原生条件变量API（比如POSIX标准的pthread_cond_wait）设计时，就要求配合的锁必须支持随时解锁、重新加锁的操作，且解锁/加锁逻辑要和条件变量的等待/唤醒流程精准匹配。std::unique_lock刚好满足这些要求：它既能管理std::mutex的生命周期，还提供独立的lock()、unlock()成员函数，完全贴合原生API的调用逻辑。
  因为不需要额外适配层，直接复用平台原生实现，所以std::condition_variable在这些平台上能达到最高运行效率。

• std::condition_variable_any支持任意BasicLockable的原因：通用抽象与灵活性
  BasicLockable是C++标准定义的极简锁概念，只要实现了lock()和unlock()成员函数的类型都属于这个范畴（比如std::shared_lock、自定义简单锁）。std::condition_variable_any内部做了一层通用包装，不管传入的锁是什么类型，都通过这两个通用接口完成等待前解锁、唤醒后加锁的操作。
  但这种通用性有代价：为适配不同锁的特性，它可能需要额外的内部同步逻辑或包装层，效率通常比std::condition_variable低。不过换来了更灵活的使用场景——比如多读少写场景中，可配合std::shared_lock（共享锁）使用，这是std::condition_variable做不到的。

内容的提问来源于stack exchange，提问作者douyu