std::condition_variable必须与std::mutex配合使用，所有wait/notify操作须在同 mutex 保护下进行；需用lambda条件判断防虚假唤醒；notify_one/all选择取决于业务语义；超时等待后仍需检查条件。
std::condition_variable 必须和 std::mutex 一起用
单独声明 std::condition_variable 没有意义，它不管理临界区，只负责“通知-等待”逻辑。所有 wait()、notify_one()、notify_all() 调用都必须在持有同一把 std::mutex 的前提下进行，否则行为未定义（常见崩溃或死锁）。
典型错误是：在 wait() 前没加锁，或锁的是另一把互斥量。正确模式是：
std::unique_lock<:mutex> lock(mtx);
cv.wait(lock, [&]{ return ready; });</:mutex>
注意：wait() 内部会自动释放 lock，被唤醒后重新获取——这是防止唤醒丢失的关键机制。
用 lambda 判断条件，别手写 while + wait
直接调用 cv.wait(lock) 是危险的，可能遭遇虚假唤醒（spurious wakeup）。标准做法是传入一个可调用对象（通常是 lambda），让 wait() 内部循环检查条件是否真正满足。
-
cv.wait(lock, []{ return data_ready; });—— 安全，推荐 -
while (!data_ready) cv.wait(lock);—— 理论可行，但易漏写条件更新逻辑，且不如 lambda 清晰 -
cv.wait(lock);—— 错误，无条件等待，无法响应业务状态变化
lambda 中捕获的变量（如 data_ready）必须受同一 std::mutex 保护，否则存在数据竞争。
notify_one() 和 notify_all() 的选择取决于等待者语义
notify_one() 唤醒**至少一个**正在 wait() 的线程；notify_all() 唤醒**所有**等待线程。选哪个不是看性能，而是看业务逻辑是否允许多个线程同时推进。
- 生产者-消费者模型中，一个新任务到达，只需唤醒一个消费者 → 用
notify_one() - 状态变更（如“初始化完成”）需确保所有依赖线程都收到 → 用
notify_all() - 用
notify_one()却有多个等待线程？可能造成部分线程永久阻塞（如果条件不满足又没再次通知）
注意：notify_* 调用本身不要求持有锁（可以加锁后调用，也可以不加），但被唤醒线程恢复执行时，仍需重新竞争并获取该 mutex 才能继续——这点常被忽略。
std::condition_variable 不支持超时等待的简单写法
wait_for() 和 wait_until() 支持带超时的等待，但它们同样需要配合条件判断，不能只靠超时就认为“条件已满足”。
std::unique_lock<:mutex> lock(mtx);
if (cv.wait_for(lock, 100ms, [&]{ return result_available; })) {
// 真正满足条件，可安全使用 result
} else {
// 超时了，但 result_available 仍可能为 false —— 不能直接用 result
}</:mutex>
超时返回 false 只代表“等了这么久还没满足”，不代表“永远不满足”。若业务允许重试，应在外层加循环；若必须放弃，则需额外同步机制标记失败态。
容易被忽略的一点：系统时钟精度、调度延迟可能导致实际等待时间略长于指定值，尤其在高负载下。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
