用 container/heap 实现带优先级的定时任务队列
用 container/heap 实现带优先级的定时任务队列
Go语言的标准库确实没有开箱即用的优先级队列，但别担心，container/heap 包已经为我们准备好了所有底层工具。这里的关键，其实不在于“堆怎么建”，而在于“任务怎么比”——你必须确保高优先级的任务能稳稳地待在堆顶。小根堆默认把最小值放在顶部，所以一个常见的技巧是，把高优先级映射为更小的数值。
新手常犯的一个错误是直接用任务创建的时间戳来当优先级。这里需要明确：时间早，并不等于优先级高。在实际调度场景里，紧急任务往往需要插队，哪怕它创建得比别的任务都晚。
- 定义任务结构体时，核心字段不能少：
priority int（优先级）、execTime time.Time（执行时间）、fn func()（任务函数）。 - 实现
heap.Interface接口时，Less(i, j int) bool方法的逻辑是重中之重：先比较priority，如果优先级相同，再比较execTime。这能有效防止低优先级但时间早的任务被无限期延迟（也就是“饥饿”问题）。 - 记住，每次调用
heap.Push或heap.Fix之后，堆结构才会重新保持有效。另外，在调用Pop取出堆顶元素后，别忘了后续的清理工作，比如调用heap.Remove或手动调整堆。
用 time.Timer + 优先级队列做动态调度
如果只用 time.AfterFunc，任务一旦设定就很难取消或调整顺序。一个真正灵活、可调度的系统，必须支持任务的插入、取消和重新调度。核心思路是：维护一个全局的 *time.Timer，让它始终指向队列中下一个即将执行的任务。每当队列有变动——比如新增了更高优先级的任务，或者某个任务被取消了——就重新计算下一个任务的执行时间，并对这个 Timer 调用 Reset。
这个环节容易踩坑。一是并发访问，对队列的读写如果没有用锁保护，数据竞争就来了。二是操作 Timer 不规范，在 Reset 之前没有先尝试 Stop，这可能导致 timer 资源泄漏甚至程序 panic，常见的错误信息包括 timer already fired 或 invalid memory address。
立即学习“go语言免费学习笔记（深入）”；
- 使用
sync.RWMutex来保护优先级队列的并发访问。特别是查看堆顶（Peek）和弹出任务（Pop）的操作，必须是串行的。 - 在调用
Timer.Reset(d)之前，务必先检查并停止旧计时器：if !t.Stop() {，否则之前设定的 timer 可能还在发送信号，引发混乱。} - 如果任务函数本身执行时间可能较长，考虑在调度循环中启动一个 goroutine 来异步执行
fn()，避免阻塞核心的调度逻辑。
用 golang.org/x/exp/slices 简化优先级排序（Go 1.21+）
如果你的场景不需要实时、动态地调整堆结构，只是定期批量处理一批任务（例如，像 cron 那样每分钟拉取一批待执行任务），那么使用切片配合 slices.SortFunc 会是更轻量、更清晰的选择。它比自己手动维护堆接口更不容易出错，单元测试也简单得多。
需要明确的是，这不是一个实时调度器。它更适合“每隔固定时间，对当前所有待办任务按优先级排个序，然后依次执行”的模式。从性能角度看，对于1000个量级以内的任务，排序的开销远小于维护一个完整堆结构的复杂度。
- 排序函数需要返回一个布尔值，
true表示元素a应该排在元素b前面。你可以自由组合排序条件：优先级更高（数值更小）、执行时间更早、甚至任务ID更小。 - 切记，不要在排序比较函数内部执行任何I/O操作或加锁，这会严重拖慢整个排序过程。
- 如果你的任务列表在排序后还需要频繁地插入或删除，那就别用
slices.SortFunc了，它不维护动态数据结构，每次操作后重新排序的代价太高。
第三方库选型：为什么 robfig/cron 不适合优先级调度
robfig/cron 是一个非常优秀的基于时间表达式的调度库，但它设计之初就是让所有任务平等排队，并不支持在运行时根据优先级调整执行顺序，也不支持任务插队。它的 Entry.ID 字段主要用于取消任务，而非调度决策。如果非要基于它实现优先级，相当于要在外面再包一层逻辑，有点得不偿失。
更贴近需求的第三方库可能是 hibiken/asynq（专注于分布式任务队列）或 machinery（也支持优先级字段），但它们通常依赖 Redis 或其它消息中间件。如果你想要的是一个纯内存、无外部依赖的轻量级优先级调度器，那么自己组合 heap 和 Timer 仍然是最高效、最可控的方案。
asynq的task.WithPriority确实有效，但引入它会带来一整套服务启动、任务序列化、失败重试的机制，复杂度显著提升。- 如果只是内部服务中有少数几类任务需要区分轻重缓急（例如，配置热更新 > 日志归档 > 统计上报），没必要引入一个完整的分布式队列系统。
- 定义优先级数值时，强烈建议使用常量，例如：
const ( PrioUrgent = 0; PrioNormal = 10; PrioBackground = 100 )。这能彻底避免代码中间出现令人困惑的“魔法数字”。
说到底，实现优先级调度最困难的部分，往往不是数据结构与算法，而是如何清晰定义“优先级”的业务语义：是严格抢占吗？任务等待超时后优先级会自动提升吗？允许临时降低优先级吗？这些规则如果一开始没想清楚，代码就会在后期不断打补丁，越来越难以维护。建议在动手写 Less 函数之前，先在白板上把任务可能的状态和流转图画清楚。
