不能只用 mutex 包裹 priority_queue，因漏 notify 会导致消费者永久阻塞，须 push 后必 notify；默认最大堆需改用 std::greater 和 vector 实现小值高优；自定义消息需显式默认移动语义防拷贝开销；条件变量必须用谓词等待并加超时，且需在锁内循环校验堆顶有效性。
直接用 std::priority_queue 加锁封装，就能做出线程安全的带优先级消息队列；但关键不是“能不能跑”，而是“会不会漏唤醒、会不会死锁、堆顶更新是否及时”。
为什么不能只用 mutex 包裹 priority_queue？
单纯加锁后调用 push() 和 top()/pop() 看似可行，但消费者线程在空队列上 wait() 时，必须确保：生产者每次 push() 后都触发 notify_one() 或 notify_all()；否则消费者可能永远阻塞。常见错误是只在 push 后 notify，却忘了 pop 后若队列变空，下次 push 前没人唤醒消费者——其实不需管“是否变空”，只要 push 就 notify 才可靠。
- 漏 notify：消费者卡在
cv.wait()，无超时机制时彻底假死 - 误用
notify_all()：多个消费者竞争时可能引发惊群，但单消费者场景用notify_one()更轻量 - 未用谓词等待：
cv.wait(lock, []{ return !q.empty(); })必须写，不能先检查再 wait，否则存在竞态窗口
std::priority_queue 默认是最大堆，怎么改成按优先级数字小的先处理？
默认行为是“数值越大越先出”，但业务中常要“紧急程度值越小越优先”（比如 priority=0 表示最高紧急），这时必须显式指定比较器为 std::greater<t></t>，且底层容器必须支持随机访问——std::vector 是唯一稳妥选择，std::deque 不被 std::priority_queue 接受。
- 错误写法：
priority_queue<message deque>, greater<message>></message></message>→ 编译失败，deque 不满足堆算法对迭代器的要求 - 正确写法：
priority_queue<message vector>, greater<message>></message></message> - 如果 Message 是自定义结构体，需重载
operator>或提供独立Compare函数对象，且逻辑必须与greater语义一致（即 a > b 为 true 时 a 优先级更低）
消息结构体里放 std::string 会不会导致 move 语义失效？
会，而且很隐蔽。如果只定义了默认构造和成员变量，std::priority_queue 在内部调整堆时频繁调用拷贝构造，大量短字符串会触发小字符串优化（SSO）外的堆分配，性能陡降。必须显式默认移动构造/赋值，并禁用拷贝（或至少确认编译器生成了移动操作）。
- 推荐写法：
Message(Message&&) = default;+Message& operator=(Message&&) = default; - 避免写
const std::string&成员并用引用传参初始化——移动后引用悬空风险高 - 测试方法：在 push 前后打日志，看拷贝构造函数是否被调用；若出现多次拷贝而非一次移动，说明移动语义未生效
条件变量 wait 超时处理要不要加？
要，尤其在线上环境。没有超时的 wait() 会让整个消费者线程不可中断——比如配置热更新失败、依赖服务宕机时，你无法 graceful shutdown。用 cv.wait_for(lock, 100ms, []{...}) 并在超时后检查退出标志位，是健壮性的底线。
真正容易被忽略的是：堆顶元素可能已过期（比如带 TTL 的消息），但 priority_queue 本身不支持懒删除。必须在 dequeue() 返回前校验有效性，无效则继续 pop() 直到有效或队列空——这个循环必须包在锁内，否则多线程下会破坏堆结构。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
