正确做法是单次任务用 time.AfterFunc，动态批量任务需自建最小堆加单 Timer 驱动；time.Sleep 仅适用于临时调试，因其阻塞 goroutine、不可取消且无队列语义。
直接用 time.Sleep 做延迟执行是错的——它阻塞 goroutine、无法取消、不构成队列语义，纯属临时调试写法。真正可用的方案只有两个层级：单次任务用 time.AfterFunc，动态批量任务必须自己搭最小堆 + 单 Timer 驱动。
用 time.AfterFunc 实现可取消的单次延迟任务
这是最轻量、最安全的单次延迟调用方式，底层复用 Go runtime 的时间轮，不额外启 goroutine 管理 timer。
- 别传匿名闭包捕获可能被修改的变量，比如
for i := 0; i —— 最终全打印 <code>5；应显式传参：time.AfterFunc(time.Second, func(val int) { fmt.Println(val) }(i)) -
time.AfterFunc返回*time.Timer，调用Stop()可随时取消，适用于用户取消订单、接口超时等场景 - 函数在新 goroutine 中执行，里面别放没
recover的 panic 风险操作，否则会 crash 整个程序 - 不要和
time.After混用：time.After只返回<-chan time.Time，不能直接调用，常见误写time.After(2*time.Second)()会编译失败
为什么不能用切片 + time.Sleep 实现延迟队列
网上很多“简单 DelayQueue”示例用 []Task 存任务、遍历比较 time.Now().Before(task.ExecuteTime) 再 time.Sleep，这种实现有硬伤：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每次
time.Sleep都阻塞当前 goroutine，一个队列只能串行处理，无法并发调度多个到期任务 - 无法响应外部取消信号，比如服务优雅退出时，
time.Sleep中的任务卡住不释放 - 插入新任务后要重排切片（按时间排序），
append+sort开销随任务数增长，1000 个任务插入一次就要 O(n log n) - 没有状态隔离，多个 goroutine 同时读写
TaskQueue切片会引发竞态，加锁又进一步降低吞吐
用 container/heap + 单 time.Timer 实现高并发延迟队列
核心思路是：所有任务按 dueAt 时间堆化，只起一个 goroutine 监听最近到期任务，Timer 到期后批量 pop 所有已到时间的任务并执行。
立即学习“go语言免费学习笔记（深入）”；
- 堆元素结构体必须实现
heap.Interface，关键是Less(i, j int) bool要比较dueAt字段，且用time.Time.Before而非<（避免纳秒溢出） - Timer 不要每个任务一个——每次
heap.Pop后，取新堆顶的dueAt，调用timer.Reset(nextDue.Sub(time.Now()))复用 - Pop 出的任务必须用
heap.Remove或heap.Pop显式从堆中移除，否则堆结构损坏，后续Fix也救不回来 - 任务逻辑尽量无状态；若需查状态（如“订单是否已支付”），用
sync.Map存 ID → 状态，别在堆里存指针指向外部 struct
容易被忽略的边界点：时间精度与系统负载影响
Go 的 time.Timer 底层依赖系统调用（如 epoll_wait 或 kqueue），实际触发时间受系统调度延迟影响，高负载下可能漂移 10–100ms。如果业务要求严格准时（如金融对账），不能只靠内存队列，得结合 Redis ZSET 或 RabbitMQ 延迟插件做兜底。另外，dueAt 字段建议统一用 time.Now().Add(x) 计算，别用绝对时间戳，避免时钟回拨导致任务永远不触发。
