std::condition_variable_any能接受任意锁类型，因其仅依赖lock()、unlock()、try_lock()接口，满足lockable概念即可；但锁必须已持有、为同一对象且支持引用传递。
std::condition_variable_any 为什么能接受任意锁类型
它内部不依赖 std::mutex 的特定接口，只调用锁对象的 lock()、unlock() 和 try_lock()（后者仅用于 wait_for/wait_until 的超时路径），所以只要你的锁满足这个“可锁定概念”（Lockable concept），就能传给 wait、wait_for 等成员函数。
典型可用类型包括：std::mutex、std::shared_mutex、std::recursive_mutex，甚至自定义锁（只要实现那三个函数且无异常抛出）。
- 注意：锁对象必须支持拷贝或移动——但实际中你几乎总是传左值引用，所以只需确保它可绑定到
Lock& -
std::condition_variable不行，它硬编码依赖std::mutex::native_handle()和底层 OS 原语，无法泛化 - 别误以为“any”意味着能混用不同锁实例——
wait的锁参数和唤醒前持有的锁必须是同一个对象（或至少语义等价），否则行为未定义
wait() 调用时锁必须已持有，且不能提前释放
这是最常踩的坑：wait 不会帮你加锁，它假设你传入的是一个**已成功上锁**的锁对象；进入等待前，它会原子地释放该锁，并在被唤醒后重新获取它。
错误写法：
立即学习“C++免费学习笔记（深入）”；
std::shared_mutex smtx;
std::condition_variable_any cv;
// ❌ 错误：smtx 未 lock 就传入
cv.wait(smtx, []{ return ready; });
正确做法：
- 显式调用
smtx.lock_shared()或smtx.lock()（取决于你要的锁模式） - 把锁对象（不是锁类型！）以引用方式传给
wait - 确保 lambda 条件检查与锁的粒度匹配——比如用
shared_mutex读锁保护的变量，就不能在wait中用独占锁去读
shared_mutex + condition_variable_any 的典型协作模式
当你需要多个读者等待某个状态，又允许写者更新该状态时，std::shared_mutex 配合 std::condition_variable_any 是比纯 std::mutex 更细粒度的选择。
关键点：
- 读者用
lock_shared()加读锁，调用cv.wait()；此时其他读者仍可进入，但写者会被阻塞 - 写者用
lock()加写锁，修改状态后调用cv.notify_all()（注意：notify 不需要锁，但通常应在锁内完成状态更新和通知，避免丢失唤醒） - 不要在
wait的 lambda 中调用shared_mutex::try_lock()——这会破坏锁层次，且可能死锁 -
wait_for在共享锁下仍安全，但超时返回后锁依然有效，你得自己判断是否重试或退出
性能开销比 std::condition_variable 高，别盲目替换
std::condition_variable_any 的通用性是有代价的：每次 wait 都需做类型擦除（通常是堆分配或小型缓冲区），并多一层虚函数或模板间接调用；而 std::condition_variable 直接映射到 futex 或 Windows Event，零额外开销。
所以：
- 除非你明确需要
shared_mutex、recursive_mutex或自定义锁，否则坚持用std::condition_variable+std::mutex - 高频等待场景（如每微秒都 wait/notify）要实测对比——
any版本可能慢 2–5 倍 - 静态分析工具（如 clang-tidy）可能对
condition_variable_any报告“overly generic”，这不是 bug，但值得确认是否真有必要
真正难处理的从来不是“能不能用”，而是唤醒时机和锁生命周期的耦合——比如 notify 发生在 wait 前，或者锁在 wait 返回后意外被另一个线程释放。这些不会报错，但会让条件变量失效。
