直接用std::queue加互斥锁会导致忙等待和无法感知新元素，需配合std::condition_variable实现线程挂起与唤醒；wait必须用std::unique_lock，推荐带谓词的wait避免虚假唤醒；有界队列需两个条件变量分别管理空与满状态。
为什么直接用 std::queue 加互斥锁会出问题
因为消费者线程在队列为空时，如果只是加锁后发现 empty() 为真，就立刻解锁并循环重试，这会引发忙等待（busy-waiting），浪费 CPU；更严重的是，它无法感知“何时有新元素到来”，导致要么卡死、要么漏通知。必须让线程在无数据时主动挂起，等生产者插入后再唤醒——这正是 std::condition_variable 的作用。
std::condition_variable::wait() 必须和 std::unique_lock<:mutex> 配合使用
wait() 不是独立工作的：它会在进入等待前自动释放锁，并在线程被唤醒且重新获得锁后才返回。如果不传 std::unique_lock，编译直接报错；若传 std::lock_guard，则因类型不匹配而失败。常见错误写法：cv.wait(lock) 中的 lock 是 std::lock_guard —— 这会导致未定义行为。
- 消费者等待逻辑应写成：
cv.wait(lock, [&] { return !q.empty(); });（带谓词的 wait，避免虚假唤醒） - 生产者通知只需调用
cv.notify_one()（单个消费者唤醒）或cv.notify_all()（全部唤醒，适合多消费者竞争场景） - 注意：notify 可以在锁内或锁外调用，但放在锁内更易保证唤醒时机不被调度器打乱
阻塞队列的 push/pop 接口要区分「阻塞」和「超时」语义
实际工程中，你往往需要两种行为：一种是无条件阻塞直到成功（如核心工作流），另一种是带超时的尝试操作（如响应式任务或资源受限场景）。标准库没提供现成封装，得自己实现：
-
push(T&& item)：加锁 → 入队 →cv.notify_one()，无返回值 -
pop(T& item)：加锁 →cv.wait(...)等非空 → 出队，成功返回true -
try_pop_for(T& item, std::chrono::milliseconds timeout)：用cv.wait_for()，返回std::cv_status::timeout或no_timeout，再判断队列是否真有数据
漏掉超时判断或忽略 wait_for() 返回值，会导致看似“超时了”其实仍卡在 pop 上。
立即学习“C++免费学习笔记（深入）”；
多个条件变量容易混淆：空 vs 满，该用几个？
如果你的队列有容量上限（即有界阻塞队列），就需要两个条件变量：not_empty_cv 和 not_full_cv，分别控制消费者和生产者的等待。只用一个 cv 会导致：当队列满时，生产者 wait 后被 notify_one() 唤醒，但唤醒源可能是消费者 pop 后触发的同一通知——它本意是告诉“有空间了”，却可能误唤醒另一个生产者，造成竞争或逻辑错乱。
- 有界队列中，
push()要先等not_full_cv，再入队，再 notifynot_empty_cv -
pop()要先等not_empty_cv，再出队，再 notifynot_full_cv - 两个 cv 对应两把“门禁”，混用或省略其中一个，边界控制就失效了
很多人一开始用无界队列测试没问题，一加上容量限制就死锁，问题几乎都出在这里。
