根本原因是未正确实现heap.interface的五个方法契约：less必须严格基于切片当前状态比较，swap须真正交换元素，修改字段后须调用heap.fix维护堆序，且初始化必须调用heap.init。
Go 里解决 TopK 问题，container/heap 是标准且高效的选择，但直接用会 panic 或结果错乱——根本原因不是不会写，而是没踩对 heap.Interface 的五个方法契约。
为什么 heap.Push 后堆序不生效？
常见现象：heap.Push(&h, x) 执行完，h[0] 不是最小/最大值，甚至 heap.Pop(&h) 返回的也不是预期元素。
核心问题出在 Less() 和 Swap() 的实现不匹配：
-
Less(i, j int) bool必须严格基于底层切片当前状态比较；若结构体字段被修改但没调heap.Fix()，它就“看不到”变化 -
Swap(i, j int)必须真正交换切片中两个索引位置的元素，不能只改字段或搞错指针解引用层级 - 如果类型是
[]*Item，Less里必须写h[i].priority ，而不是 <code>(*h[i]).priority—— Go 切片元素本身已是指针，双重解引用会 panic
最小堆 vs 最大堆：只靠 Less() 方向控制
Go 没有内置最大堆类型，也不支持运行时切换堆序方向。同一个切片不能既当最小堆又当最大堆管理。
正确做法是定义两个独立类型：
- 最小堆：
type MinHeap []int，Less(i, j int) bool { return h[i] - 最大堆：
type MaxHeap []int，Less(i, j int) bool { return h[i] > h[j] }
混用会导致 heap.Pop() 行为未定义——比如把 MaxHeap 实例传给本该处理 MinHeap 的逻辑，堆顶弹出的可能是任意值。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
TopK 场景下，为什么用容量为 K 的最小堆？
求最大的 K 个数，维持一个大小始终 ≤ K 的最小堆，堆顶就是这 K 个数里的“门槛”。新元素比堆顶大，才值得替换进去。
关键细节：
- 初始化后必须调
heap.Init(&h)，否则切片只是普通数组，不满足堆序 - 每次
heap.Push(&h, x)前，先检查len(h) ；满员时，只在 <code>x > h[0]时做heap.Pop()+heap.Push() - 别用
append(h, x)替代heap.Push()——后者会自动上滤，前者直接破坏堆结构
示例逻辑片段：
if len(minH) minH[0] {
heap.Pop(&minH)
heap.Push(&minH, x)
}
动态更新元素优先级时，Fix() 不是可选项
比如在 Dijkstra 或任务重调度中，你改了某个 item.priority 字段，但没调 heap.Fix(&h, i)，后续 Pop() 就可能漏掉它或提前弹出。
heap.Fix() 的触发条件很具体：
- 仅当某个已有元素的优先级字段被原地修改（非 Push/Pop）
- 且该字段参与了
Less()判断 - 且你明确知道它在堆中的索引
i
漏掉 Fix() 不会 panic，但堆结构会逐步腐化——这种 bug 往往只在数据量变大或特定输入顺序下暴露，极难复现。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
