直接 new 切片会 panic，因为 container/heap 要求传入已实现 heap.interface 的非 nil 实例，且底层切片不可为 nil；正确做法是用 &intheap{} 初始化，避免 less 中访问 nil 字段。
为什么直接 new 一个切片就 panic？
因为 container/heap 不是“开箱即用”的队列，它根本不存数据——只提供堆序维护逻辑。你传给它的必须是一个**已实现 heap.Interface 的类型实例**，且该实例底层切片不能为 nil。
- 常见错误：写
h := IntHeap(nil)后直接heap.Init(&h)→Len()返回负值或 panic - 正确做法：哪怕空队列，也要初始化为
h := &IntHeap{}或h := &IntHeap{}（注意取地址） -
Less方法里别碰未初始化字段或nil指针，比如h[i].Task != nil && h[i].Task.Priority 才安全 - 漏掉任意一个
heap.Interface方法（尤其是Push/Pop的指针接收器签名），运行时就会报interface conversion: *X is not heap.Interface
Push 和 Pop 必须用指针接收器，不是可选项
因为 Push 要调 append，Pop 要截断切片——这两者都会改变底层数组头（len、cap、甚至地址）。值接收器只会改副本，原切片完全没变。
- 错例：
func (h IntHeap) Push(x interface{})→ 插入无效，h始终为空 - 对例：
func (h *IntHeap) Push(x interface{}) { *h = append(*h, x.(int)) } -
Pop顺序不能反：先取old[n-1]，再做*h = old[0 : n-1]；反过来会返回错误元素 - 所有
heap.Push/heap.Pop调用都必须传指针，如heap.Push(&pq, task)，传值会静默失败
Init、Fix、Push 到底什么时候该调？
heap.Init 只在两种场景下需要：从外部批量加载数据后（比如 DB 查出一堆任务），或你手动构造了一个无序切片。新建空堆、只用 Push 填充，完全不用 Init。
-
heap.Push内部已自动上滤（sift-up），时间复杂度O(log n)；每次Push后再Init是典型性能陷阱（O(n)覆盖O(log n)） -
heap.Fix(&h, i)只在你**手动改了某个元素的字段**（比如动态更新了task.RemainingTime）导致堆序破坏时才调——不是每改一次都得 Fix，而是改完后明确知道位置i失序了才调 - 别在
Less里做耗时操作（查 map、调函数），堆调整频繁触发Less，一卡就是调度循环
并发访问不加锁必出问题
container/heap 连个 mutex 字节都没藏，纯函数式操作。多个 goroutine 同时 Push/Pop，轻则数据竞争，重则切片越界 panic 或堆结构损坏。
- 最简方案：
sync.Mutex包一层，所有Push/Pop/Peek（如果自己实现）都在锁内 - 别用
chan封装来“假装线程安全”——通道只排队，底层切片仍被多 goroutine 并发读写 -
heap.Fix和heap.Init都要写锁，不能用sync.RWMutex的读锁，否则可能读到半截坏堆 - 懒删除（map 标记 + Pop 时跳过）虽简单，但高并发下 Pop 前检查标记也得加锁，否则 map 并发写 panic
真正难的从来不是写对那五个方法，而是想清楚：谁在什么时候改了什么字段、是否破坏了堆序、要不要修复、有没有并发干扰。这些地方一松懈，bug 就藏得深又跑得偏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
