std::condition_variable::wait_for 必须传 std::unique_lock，因其需在等待中自动释放并重获锁，而 std::lock_guard 不可移动且生命周期固定；超时参数必须为 std::chrono::duration 类型；返回 false 仅表示超时未被通知，仍需检查谓词；需用 while 循环防虚假唤醒和通知丢失。
std::condition_variable::wait_for 为什么必须传 std::unique_lock
因为 wait_for 内部会先释放锁、挂起线程，超时或被唤醒后再尝试重新加锁——这个“自动释放+重获”逻辑依赖 std::unique_lock 的可移动性和对 mutex 的完全控制权。std::lock_guard 不可复制也不可移动，且构造即加锁、析构即释放，无法满足 wait 过程中“临时释放”的需求。
常见错误是传入 std::lock_guard<:mutex></:mutex> 或裸指针，编译直接报错：no matching member function for call to 'wait_for'。
- 必须用
std::unique_lock<:mutex></:mutex>，且保持其生命周期覆盖整个wait_for调用 - 不能用
std::scoped_lock（C++17），它不可移动，C++11 也不支持 - 锁对象（
std::mutex）必须和 condition_variable 绑定同一份共享状态
wait_for 的超时参数到底传什么单位
wait_for 第二个参数是 std::chrono::duration 类型，不是毫秒整数，也不是秒浮点数。传错单位会导致等待时间相差千倍甚至被截断为 0。
正确写法示例：
立即学习“C++免费学习笔记（深入）”；
std::mutex mtx;
std::condition_variable cv;
std::unique_lock<std::mutex> lk(mtx);
// ✅ 正确：显式指定毫秒
cv.wait_for(lk, std::chrono::milliseconds(500));
// ✅ 正确：用 duration_cast 避免隐式转换歧义
auto timeout = std::chrono::duration_cast<std::chrono::milliseconds>(
std::chrono::seconds(1) + std::chrono::microseconds(234)
);
cv.wait_for(lk, timeout);
// ❌ 错误：整数 500 → 编译失败（无匹配构造）
// cv.wait_for(lk, 500);
// ❌ 错误：double 0.5 → 无法隐式转成 duration（除非显式构造）
// cv.wait_for(lk, 0.5s); // C++14 起才有字面量，C++11 不支持
wait_for 返回值 false 意味着什么，要怎么处理
wait_for 返回 bool：true 表示在超时前被 notify_one/notify_all 唤醒；false 表示超时到期，但此时锁已重新持有，线程可安全访问共享数据。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
关键点在于：**返回 false 不代表条件成立与否，只代表“没被通知”**。你仍需手动检查谓词（predicate），不能直接当作“条件不满足”跳过逻辑。
- 如果用带谓词的重载
wait_for(lk, rel_time, []{ return ready; })，返回 false 就说明谓词仍为 false，可放心继续等或退出 - 如果用无谓词版本，返回 false 后必须重新判断业务条件，否则可能漏处理或死循环
- 注意 spurious wakeup：即使返回 true，谓词也可能为 false（系统假唤醒），所以生产代码几乎都该用带谓词的版本
wait_for 在多线程中容易被忽略的唤醒时机问题
wait_for 的超时是相对调用时刻的“近似”等待，不是硬实时保证。实际唤醒可能比设定时间晚几毫秒（取决于调度延迟、系统负载），尤其在高负载或低优先级线程中更明显。
更隐蔽的问题是：如果在 wait_for 等待期间，另一个线程调用了 notify_one，但当前线程尚未进入内核等待队列，这次通知就丢失了——这就是为什么必须配合 while 循环 + 谓词检查，而不是 if 判断。
典型健壮写法：
while (!ready) {
auto status = cv.wait_for(lk, std::chrono::milliseconds(100));
if (status == std::cv_status::timeout && !ready) {
// 可选：做超时处理，比如重试、日志、降级
continue;
}
// 被唤醒后仍需检查 ready，防止虚假唤醒
}
真正难调试的坑，往往出在把 wait_for 当作“阻塞 N 毫秒然后继续”，却忽略了它和条件变量语义的强耦合：它不是定时器，而是“带超时的条件等待”。
