条件谓词是防止虚假唤醒和竞态的唯一防线，必须用while循环包裹、仅读取受同一锁保护的共享状态，且须为纯函数；省略或写错将导致死锁或脏数据。
条件谓词不是语法糖，而是防止虚假唤醒和竞态的唯一防线。 它是 wait() 内部循环检查的布尔表达式，决定了线程该不该真正醒来继续执行——写错或省略它，程序会在看似正常时随机卡死或读到脏数据。
为什么必须用 while 循环包裹谓词，而不是 if
因为操作系统可能在无通知情况下唤醒线程（即“虚假唤醒”），也可能在通知发出后、线程重新获取锁前，被其他线程抢先消费了条件（例如消费者抢在你之前取走了最后一个任务）。if 会让线程误以为条件成立而直接往下走，导致崩溃或逻辑错误。
- ✅ 正确：用
while (!pred()) { cond.wait(lock); }—— 每次唤醒后都重新验证 - ❌ 错误：用
if (!pred()) { cond.wait(lock); }—— 一次判断，永不回头 - ⚠️ 注意：
std::condition_variable::wait(lock, pred)底层就是帮你自动展开成 while 循环，但前提是pred是可调用对象且每次调用都真实反映状态
谓词里能访问哪些变量？哪些绝对不能写
谓词函数体必须只读取被同一互斥锁保护的共享状态。任何绕过锁的读取（比如直接读全局 ready 而不加锁）、或读取非共享的局部变量，都会破坏内存可见性，导致永远等不到唤醒。
- ✅ 允许：
[&]{ return !tasks.empty() || shutdown_requested; }（tasks和shutdown_requested都由同一mtx保护） - ❌ 禁止：
[&]{ return flag_from_another_thread; }（flag_from_another_thread未受锁保护，编译器可能优化掉重读，CPU 可能读到过期缓存） - ⚠️ 注意：C++ 中捕获引用必须确保生命周期长于等待过程；Rust 中需用
Arc<mutex>></mutex>包裹状态再传入闭包
常见谓词陷阱：你以为的“条件成立”，其实早已失效
最典型的是在谓词中做“副作用检查”，比如 [&]{ tasks.pop(); return true; } —— 这不仅违反谓词应为纯函数的原则，更会导致多次 pop 或竞争崩溃。谓词只负责“问”，不负责“动”。
- ❌ 错误模式：
while (queue.size() > 0) { auto x = queue.front(); queue.pop(); ... }（size 和 front/pop 不是原子操作） - ✅ 正确流程：谓词只检查
!queue.empty()→ wait 返回后，在临界区内做front()+pop() - ⚠️ 特别注意：Go 的
sync.Cond.Wait()不提供谓词封装，必须手写for !condMet { c.Wait() }；Java 的Condition.await()同理
谓词写得再短，只要没覆盖所有状态变迁路径，就等于没写。它不是锦上添花的检查，而是通信逻辑的契约底线——漏掉一个 || shutdown，程序就可能在退出时死锁；多写一个未加锁的变量读取，就可能在高负载下间歇性失联。
