go标准库未提供现成priorityqueue类型，仅提供需手动实现heap.interface的底层堆工具；container/heap适用于动态维护有序性，sort.slice适用于一次性全量排序。
为什么 container/heap 不是开箱即用的优先队列
因为 Go 标准库没提供现成的 PriorityQueue 类型，只给了堆操作的底层工具集。你得自己实现 heap.Interface——也就是 Len()、Less()、Swap()、Push()、Pop() 这五个方法。
常见错误现象：panic: interface conversion: interface {} is int, not *MyItem，通常是因为 Push 和 Pop 没做类型断言或指针解引用；或者 Pop 返回了错误的值（比如忘了从切片末尾取再删）。
-
Less(i, j int)决定“谁优先”：返回true表示i应该排在j前面（小顶堆就写a[i] ，大顶堆反过来） -
Pop()必须返回切片末尾元素，并且立刻slice = slice[:len(slice)-1]，否则下次heap.Fix或Push会越界 - 不要在
Less里做耗时操作（比如网络请求、文件读取），它会被频繁调用，影响heap.Push/heap.Pop性能
heap.Init 后还能不能直接改底层数组
可以改，但改完必须手动调用 heap.Fix、heap.Push 或 heap.Pop 来恢复堆性质；直接改数组元素值却不通知堆，后续操作大概率出错。
使用场景：动态更新某个任务的优先级（比如定时器重调度、Dijkstra 中松弛边后更新节点距离）。
立即学习“go语言免费学习笔记（深入）”；
- 如果只改了一个元素的优先级，用
heap.Fix(h, index)最高效，时间复杂度O(log n) - 如果不确定改的是哪个位置，或要批量更新，不如重建堆：
heap.Init(h)，虽然O(n)，但代码更稳 - 注意
Fix的第二个参数是索引，不是值；传错索引会导致堆结构彻底混乱，但不会 panic，调试起来很隐蔽
用 heap.Pop 取最大/最小值时为什么总少一个元素
因为 heap.Pop 本身就会把元素从切片中移除，如果你再手动 slice = slice[1:] 或类似操作，就删多了。
典型错误代码：
h := &IntHeap{1, 3, 2}<br>heap.Init(h)<br>val := heap.Pop(h).(int)<br>h.IntHeap = h.IntHeap[1:] // ❌ 多此一举
-
Pop的语义就是「取出并删除」，它的内部已经做了swap(0, len-1)+down(0)+return slice[len-1] - 如果你看到取出来的值和预期不符，先检查
Pop返回值是否被忽略（比如写了heap.Pop(h)却没接返回值） - 对空堆调用
Pop会 panic：index out of range，务必在调用前判断h.Len() > 0
和 sort.Slice 做堆排序比有什么实际区别
用 container/heap 是在线维护动态有序性，sort.Slice 是一次性全量排序；两者目标不同，别混用。
性能影响明显：插入 10 万条数据，用 heap.Push 累计约 O(n log n)，而每插一次都 sort.Slice 是 O(n² log n)，慢两个数量级以上。
- 需要持续插入+弹出最值（如任务调度、Top-K 流式统计），必须用
heap - 只是把一坨数据排好序就完事，用
sort.Slice更简洁，也更容易并行（sort.Parallel尚未进标准库，但第三方有） -
container/heap不支持自定义比较器函数，必须靠结构体方法实现Less；而sort.Slice直接传func(i,j int) bool，写临时逻辑更快
真正难的不是写那五个接口方法，而是想清楚：这个“优先级”到底该封装进结构体字段，还是靠外部状态计算——后者容易在并发或多次 Fix 时丢失一致性。
