go的container/heap是堆操作适配器而非优先队列类型，必须自定义类型并完整实现heap.interface的五个方法；其中push和pop必须用指针接收者，否则修改副本导致插入/删除无效。
Go 的 container/heap 不是优先级队列类型，而是堆操作适配器；你必须自己定义类型、完整实现 heap.Interface 的五个方法，且 Push 和 Pop 必须用指针接收者，否则插入/删除完全无效。
为什么 heap.Push(&pq, x) 没反应？
最常见原因是 Push 和 Pop 方法用了值接收者（比如 func (pq PriorityQueue) Push(x interface{})），导致 *pq = append(*pq, x) 修改的是副本，原切片长度和内容毫无变化。
-
Push和Pop必须使用指针接收者：func (pq *PriorityQueue) Push(x interface{}) - 调用时也必须传地址：
heap.Push(&pq, task)，不能写heap.Push(pq, task) -
Len、Less、Swap可用值接收者（更高效），但不是必须——统一用指针接收者反而不易出错 - 如果
pq是局部变量字面量（如pq := PriorityQueue{}），&pq可能编译失败；应改用var pq PriorityQueue或字段为指针类型
Less(i, j int) bool 怎么写才对？
Less 决定谁该“浮到堆顶”：返回 true 表示索引 i 的元素优先级更高（即更小，对最小堆而言）。写反会导致 heap.Pop() 返回错误元素，甚至 panic。
- 最小堆（默认）：数值越小越优先 →
return h[i].Priority - 最大堆：数值越大越优先 →
return h[i].Priority > h[j].Priority - 避免在
Less中访问可能为nil的字段（如*time.Time），先判空再比较，否则运行时 panic - 别在
Less里调函数、查 map、读外部状态——它会在每次上滤/下滤中高频调用，性能敏感
heap.Init()、heap.Push()、heap.Pop()、heap.Fix() 各自什么时机用？
heap.Init() 是初始化堆序的强制步骤，不是可选项；heap.Push 和 heap.Pop 是日常增删的唯一正途；heap.Fix 是特例工具，99% 的场景不该碰。
-
heap.Init(&pq)必须在首次使用前调用，哪怕切片为空；它执行一次完整堆化（从最后一个非叶子节点开始下沉），不调就直接Push行为未定义 -
heap.Push和heap.Pop已自动维护堆序，新增/删除永远只走这两个入口 -
heap.Fix(&pq, i)仅当你**手动修改了索引i处元素的优先级字段**后才需要（比如任务中途升级紧急度），此时堆结构已破坏，需从该位置重新上滤或下滤 - 误用
heap.Fix（比如在Push后调用）会触发index out of rangepanic，因为它假设索引合法且结构基本完整
并发访问 PriorityQueue 怎么办？
container/heap 所有函数纯内存操作，零并发保护；多个 goroutine 直接读写同一 PriorityQueue 变量，必然触发 data race、切片错乱或 panic。
- 必须加锁，推荐用
sync.Mutex包裹每次heap.Push和heap.Pop调用 - 锁粒度要覆盖整个操作：比如
Enqueue方法里mu.Lock()→heap.Push(&pq, x)→mu.Unlock() - 不要只锁
Push/Pop却忽略Peek（读(*pq)[0]）或遍历——只要读写底层数组，就得串行 - 避免在锁内执行耗时操作（如网络请求、大计算），否则阻塞整个队列吞吐
最容易被忽略的是：堆结构本身不感知字段变更。一旦你把一个 Task 入队后，又直接改了它的 Priority 字段，堆序就失效了——这时不是靠 heap.Fix 就能救回来的，得先确保设计上优先级在入队前就稳定，或者用带 index 字段的 Item 结构体配合显式更新逻辑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
