std::priority_queue不能直接用于多消费者广播队列，因其非线程安全且默认最大堆与业务最小优先级需求相反；需自定义比较器、细粒度锁、分离分发逻辑，并避免使用Windows专属API。
直接用 std::priority_queue 做全局广播队列，必然卡死或丢消息——它不是为多消费者并发分发设计的。
std::priority_queue 默认是最大堆，但业务常要最小优先级
很多人一上来就写 std::priority_queue<message></message>，结果发现高优先级消息（比如 priority=1）被排在后面。因为默认用 std::less<message></message>，top() 返回的是“最大”值，而你定义的 priority 越小越紧急，这刚好反了。
必须显式指定比较器：
struct Message {
int priority;
std::string data;
bool operator<(const Message& rhs) const { return priority > rhs.priority; } // 注意是 >
};
std::priority_queue<Message> max_heap; // 这样 top() 才返回 priority 最小的
// 或更清晰地：
std::priority_queue<Message, std::vector<Message>, std::greater<int>> min_heap;
// 但注意：std::greater<int> 只能比较 int 成员，不能直接用于 Message，得自定义比较器或重载 operator<
- 漏掉容器模板参数
std::vector<Message>会触发编译错误：no type named 'value_type' in 'std::less<Message>' - 重载
operator<时，逻辑必须严格满足“严格弱序”，否则push()行为未定义；常见错是写成return priority <= rhs.priority - 别在比较器里做耗时操作（如日志、网络调用），它会在每次堆调整时被高频调用
单队列 + 全局锁 = 订阅者互相阻塞
一个 std::priority_queue 加一把 std::mutex，然后所有生产者 push、所有消费者 while(!empty()) pop，这是最典型也最危险的模式。
立即学习“C++免费学习笔记（深入）”；
问题在于：pop() 是两步操作（取 top + 删除），而标准库没提供原子的“弹出并返回”接口；你必须先 top() 再 pop()，中间若解锁，其他线程可能插入/删除，导致数据不一致。
- 正确做法是：只在锁内做
top()和pop()，但必须确保每次只服务一个订阅者——即锁粒度要细到“每个主题+每个消费者线程” - 更稳妥的是用
std::queue+ 手动堆排序（std::make_heap等），把堆操作和锁分离：锁内仅交换元素、调整索引；实际分发在锁外进行 - 若用条件变量等待新消息，
notify_one()比notify_all()更轻量，除非你明确需要唤醒全部消费者
广播分发必须脱离队列层，且防重复消费
队列只负责“按优先级排序并暂存”，分发逻辑必须后置。例如某主题 "alarm" 有 3 个订阅者，新来一条 priority=0 消息，不能让队列自己遍历投递——那等于把网络延迟、序列化开销全塞进临界区。
应这样组织：
- 锁内：从该主题的优先队列取出消息，拷贝一份，记录 msg_id，更新已分发订阅者集合（如
std::unordered_set<subscriber_id>） - 解锁后：遍历该主题当前活跃订阅者列表，对每个订阅者异步投递（如
std::async或线程池post()） - 每个订阅者收到后必须校验
msg_id是否已处理过，否则高优消息重发会导致状态错乱 - 饥饿问题靠“低优先级消息保底调度”缓解：比如每 10 条高优消息后，强制 pop 一条最低优先级消息
别碰 BroadcastSystemMessage，它和你的服务无关
搜到 BroadcastSystemMessage 就停手。它是 Windows GUI 子系统内部 API，只能向本机窗口过程发 WM_* 消息，不支持序列化、无优先级机制、不能跨进程、更不适用于 C++ 后端服务的多线程消息路由。
替代方案很明确：
- 进程内：用
std::condition_variable+ 主题哈希表 + 每主题独立优先队列 - 跨进程：命名管道（Windows）或 domain socket（Linux），配合消息头带 priority 字段
- 分布式：别自己造，直接上 Redis Streams 或 Kafka，它们原生支持优先级分组与消费者组语义
真正难的从来不是堆怎么调、锁怎么加，而是“谁该在什么时候看到哪条消息”——这个策略一旦写死在队列实现里，后面加个灰度开关或按地域分流，就得重写整个分发引擎。
