go语言通过container/heap实现优先队列需自定义类型并实现heap.interface的五个方法，其中less必须处理优先级相等时的二级比较以避免饥饿，且所有并发操作须统一加锁保护。
Go 语言没有内置优先级调度能力，所谓“基于内存的优先级调度”，本质是用 container/heap 构建一个线程安全的内存队列，并由你控制谁先被 Pop()、谁该插队、谁该取消——不是 runtime 帮你调度，是你自己写逻辑决定顺序。
container/heap 的 Less 方法怎么写才不翻车
排序逻辑错，整个优先级就崩。别只比 priority 数值，得处理相等情况，否则同优先级任务会随机出队甚至饥饿。
- 高优先级任务数值应更小（比如
0表示最高），Less(i, j int) bool返回true表示i应该排在j前面 - 必须二级比较：先比
Priority，相等再比CreatedAt或ID（避免堆内元素位置漂移） - 禁止在
Less里调用任何可能阻塞或 panic 的函数（如 DB 查询、HTTP 请求） - 如果任务支持动态提权（比如超时后升为高优），不要原地改
Priority后直接heap.Fix——你得先知道它在堆里的索引，而container/heap不维护索引映射
并发读写 *PriorityQueue 必须加锁，且不能只锁部分操作
常见错误是只给 Push 加锁，但 Peek（看堆顶）或 Len() 没锁，导致 goroutine 竞态或 panic: “invalid memory address”。
- 所有公开方法（
Push、Pop、Peek、Len）都必须用sync.Mutex或sync.RWMutex包裹 - 别把锁粒度设得太细（比如只锁 Push 内部切片操作），外部仍可能并发调用
Pop；统一在方法入口加锁最稳 - 如果使用
sync.RWMutex，注意Push和Pop是写操作，Peek和Len可读，但一旦Peek返回指针并被外部修改，就得升级为写锁 - 切忌把
heap.Push(&pq, task)直接丢进 goroutine 异步执行——没锁保护的并发堆操作必破坏堆不变量
用 time.Timer 配合队列做定时调度时，Reset 前必须 Stop
这是生产环境最常触发 panic 的点：timer already fired 或 invalid memory address 往往源于没检查旧 timer 状态。
- 每次有新任务入队或队顶变更，都要重新计算下一个执行时间：
time.Until(pq.Peek().ExecTime) - 调
timer.Reset(d)前，务必先if !t.Stop() { /* 说明已触发，需手动清理 */ }，否则可能向已关闭的 channel 发信号 - 别让 timer 回调直接执行任务逻辑；应发到 worker channel，避免阻塞 timer goroutine
- 如果任务执行耗时超过间隔，考虑用
time.AfterFunc替代长周期Timer，或加 context 超时兜底
真正难的不是堆怎么建，而是当任务执行失败要重试、用户中途取消、优先级随业务规则动态变化时，你怎么保持队列状态一致。这些场景下，heap.Fix 的调用时机、任务版本号管理、以及是否允许“软删除”而非真实 Pop，比初始排序逻辑重要得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
