std::condition_variable::wait_for不能直接当“超时锁”用，因其返回cv_status仅表示是否被唤醒，不保证条件满足；必须配合谓词使用，否则易因虚假唤醒导致假成功或资源泄漏。
std::condition_variable::wait_for 为什么不能直接当“超时锁”用
因为 wait_for 返回的是 std::cv_status，不是布尔值；它只表示“是否被唤醒”，不反映条件是否真正满足。常见错误是写成 if (cv.wait_for(lock, 200ms) == std::cv_status::no_timeout) 就认为条件成立——其实可能只是虚假唤醒，pred 根本没通过。
正确做法必须配合谓词（predicate）使用，否则超时逻辑和业务逻辑脱钩：
std::unique_lock<std::mutex> lock(mtx);
if (cv.wait_for(lock, 200ms, [&]{ return ready; })) {
// ready == true，且是被 notify 唤醒的
} else {
// 超时，或虚假唤醒但 ready 仍为 false
}
超时后如何避免“假成功”和资源泄漏
超时不是终点，而是决策点：你要明确后续动作——重试？放弃？通知上游？尤其涉及 RAII 对象（如 socket、file handle）时，wait_for 返回后若未检查谓词，可能让线程继续操作已失效的资源。
- 永远把业务状态检查（如
ready、result_valid）放在谓词里，而不是 wait_after 后单独判断 - 如果超时后需清理，确保清理逻辑在
else分支里，且不依赖 lock 持有状态（lock 在 wait_for 返回时仍持有） - 避免在谓词中做耗时操作（如 IO、锁其他 mutex），否则超时精度严重失准
std::condition_variable + std::chrono::steady_clock 是唯一可靠组合
std::condition_variable::wait_until 和 wait_for 内部都基于 steady_clock，这是硬性要求。用 system_clock 或自定义 clock 会导致超时行为不可预测——系统时间被调整时，wait_until 可能提前返回或卡死。
立即学习“C++免费学习笔记（深入）”；
实操上，别自己算时间点：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
// ❌ 错误：手动加时，受 system_clock drift 影响 auto tp = std::chrono::system_clock::now() + 200ms; cv.wait_until(lock, tp, pred); // ✅ 正确：用 steady_clock，且交给 wait_for 处理 cv.wait_for(lock, 200ms, pred);
另外，200ms 这类字面量建议用 std::chrono::milliseconds(200) 显式构造，避免隐式转换歧义。
多线程下 notify_one/notify_all 与超时的竞争关系
notify 和 wait_for 是竞态操作：notify 可能在 wait_for 加锁前、加锁后但还没进内核等待队列、或刚进入等待队列后发生。这意味着即使 notify 先执行，wait_for 也可能超时——除非 notify 发生在 wait_for 的临界区内（即 lock 已持有时）。
安全模式只有一种：状态变更和 notify 必须在同一个 mutex 下原子完成：
mtx.lock(); ready = true; cv.notify_one(); // 必须在 lock 保护下 mtx.unlock();
漏掉这一步，哪怕超时设成 5s，也可能 100% 触发超时——不是代码慢，是 notify 永远赶不上 wait_for 的等待起点。
复杂点在于，很多业务逻辑把 notify 放在异步回调里，而回调可能运行在不同线程、甚至不同事件循环中，这时必须确保回调里重新获取并锁定同一 mutex，否则超时就是常态，不是异常。
