std::condition_variable::wait_for不能直接当“带超时的条件变量”用，因为它不持有状态，必须配合外部谓词（如bool ready）使用；超时返回仅表示谓词仍为假且未收到通知，而非条件未满足，故必须用lambda谓词重检以避免虚假唤醒或漏判。
为什么 std::condition_variable::wait_for 不能直接当“带超时的条件变量”用
因为 std::condition_variable 本身不持有状态，它只是配合 std::mutex 和一个外部谓词（比如 bool ready）工作的同步原语。即使调用 wait_for 超时返回，也不能说明“条件没满足”，而只说明“在超时前没收到通知且谓词仍为假”。常见错误是忽略谓词检查，写成：
cv.wait_for(lock, 100ms); // ❌ 错！没检查 ready 是否真为 true
if (ready) { /* 处理 */ }这会导致虚假唤醒或漏判——超时后 ready 其实已被设为 true，但还没来得及被看到。
正确写法：必须用 while 循环 + 谓词重检
标准做法是把条件检查包进 wait_for 的谓词参数里，让其自动重试直到超时或条件成立：
std::unique_lock<std::mutex> lock(mtx);
if (cv.wait_for(lock, 100ms, [&]{ return ready; })) {
// ✅ 进来这里时 ready 一定为 true，且未超时
process();
} else {
// ⚠️ 超时了，ready 仍为 false（此时已确认过）
}- 这个 lambda 会在每次唤醒（包括虚假唤醒）后重新求值，确保逻辑安全
- 不要手动写
while (!ready) { cv.wait_for(...); }—— 容易漏掉超时后对ready的最终判断 - 如果谓词计算开销大，需确保它是无副作用、快速返回的
注意 wait_until 与系统时钟精度的关系
用 wait_until（比如搭配 std::chrono::steady_clock::now() + 100ms）比 wait_for 更可控，但要注意：
立即学习“C++免费学习笔记（深入）”；
-
steady_clock是推荐的，避免系统时间被调整影响超时逻辑 - 实际唤醒可能比设定时间晚几毫秒——内核调度和用户态开销导致，无法保证绝对精确
- 某些平台（如 Windows + MinGW）对高精度时钟支持弱，
wait_for(1ms)可能实际延迟 15ms
若业务对延迟敏感，别依赖 sub-10ms 级别的超时精度。
更复杂的场景：需要取消等待或响应中断
std::condition_variable 原生不支持取消。如果线程需在超时外被主动唤醒（例如收到取消信号），常见做法是引入额外标志：
std::atomic<bool> cancelled{false};
// …
if (cv.wait_for(lock, 100ms, [&]{ return ready || cancelled.load(); })) {
if (cancelled) {
// 处理取消
} else {
process();
}
}- 多个退出条件共存时，谓词里用
||组合，保持原子性检查 - 避免在谓词里加锁或耗时操作，否则会拖慢整个等待路径
- 如果取消逻辑频繁发生，考虑改用
std::condition_variable_any配合自定义锁，但通常没必要
真正难处理的是“等待中被 kill”这种 OS 级中断——C++ 标准库不提供可打断的等待，得靠线程协作或信号机制，那已经超出条件变量范畴了。
