插入元素必须上滤以恢复堆序，因新元直接置于末尾会破坏父≤子性质；需持续与父节点（0-based下为(i-1)/2）比较交换直至根或父更小。
插入元素时为什么必须上滤（sift_up）
因为二叉堆的结构性质要求所有节点都满足堆序：父节点 ≤ 子节点（小根堆）。直接把新元素塞到数组末尾会破坏这一性质，必须把它“浮”到正确位置。上滤的本质是持续和父节点比较、交换，直到父节点更小或已到根。
常见错误是索引算错——C++里用 0-based 数组，parent(i) 必须写成 (i-1)/2，不是 i/2；否则对偶数下标会误算父节点。
实操建议：
- 每次交换后更新当前索引
i = parent(i)，别漏这步 - 循环终止条件是
i == 0或heap[parent(i)] ，注意等号——相等时无需再上滤 - 避免在
sift_up中重复计算parent(i)，可先存为int p = (i-1) >> 1
删除堆顶后下滤（sift_down）的关键判断逻辑
删掉根后，得把末尾元素挪上来，再让它“沉”下去。难点在于：该和哪个子节点比？必须选更小的那个子节点（小根堆），否则可能跳过合法路径，导致堆序破裂。
立即学习“C++免费学习笔记（深入）”；
典型错误是只和左子比较，忽略右子存在性，或比较时没检查右子是否越界——right = 2*i + 2 可能 ≥ size()，直接访问会越界。
实操建议：
- 先确认左子存在：
left = 2*i + 1，若left >= heap.size()，说明无子节点，下滤结束 - 再查右子：
right = left + 1，仅当right 且 <code>heap[right] 时才选右子 - 交换后更新
i为所选子节点索引，继续循环；别忘了在交换前保存目标子索引，否则比较和交换用的索引不一致
vector 实现时 size() 与 capacity() 的实际影响
std::vector 做底层容器很自然，但要注意：插入频繁时 push_back 触发扩容会导致 sift_up 的时间不可控（虽然均摊 O(log n)，但单次可能 O(n)）；而删除时 pop_back 不缩容，size() 减小但内存未释放。
如果你的优先队列生命周期长、增删极不均衡（比如先插 10 万再删剩 10 个），capacity() 会远大于 size()，浪费内存但不影响逻辑正确性。
实操建议：
- 若预估最大规模，构造时用
reserve(N)避免多次扩容 - 不推荐在
pop()后调用shrink_to_fit()——它不保证缩容，且开销大，纯属干扰主线逻辑 - 真正要控制内存时，应由使用者决定何时重建整个堆，而不是在每次删除后干预 vector
operator[] 和 top() 的语义差异必须分清
top() 是接口契约：返回堆顶值，不修改结构；而 operator[](0) 是底层暴露——它确实能取到堆顶，但绕过了封装，一旦你后续误改 heap[0]，堆序立刻崩坏，且类无法感知。
另一个坑是有人把 top() 实现成 return heap[0] 后加 assert(!empty())，这没问题；但若写成 return empty() ? T{} : heap[0]，就引入了默认构造风险——T 可能不可默认构造，或默认值语义错误。
实操建议：
-
top()必须要求非空，断言或抛异常均可，但不能回退到默认值 - 不要提供
operator[]给用户直接访问内部数组——除非明确设计为“可调试视图”，且文档写清风险 - 如果真需要随机访问（比如调试打印），加一个
const std::vector<t>& raw_data() const</t>，用 const 引用只读暴露
if 判定，也不要靠“应该不会越界”去赌。 
