正确写法是Less方法优先比较Priority（值小者优先），相等时再比execTime防饥饿；错误写法用“>”会导致逻辑混乱，因最小堆需小值在顶，高优任务应对应更小数值。
Go 标准库没有现成的优先级任务调度器，但用 container/heap + 自定义结构体 + 一点并发控制，就能做出稳定可用的内存级调度器——关键不是堆怎么建，而是任务怎么比、谁来保护、Timer 怎么 reset。
怎么写 Less 才让高优先级任务先出队
最小堆默认把“小值”放在堆顶，所以你要让高优任务对应更小的数值。比如 Priority=0 是最高优，Priority=10 是低优。别反着来，否则整个调度逻辑就倒了。
- 错误写法：
func (pq PriorityQueue) Less(i, j int) bool { return pq[i].Priority > pq[j].Priority }（这实际建的是最大堆，但没配对 Pop/Init 就会乱） - 正确写法：优先比
Priority，相等再比execTime防饥饿：return pq[i].Priority - 别在
Less里调用方法或做 I/O，它会被高频调用，必须轻量 - 如果业务语义是“数值越大越紧急”，那就统一转成负数：
-task.Priority，别改比较逻辑
为什么 heap.Push 后不立刻生效，还得手动 heap.Init
heap.Push 内部已调用 heap.Up 维护堆序，不需要也不该再 heap.Init。真正要小心的是：直接改切片元素（比如 pq[0].Priority = 5）后，堆结构就坏了，必须显式调 heap.Fix(&pq, idx)。
-
heap.Init是 O(n) 全量重建，只在初始化空堆或批量灌入后用一次 -
heap.Fix是 O(log n)，适合单个任务优先级变更后修复位置 - 忘了
Fix的典型现象：修改task.Priority后，heap.Pop还是返回旧的最高优任务 - 如果你的任务结构体里没存
index字段，就无法安全调Fix——得自己加
怎么避免 *time.Timer 导致 panic 或泄漏
用 time.Timer 驱动定时调度时，Reset 前不检查是否已触发，大概率遇到 timer already fired 或 invalid memory address。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 每次重设前必须：
if !t.Stop() { select { case ，清掉可能残留的信号 - 堆为空时别
Reset，直接Stop并置为nil，否则 Timer 会一直挂着 - 所有堆操作（
Push/Pop/Fix）必须由同一把sync.RWMutex保护，Peek（看堆顶）也要锁，不然读到中间态 - 任务执行耗时长？别在 Timer 回调里直接跑
fn()，用go fn()异步，否则阻塞下一次调度
并发 worker 消费时为什么 heap.Pop 会 panic
多个 goroutine 直接对同一个 PriorityQueue 切片调 heap.Pop，底层 append 和索引访问会竞态，报 index out of range 或数据错乱。
- 必须用
sync.Mutex包住所有堆操作，粒度不能大到锁住fn()执行 - 别用
for range循环读 channel 模拟队列——优先级队列不是 channel，没有阻塞/非阻塞语义 - worker 停止前，要用
sync.Once+closed标志位，主动Pop并执行完剩余任务，别丢弃高优任务 - 如果只是每秒轮询执行一批，不用实时堆调整，
golang.org/x/exp/slices.SortFunc更简单、更易测
真正难的不是实现堆，而是明确优先级语义、守住并发边界、以及在 Reset 和 Fix 这两个点上不手抖。
