应优先用time.AfterFunc实现单次延迟任务，它轻量可取消；大量动态任务需用最小堆+单Timer复用管理，避免频繁创建销毁Timer。
用 time.AfterFunc 做单次延迟任务，别直接裸写 time.Sleep
直接 time.Sleep 阻塞 goroutine 是最常见误用。它没法取消、没法复用、一睡就死，和“队列”完全不沾边。
真正该用的是 time.AfterFunc：它把函数调度交给 runtime 的 timer 系统，底层复用时间轮，轻量且可取消。
- 必须传入一个已声明的
func()，不能是闭包里捕获了可能被修改变量的匿名函数（容易读到过期值） - 返回值是
*time.Timer，调用Stop()可提前终止——比如任务被重复提交、用户取消请求等场景 - 注意：
AfterFunc不会阻塞，函数在新 goroutine 中执行，别在里面做 panic 后没 recover 的重操作
timer := time.AfterFunc(5*time.Second, func() {
fmt.Println("5秒后执行，且可被 Stop()")
})
// ……中途想取消
timer.Stop()
用最小堆（container/heap）管理大量动态延迟任务
当你要维护成百上千个不同到期时间的任务（比如订单超时关单、消息重试、定时通知），time.AfterFunc 就不够用了——它每任务一个 timer，开销大，且无法按需调整或批量查询。
这时候得自己实现延迟队列核心：用 container/heap 维护一个按触发时间排序的最小堆，再配一个常驻 goroutine 持续 pop 到期任务并执行。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 堆元素结构体必须实现
heap.Interface，重点是Less(i, j int) bool要比较dueAt字段 - 别在堆里存指针指向外部状态，避免竞态；任务逻辑尽量无状态，或用
sync.Map配合 ID 查状态 - pop 后记得调用
heap.Remove或heap.Pop，否则堆结构会错乱，后续Fix也救不回来
type Task struct {
ID string
DueAt time.Time
Fn func()
}
// Less 实现：return t[i].DueAt.Before(t[j].DueAt)
time.Timer 复用陷阱：别在 for-select 里反复 new
很多人想“轮询堆顶”，写个 for 循环每次取最早任务时间，然后 time.NewTimer 等待——这会导致 timer 对象疯狂创建销毁，GC 压力大，还可能漏触发（因为 reset 时机不对）。
正确做法是只持有一个 *time.Timer，每次堆有变更就 Reset 它，指向新的最近到期时间；如果堆空了，就 Stop 它。
-
Reset返回bool：false 表示原 timer 已触发或已 Stop，此时必须Stop后再NewTimer - 在 select 分支里收到
后，必须立刻从堆中 pop 所有已到期任务（不止一个！），因为精度误差或调度延迟可能导致多个任务在同一 tick 到期 - 别用
time.After替代Timer——它每次都会新建 timer，不可复用
生产环境绕不开的三个细节
本地跑通不等于线上可用。这三个点不处理，延迟可能漂移几十秒甚至丢任务。
- 系统时钟被 NTP 调整时，
time.Timer会受跳变影响（Linux 上默认用 CLOCK_MONOTONIC 修复，但老内核或容器环境不一定）——建议用github.com/robfig/cron/v3这类经过验证的库做兜底 - 任务执行函数 panic 会杀掉整个 timer goroutine，必须用
defer/recover包一层，否则后续所有延迟任务全卡住 - 堆中任务如果依赖外部资源（如 DB 连接），要检查上下文是否超时：
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)，别让一个慢任务拖垮整个队列
延迟队列真正的复杂性不在“怎么延”，而在“怎么不丢、不重、不错序、不雪崩”。堆和 timer 只是工具，边界控制和错误恢复才是活儿。
