heap.Init() panic 是因未完整实现 heap.Interface：缺 Push/Pop 方法或接收者类型错误；Less 返回 true 表示 i 应排在 j 前，最小堆需写 pq[i].Priority < pq[j].Priority。
Go 语言里没有现成的 PriorityQueue 类型，必须用 container/heap 自己搭；不实现 Push 和 Pop 方法，heap.Init() 就会 panic；优先级逻辑写反，heap.Pop() 拿到的就不是你想要的那个任务。
为什么 heap.Init() 一调就 panic？
因为 container/heap 要求你提供的类型必须完整实现 heap.Interface：即 Len()、Less(i, j int) bool、Swap(i, j int) 这三个值接收者方法，外加 Push(x interface{}) 和 Pop() interface{} 这两个指针接收者方法。
常见错误包括：
- 只实现了
Len/Less/Swap，漏了Push或Pop——heap.Init()直接报 “missing method Push” -
Push和Pop写成了值接收者（如func (pq PriorityQueue) Push(...)）—— 运行时报 “cannot call pointer method on pq” - 定义队列变量时用了短变量声明
pq := PriorityQueue{}，导致后续传&pq时不可寻址
正确姿势是：var pq PriorityQueue，然后 heap.Init(&pq)。
立即学习“go语言免费学习笔记（深入）”；
Less 怎么写才不会拿错最高优先级任务？
Less(i, j int) bool 返回 true 表示「索引 i 的元素应该排在 j 前面」。它不直接表达“谁优先级高”，而是决定堆的排序方向。
比如任务结构体：
type Task struct {
ID int
Priority int // 数值越小，越紧急（如延迟毫秒数）
}
要让最小 Priority 先出队（最小堆），就得写：
func (pq PriorityQueue) Less(i, j int) bool {
return pq[i].Priority < pq[j].Priority // ✅ 小的在前
}
如果误写成 >，heap.Pop() 拿到的就是最大 Priority 的任务，和预期完全相反。
其他场景参考：
- 定时器调度：按最早触发时间升序 →
Less比较时间戳，用< - 限流器中高权重请求优先：权重越大越靠前 →
Less返回pq[i].Weight > pq[j].Weight - 禁止在
Less中读当前时间或外部状态，否则堆结构可能失效
任务处理中怎么安全地 push/pop？
heap.Push 和 heap.Pop 必须传指针，且原变量得能取地址 —— 这是最容易卡住的地方。
错误示范：
heap.Push(&PriorityQueue{}, &Task{ID: 1, Priority: 10}) // ❌ 不可寻址，编译不过
正确流程：
- 定义可寻址变量：
var tasks PriorityQueue - 初始化：
heap.Init(&tasks) - 插入：
heap.Push(&tasks, &Task{...}) - 取出：
task := heap.Pop(&tasks).(*Task)
注意：Pop 返回 interface{}，需手动断言类型；如果队列为空，Pop 仍会返回零值（不会 panic），但业务逻辑得自己判空。
实际任务调度中容易被忽略的细节
真正跑在线上时，几个点常被跳过：
-
Pop后没清掉元素的index字段（如果用了带index的Item结构），会导致后续heap.Fix出错 - 并发读写同一个
PriorityQueue变量，没加锁 ——heap包本身不保证线程安全 - 把
Priority设为int64却在Less里用==判断相等性，而堆操作依赖严格偏序，应避免用==作比较依据 - 任务对象含指针或大字段，
Pop后没置nil，可能阻碍 GC
这些不显眼，但上线后要么 panic，要么内存缓慢上涨，查起来费劲。
