std::priority_queue默认用std::less构建最大堆，故小元素“沉底”；top()返回最大值，需std::greater或自定义比较器实现最小堆，模板三参数缺一不可。
priority_queue 默认比较规则为什么让小元素“沉底”
因为 std::priority_queue 默认用 std::less<t></t>，它实际构建的是**最大堆**：顶部是最大元素。很多人误以为“优先级高=数字小”，结果调 top() 却拿到最大值，一查才发现逻辑反了。
常见错误现象：priority_queue<int></int> 存入 {3,1,4}，top() 返回 4，不是 1；想实现最小堆却没改比较器，导致后续 pop 顺序和预期完全相反。
- 想按数值升序弹出（先弹小数），必须显式传
std::greater<int></int> - 自定义类型时，不能只重载
operator 就完事——默认仍走 <code>less，得在模板参数里明确写出来 - VS 和 GCC 对空
priority_queue调top()行为一致：未定义行为，不是抛异常，而是可能崩溃或返回垃圾值
如何为 struct 正确配置 priority_queue 的排序逻辑
核心不是“怎么写比较函数”，而是**模板参数顺序不能错**。标准写法是：priority_queue<mystruct vector>, decltype(cmp)></mystruct>，三个参数缺一不可，漏掉容器类型或比较器类型都会编译失败。
使用场景：比如存任务 struct Task { int id; int priority; };，希望 priority 小的先执行。
立即学习“C++免费学习笔记（深入）”；
- 用 lambda？不行——lambda 类型无法作为模板参数（除非用
auto+ C++20 deduction guide，但太绕，不推荐） - 老老实实用函数对象：
struct Compare { bool operator()(const Task& a, const Task& b) { return a.priority > b.priority; } };注意这里返回a > b才能得到小 priority 先出队的效果 - 别把比较逻辑写反：如果写成
a.priority ，那实际建的是最大堆，和默认行为一样，毫无意义
push/emplace 性能差异在哪，什么时候必须用 emplace
emplace 直接在堆内存里构造对象，避免临时对象拷贝/移动；push 先构造再移动进容器。对简单类型（int、double）几乎没差别，但对 string、vector 或自定义类，尤其含资源管理的，差异明显。
容易踩的坑：以为 emplace 总是更快，结果传参时隐式转换引发意外构造。
- 安全用法：
q.emplace(101, "upload")—— 参数直接转发给构造函数 - 危险写法：
q.emplace(Task{101, 5})—— 先构造临时Task，再 move，失去 emplace 意义 - 如果类构造函数是 explicit，
emplace可能编译失败，而push因为接受 const ref 反而能过
清空 priority_queue 没有 clear()，但别用 while(!empty()) pop()
标准库的 priority_queue 真的没有 clear() 成员函数。网上常见“while 循环 pop”的做法，在数据量大时效率极低：每次 pop 都要 heapify，复杂度 O(n log n)，而其实底层容器（通常是 vector）自己支持 O(1) 清空。
正确做法是换掉整个底层容器，但接口不暴露。所以务实解法只有一个：
- 用作用域控制生命周期：
{ priority_queue<int> q; /* use */ } // 出作用域自动销毁</int> - 需要复用变量名？直接赋值一个新对象：
q = priority_queue<int>();</int>—— 移动赋值，O(1) - 千万别手写循环 pop，特别是实时系统或高频调用路径里，这会成为性能热点
真正麻烦的是带自定义比较器和容器类型的声明，比如 priority_queue<task deque>, Compare></task>，这时候赋值写法要完整重复模板参数，容易漏写或写错——这种时候，宁可重新声明变量，也别硬凑一行赋值。
