wait_for比wait更适合超时场景，因其支持带时长的超时等待并返回cv_status以区分超时与唤醒，需配合unique_lock和steady_clock使用，推荐用带谓词的重载避免虚假唤醒。
wait_for 为什么比 wait 更适合超时场景
直接用 std::condition_variable::wait 无法设超时，它要么被 notify 唤醒，要么死等。真正支持超时的是 wait_for 和 wait_until —— 它们返回 std::cv_status，让你能区分「超时了」还是「被唤醒了」。
关键点：必须传入一个带时钟精度的 std::chrono 时长（比如 std::chrono::milliseconds(500)），不能传 raw int；且必须配合 std::unique_lock<:mutex></:mutex> 使用，否则编译失败。
-
wait_for接收相对时长（从当前时刻起），适合等待固定毫秒/秒 -
wait_until接收绝对时间点（如std::chrono::steady_clock::now() + 500ms），适合与外部 deadline 对齐 - 返回值是
std::cv_status::timeout或std::cv_status::no_timeout，别用布尔值判断
超时后怎么判断条件是否真满足了
超时只是“等够了时间”，不代表条件不成立——可能刚超时，另一线程就改完状态并 notify 了。所以不能只看 wait_for 返回值，得结合 predicate 重检逻辑。
推荐写法是用带谓词的 wait_for 重载：cv.wait_for(lock, timeout, []{ return condition; });。它内部自动循环检查，返回 true 表示条件满足（无论是否超时），false 才是真超时且条件仍假。
立即学习“C++免费学习笔记（深入）”；
- 如果手动写循环 +
wait_for，容易漏掉 notify 恰好发生在超时前的“惊群”情况 - 谓词函数必须捕获或访问到受保护的共享变量，且该变量修改必须在同个 mutex 下
- 避免在谓词里做耗时操作，否则阻塞整个条件变量等待路径
steady_clock 还是 system_clock？选错会出什么问题
超时依赖的时钟类型直接影响行为稳定性。std::condition_variable::wait_for 内部用的是 steady_clock，但你传入的 duration 是基于哪个 clock 构造的并不重要——真正要小心的是你手写的 deadline 计算（比如用 system_clock::now() 加偏移）。
- 用
system_clock可能因系统时间被手动调整或 NTP 同步导致“时间倒流”，wait_until等待异常延长甚至永远不返回 -
steady_clock单调递增，不受系统时间干扰，是超时逻辑的唯一可靠选择 - 错误示例：
auto tp = std::chrono::system_clock::now() + 1s;→ 改成auto tp = std::chrono::steady_clock::now() + 1s;
notify_one 和 notify_all 在超时场景下的实际影响
超时本身不改变 notify 行为，但会影响你对 notify 的预期。如果你用 wait_for 等待某个特定事件，而多个线程共用同一个 condition variable，notify_all 可能唤醒无关线程，它们检查谓词失败后又立刻回去等待——浪费 CPU。
- 只要业务逻辑允许，优先用
notify_one，尤其当每次 notify 只对应一个等待者时 - 如果一个 notify 要唤醒多个不同条件的等待者（比如“有新数据”和“缓冲区空了”共用一个 cv），必须确保每个等待者谓词互斥，否则出现虚假唤醒误判
- 注意：即使
wait_for超时返回，后续收到 notify 也不会再唤醒它——超时后锁已释放，线程已退出等待态
最常被忽略的点：超时不是“取消等待”，而是“放弃本轮等待”。之后要不要重试、要不要清理资源、要不要标记失败，全由你控制——condition variable 本身不提供 cancel 语义。
