condition_variable_any不能直接配std::mutex，因其要求锁支持移动语义，而std::mutex禁用移动；正确组合包括shared_mutex（独占模式）、recursive_mutex或自定义BasicLockable锁；wait_for需显式指定chrono单位；必须用谓词循环检查防虚假唤醒；notify应在持有锁时调用以防丢失。
condition_variable_any 为什么不能直接配 std::mutex
它名字里带 any，不是为了让你图省事乱配锁，而是明确要求锁类型必须满足「可迁移」和「可拷贝语义」——std::mutex 不满足。你如果硬写 cv.wait(lock) 配 std::mutex，编译器大概率报错类似：no matching member function for call to 'wait'，因为 std::mutex 的移动构造被删除，condition_variable_any::wait 内部需要临时转移锁所有权。
真正能用的常见组合是：
-
std::shared_mutex（C++17 起）——注意它支持 shared/unique 两种锁定模式，但condition_variable_any::wait只接受独占模式（即lock()或try_lock()），不能传lock_shared()得到的锁 -
std::recursive_mutex——递归锁，适合需多次加同一把锁的场景，但性能略低，且容易掩盖设计问题 - 自定义满足
BasicLockable要求的锁类（比如带日志、超时包装的锁），但要确保 move 构造/赋值可用
wait 和 wait_for 的超时参数单位容易搞反
condition_variable_any::wait_for 第二个参数是 std::chrono::duration，不是毫秒整数。写成 cv.wait_for(lk, 1000) 是错的，它会被当成 1000 个「时钟周期」（通常是纳秒级），实际等待时间趋近于 0，导致忙轮询。
正确写法必须显式指定单位：
立即学习“C++免费学习笔记（深入）”；
cv.wait_for(lk, std::chrono::milliseconds(1000)); // 等 1 秒 cv.wait_for(lk, std::chrono::seconds(5)); // 等 5 秒
另外注意：即使超时，wait_for 返回的是 std::cv_status 枚举，不是布尔值。别写 if (cv.wait_for(...))，应该写：
if (cv.wait_for(lk, std::chrono::milliseconds(500)) == std::cv_status::timeout) {
// 真的超时了
}
虚假唤醒下忘记检查谓词就继续执行
condition_variable_any 不保证唤醒一定对应真实条件变化，系统调度、信号中断都可能触发虚假唤醒。如果你只调用 wait 不带谓词版本，又没在 wait 返回后重新检查状态，就会出逻辑错误。
最稳妥写法永远是带 lambda 谓词的重载：
cv.wait(lk, [&ready] { return ready; });
这个版本内部等价于：
while (!ready) {
cv.wait(lk);
}
而手动展开时容易漏掉 while，只写一次 if，那就危险了。尤其在多生产者、多消费者或涉及多个条件变量协作时，谓词检查缺一不可。
notify_one 和 notify_all 的时机与锁状态
调用 notify_one 或 notify_all 本身不要求持有锁，但强烈建议在**仍持有同一把锁时通知**。原因有两个：
- 避免「通知丢失」：如果通知发生在等待线程进入
wait之前（即先notify后wait），而此时没有锁保护，那个通知就彻底丢弃了；加锁后通知能确保状态更新和通知原子地串在一起 - 减少唤醒后竞争：被唤醒线程需重新获取锁才能继续，若通知方提前释放锁，被唤醒线程会立刻争锁，可能引发不必要的上下文切换
所以典型模式是：
lk.lock(); ready = true; cv.notify_all(); // 在锁内通知 lk.unlock();
或者更简洁地用作用域锁：
{
std::unique_lock<std::shared_mutex> lk(shmtx);
ready = true;
cv.notify_all();
} // 自动 unlock
复杂点在于：condition_variable_any 的灵活性反而容易让人忽略锁类型的约束和谓词的必要性。它不强制你用什么锁，但每换一种锁，就得重新验证 move 语义、锁定模式、以及是否和你的等待逻辑兼容——这点比 condition_variable 更容易踩坑。
