std::condition_variable::wait_for不能直接用，因为它仅保证至少等待指定时长，可能因虚假唤醒提前返回且不检查条件是否满足；正确做法是用wait_until配合steady_clock和while循环重检谓词。
std::condition_variable::wait_for 为什么不能直接用
因为 wait_for 只保证「至少等待指定时长」，不保证「最多等待指定时长」——它可能被虚假唤醒（spurious wakeup）提前返回，而你没检查条件是否真正满足，就误以为超时了。真实场景里，你等的是「条件成立」或「超时」，不是「睡够多久」。
正确写法：用 wait_until + steady_clock + 显式条件判断
必须把超时时间换算成绝对时间点，传给 wait_until，并在 lambda 中严格检查谓词。否则一被唤醒就退出，根本不管条件有没有达成。
示例：
std::mutex mtx;
std::condition_variable cv;
bool ready = false;
auto timeout = std::chrono::steady_clock::now() + std::chrono::seconds(3);
std::unique_lock<:mutex> lock(mtx);
while (!ready) {
if (cv.wait_until(lock, timeout) == std::cv_status::timeout) {
break; // 真正超时：时间到了，且 ready 仍为 false
}
}
// 退出时 ready 可能为 true，也可能为 false —— 由 while 循环保证</:mutex>
-
wait_until返回std::cv_status::timeout表示「时间到了但没被通知」 - 返回
std::cv_status::no_timeout表示「被 notify 唤醒」，但不保证条件成立（可能虚假唤醒） - 所以必须用
while循环重检条件，不能用if - 务必用
std::chrono::steady_clock，不用system_clock（系统时间可能被手动调整）
封装成可复用的工具函数要注意什么
如果封装成模板函数，比如 wait_for_condition，容易忽略锁的生命周期和异常安全。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 不能把
std::unique_lock作为参数传入再内部释放——锁必须在函数返回前仍持有，否则条件变量行为未定义 - 谓词函数抛异常会导致
wait_until退出，但锁会被自动释放（unique_lock析构），这点要心里有数 - 不要试图在函数里重新获取锁——条件变量等待要求锁已持有
- 超时单位建议统一用
std::chrono::nanoseconds模板参数，避免隐式转换精度丢失
Linux 下 pthread_cond_timedwait 的等价陷阱
如果你在写跨平台代码或对接 C API，别直接套用 pthread_cond_timedwait 的 struct timespec 时间计算逻辑到 C++ —— 它用的是 CLOCK_REALTIME，而 std::condition_variable::wait_until 要求 steady_clock。混用会导致在系统时间跳变时行为不一致，甚至永远阻塞。
正确做法是：用 std::chrono::steady_clock::to_time_t 不行，得自己把 steady_clock::time_point 转成 timespec，靠 clock_gettime(CLOCK_MONOTONIC, ...) 对齐。
换句话说：C++ 标准库的 wait_until 已帮你屏蔽了这些细节，只要坚持用 steady_clock，就别去碰 pthread 底层时间换算。
最常被忽略的一点：超时等待的语义是「条件成立 或 超时」，不是「等一段时间」。漏掉 while 循环重检，等于没加超时。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
