wait_for可能未超时就返回，因其返回no_timeout仅表示被唤醒（含虚假唤醒），不保证谓词为真；须用while循环重检，且优先选用基于steady_clock的wait_for而非wait_until。
为什么 wait_for 有时根本没超时就返回了？
因为 wait_for 返回 std::cv_status::no_timeout 表示条件变量被唤醒（哪怕只是虚假唤醒），不是“条件满足”；它只管有没有被 notify，不管 predicate 是否为真。很多人误以为传了 lambda 就自动重检，其实得自己写循环。
- 必须用 while 循环包裹
wait_for，不能用 if —— 虚假唤醒和 notify 发生在检查前都会导致逻辑错乱 - 超时时间是相对当前系统时钟的，如果系统时间被大幅调整（如 NTP 同步跳变），
steady_clock不受影响，但system_clock可能导致等待提前或延后 - 示例中常见错误：
cv.wait_for(lock, 100ms, []{ return ready; });看似安全，但如果ready是非原子变量，且没加 memory_order，可能读到陈旧值
wait_until 和 wait_for 选哪个？
优先用 wait_for。它基于 steady_clock，不受系统时间跳变影响，语义更可靠；wait_until 需要手动构造时间点，容易出错，比如传 system_clock::now() + 100ms 就埋了隐患——万一 now() 返回的是过期时间点，立刻超时。
-
wait_for参数是持续时间（std::chrono::duration），直观、安全 -
wait_until参数是时间点（std::chrono::time_point），适合与外部 deadline 对齐（如 RPC 总超时），但需确保用steady_clock构造 - 不要混用 clock：传
system_clock::time_point给期望steady_clock的重载，编译不过；反之可能静默截断
超时后怎么判断是真超时还是被 notify 扰乱？
wait_for 和 wait_until 都返回 std::cv_status 枚举，只有两个值：no_timeout（被 notify 或虚假唤醒）和 timeout（真超时）。但注意：这个返回值只反映“是否等到通知”，不反映谓词结果。
- 如果用了带 predicate 的重载（即 lambda 版本），返回
true才代表谓词为真 + 未超时；返回false就是超时，不用再查状态 - 如果用无 predicate 版本，必须自己检查共享状态，并区分：返回
cv_status::timeout→ 确实超时；返回no_timeout→ 醒来但未必满足业务条件，还得重新判断 - 别依赖
lock.owns_lock()判断是否超时——它始终为 true，锁在函数退出前一直持有
线程被中断（如 std::jthread 停止）时，wait_for 会响应吗？
不会。标准 std::condition_variable 完全不感知线程取消或停止请求，wait_for 在超时前既不会被 std::jthread::request_stop() 中断，也不会抛异常。想实现协作式中断，得自己组合 std::stop_token。
立即学习“C++免费学习笔记（深入）”；
- 典型做法：在循环条件里加
token.stop_requested()，并在每次 wait 前检查 - 或者用
std::condition_variable_any配合自定义锁类型，把 stop_token 检查塞进锁的try_lock逻辑里（复杂且少见） - 别指望
wait_for自动处理 stop —— 这是 C++20 也没补上的空白，得手写轮子
真正麻烦的是多个退出条件交织：超时、通知、取消请求、错误标志……这时候光靠一个 condition_variable 不够，往往得退回到轮询 + sleep_for，或者换用更高级的同步原语（如第三方库中的 cancellation_token 集成版）。
