用 heap 包原地求 topn 时间复杂度为 o(n log n)，优于 sort.slice + [:n] 的 o(n log n)；需自定义 heap.interface，求 topn 大用最小堆，topn 小用最大堆，push 时超容则 pop 堆顶；结构体比较关键在 less 实现与指针接收。
用 heap 包做原地 topN，别写排序再切片
对几万以上元素取前 N，sort.Slice + [:N] 是最常见错误：它把整个数组排了序，时间复杂度 O(n log n)，而你只需要 O(n log N)。Go 标准库的 heap 包就是干这个的——维护一个大小为 N 的最大堆（求 topN 小）或最小堆（求 topN 大），边扫边调整。
关键点在于：你要实现 heap.Interface，但只重写 Len、Less、Swap 和 Push/Pop；Push 里判断是否超容，超了就 Pop 掉堆顶（即当前最“不达标”的那个）。
- 求最大的前 N 个 → 用最小堆（堆顶是最小值，方便淘汰）
- 求最小的前 N 个 → 用最大堆（堆顶是最大值）
- 初始化堆后，用
heap.Init，之后所有插入都走heap.Push - 最后遍历堆内元素即可，不用再排序——它们无序，但全部属于 topN 范围
自定义结构体怎么让 heap 认得？重点看 Less 和 Pop
很多人卡在结构体字段比较和指针接收上。比如有个 type Item struct { Name string; Score int }，想按 Score 取 topN 高分：
-
Less(i, j int) bool必须返回h[i].Score > h[j].Score（求 topN 大 → 最小堆 → 小的在顶，所以“i 比 j 小”实际是 i.Score 更大？不对——要让堆顶是最小的 Score，所以Less应该返回h[i].Score ） -
Pop必须是return h[len(h)-1]，不是return h[0]；Push是h = append(h, x)，别漏掉赋值 - 接收器必须统一：如果
Push/Pop用指针接收，Len/Less/Swap也得用指针接收，否则编译报错cannot use … as heap.Interface
数据量极大（千万级）且不能全加载进内存？用外部归并 + heap.Merge
当源数据来自文件流、数据库游标或网络分页，根本没法一次性读进 slice，就得边读边筛。这时候不要自己手写归并逻辑，Go 1.21+ 的 heap.Merge（注意不是 container/heap 里的，是 golang.org/x/exp/slices 下实验性包）能合并多个已排序的 topN 列表——但前提是每个分块你已经用上面方法独立算出了它的 topN。
- 每读一批（比如 10 万条），用最小堆跑一次 topN，保留结果 slice
- 把所有批次的 topN 结果汇总成 [][]Item，传给
slices.SortFunc或手动两两heap.Init后heap.Pop归并 - 更稳的做法：用
priorityqueue第三方库（如github.com/cobaltspeech/heapq），它支持从迭代器构建，避免中间 slice - 注意磁盘 IO 和 GC 压力：别把每条记录都 new struct，复用
sync.Pool分配临时对象
heap 不是万能的：N 接近总长度时直接排序更快
当 N > len(data)/10，堆的优势迅速消失。因为堆每次 Push/Poll 都有 log N 开销，而现代 CPU 上 sort.Slice 的常数极小，分支预测友好，对中等规模（
- 实测临界点因机器而异，但建议加个开关：
if N - 别忽略
sort.SliceStable：如果你依赖原始顺序（比如相同分数按输入先后排），Less返回 false 时需额外判断索引，不如直接稳定排序 + 切片 - 还有个隐藏坑：
heap.Pop会把底层数组最后一个元素移到堆顶再 down，但不会自动截断底层数组容量——如果反复复用同一 slice，可能残留旧数据，导致Len()错误
堆的边界很清晰：N 小、数据大、内存紧。一过线，就该换策略。很多人调了半天 heap 性能，其实只是 N 设太大了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
