container/heap 不是开箱即用的优先队列，因其仅提供堆操作工具，需手动实现 heap.interface 的五个方法；常见错误包括 less 实现错误、swap 未生效、漏调 heap.fix() 或切片截断。
为什么 container/heap 不是“开箱即用”的优先队列
Go 标准库没有提供现成的 PriorityQueue 类型，container/heap 只是一套堆操作工具集，它不封装数据结构，也不自动维护排序逻辑——你得自己实现 heap.Interface 的五个方法。
常见错误现象：heap.Push(&h, item) 后发现元素没按预期排序，或 heap.Pop(&h) 返回的不是最小/最大值。根本原因往往是 Less() 实现错位、Swap() 未正确交换底层切片元素，或者忘记在修改元素后调用 heap.Fix()。
-
Len()和Less(i, j int) bool必须基于同一份底层数据；若用指针切片存元素，Less里解引用要一致 - 如果动态更新某个元素的优先级（比如 Dijkstra 中松弛边），不能只改字段值——必须调用
heap.Fix(&h, index)重新堆化该位置 -
Pop()要负责从切片末尾取元素并缩短长度，漏掉h = h[:h.Len()-1]会导致后续操作 panic 或数据错乱
如何用 container/heap 实现最小堆和最大堆
Go 没有内置比较器或泛型约束，所以最小堆和最大堆得靠 Less() 方向控制：返回 a 是最小堆，<code>a > b 是最大堆。别试图复用同一结构体切换行为——容易在 Fix() 或并发场景下出错。
使用场景：任务调度（按截止时间升序）、合并 K 个有序链表（取当前最小节点）、Top-K 统计（维持大小为 K 的最大堆）。
立即学习“go语言免费学习笔记（深入）”；
- 最小堆示例：定义
type MinHeap []int，Less(i, j int) bool { return h[i] - 最大堆示例：同类型，但
Less(i, j int) bool { return h[i] > h[j] } - 混用风险：同一个切片同时被两个不同
Less逻辑的 heap 实例管理，行为未定义 - Go 1.21+ 可用泛型封装，但标准库本身仍无泛型版
heap，别依赖constraints.Ordered自动推导比较逻辑
heap.Init() 和 heap.Fix() 的实际触发时机
heap.Init() 只在初始化时把任意顺序切片变成合法堆，它不监听后续变更；而 heap.Fix() 是唯一能局部修复单个节点违反堆序的方式——比全量 heap.Init() 更轻量，也更易出错。
性能影响：对长度为 N 的堆，Fix() 最坏 O(log N)，Init() 是 O(N)；但误用 Fix()（比如传入错误索引）会导致堆损坏且难以调试。
- 必须在修改某元素后立刻调用
heap.Fix(&h, i)，而不是等所有修改完再批量修——堆序可能已在中间步骤被破坏 -
i必须是有效索引（0 ），越界不会 panic，但结果不可预测 - 如果只是 Push/Pop，不用手动 Fix；只有原地改字段 + 依赖该字段做 Less 判断时才需要
和手写堆排序算法（sort.Sort + 自定义 sort.Interface）的区别
container/heap 维护的是动态堆结构，支持 O(log N) 插入/删除；而 sort.HeapSort（或 sort.Sort）是一次性排序，O(N log N) 时间建序，之后无法高效增删。
容易踩的坑：有人把切片先 heap.Init()，再反复 sort.Sort()，以为能保持堆序——其实 sort.Sort 会彻底重排，破坏堆结构；反之，对已排序切片直接 heap.Pop() 也不保证正确性，因为缺少堆头校验。
- 需要持续增删 → 用
container/heap+ 自定义类型 - 只需要一次排序输出 → 用
sort.Slice()或sort.Sort()，更简单安全 - 想复用排序逻辑到 heap 中？别复制粘贴
Less，把比较逻辑抽成独立函数，两边都调用它，避免不一致
真正麻烦的是跨 goroutine 共享堆实例——container/heap 本身不带锁，所有操作都要自己加互斥，而且 Push/Pop 不是原子的，连 len(h) 都可能和实际不一致。这点文档几乎不提，但线上出过竞态 bug。
