std::priority_queue 默认是大顶堆，top() 返回最大值；因其默认使用std::less比较器，若需小值优先（如定时任务），须显式指定std::greater作为第三个模板参数。
为什么 std::priority_queue 默认不是“高优先级先出”？
很多人一用就发现：插入 1、10、5，top() 却返回 10——以为是“最大堆”，结果业务要的是“数值越小，优先级越高”（比如定时任务按毫秒时间戳排序），这就反了。
根本原因是：std::priority_queue 默认用 std::less<t></t>，底层是大顶堆，top() 返回最大值。它不关心你叫它“优先级队列”，只认比较逻辑。
- 要实现“小值优先”，得显式传入
std::greater<int></int>作为第三个模板参数 - 自定义类型必须提供
operator 或传入仿函数，否则编译报错：<code>invalid operands to binary expression - 别在运行时“反转逻辑”，比如手动存
-timestamp——容易溢出、可读性差、调试时 timestamp 显示为负数
如何让自定义任务结构体正确参与优先级比较？
直接把 struct Task 塞进 std::priority_queue 会失败，因为默认没有定义大小关系。常见错误是只重载了 operator== 或写了个 compare() 成员函数但没被调用。
最稳妥的做法是提供 operator，且语义清晰：返回 <code>true 表示左边“优先级更低”（即应该排在右边之后）。
立即学习“C++免费学习笔记（深入）”；
struct Task {
int priority; // 数值越小，越该先执行
std::string name;
bool operator<(const Task& rhs) const {
return priority > rhs.priority; // 注意：这里是 >，不是 <
}
};
- 上面的
operator 实际构建的是小顶堆：当 <code>this->priority > rhs.priority，说明this该排后面，所以this 为 <code>false，符合std::less的预期 - 如果用仿函数替代，记得第三个模板参数写成
std::priority_queue<task std::vector>, Compare></task>，别漏掉容器类型 - 避免在
operator 里做耗时操作（如字符串比较、IO），否则 <code>push()和pop()性能直线下滑
std::priority_queue 能否动态修改已入队任务的优先级？
不能。这是它和真正“可更新堆”（如 Boost.Heap 的 fibonacci_heap）最本质的区别：std::priority_queue 是只读接口封装，底层 std::vector 不暴露索引，也没有 update() 或 erase() 方法。
一旦任务入队，它的位置就被固定；想改优先级，唯一办法是标记旧任务为无效，再 push 一个新任务。
- 配合使用
std::shared_ptr<task></task>+ 状态标志位（如bool valid = true），pop()后检查再处理 - 别试图用
std::make_heap手动维护底层容器——std::priority_queue不保证公开其内部vector，不同 STL 实现可能加 padding 或私有成员，强行访问会未定义行为 - 如果业务频繁修改优先级（如网络请求重试倒计时动态调整），建议换用
std::set或第三方库，别硬撑
多线程环境下直接用 std::priority_queue 安全吗？
不安全。它没有任何线程同步机制。两个线程同时 push() 可能导致底层 vector 重分配时数据错乱，top() + pop() 组合也不是原子操作。
最轻量的修复方式是套一层互斥锁，但要注意粒度：
- 不要只锁
push()和pop()，也要锁empty()和size()——它们同样读底层容器 - 避免在锁内做耗时操作（比如处理任务本身），否则整个队列阻塞，吞吐暴跌
- 如果需要等待非空再取任务，别用 while+sleep 轮询，改用
std::condition_variable配合锁
复杂点在于：优先级队列的“唤醒”逻辑比普通队列更敏感——新入队的高优任务，应该立刻打断当前等待线程，而不是等下一次通知。这点很多简单封装会忽略。
