time.AfterFunc不能当延迟队列用，它只适合单次、可丢失、无状态的短时延迟；高并发下易引发timer暴涨和goroutine泛滥，正确方案应按场景选Redis ZSET+Lua（持久化）、最小堆（动态控制）或时间轮（高频短延时）。
time.AfterFunc 不能当延迟队列用
它只适合单次、可丢失、无状态的短时延迟（比如 5 秒后打个日志），time.AfterFunc 底层复用 runtime 时间轮，但不支持动态增删、无法查询剩余时间、重启即丢任务。高并发下若每个任务都起一个 time.AfterFunc，timer 对象暴涨，GC 压力大，还可能因 goroutine 泛滥导致调度失准。
常见错误现象：time.Sleep 裸写在 goroutine 里模拟延迟——它阻塞当前协程、无法取消、不能共享、完全不是队列行为；或误以为 time.NewTimer + for-select 就是队列，结果频繁 new/stop 导致 timer 泄漏和漏触发。
单层时间轮是高频短延时任务的首选
业务场景如：风控超时判定（1~30 秒）、心跳续期（10~60 秒）、短时订单关单（2~5 分钟），每秒调度量达数百至数千时，单层时间轮比 Redis 轮询或堆更稳、更省资源。
-
interval设为业务容忍的最小延迟粒度，比如 500ms；槽位数 = 最大延迟 ÷interval（如最大支持 10 分钟，则需 1200 个槽） - 每个槽是
*list.List，任务按pos（取模位置）和cycle（滚动圈数）落槽，tick()只移动curSlot指针，O(1) 开销 - 别在
task函数里做阻塞操作：HTTP 调用、DB 写入必须交给 worker pool 异步处理，否则卡住整个 tick goroutine - 重启会丢任务，必须搭配 DB 或 WAL 日志落盘；恢复时按
executeAt重算pos/cycle并 reload
Redis ZSET + Lua 是生产环境最稳的兜底方案
时间轮纯内存，扛不住进程崩溃；ZSET 提供持久化、多实例共享、天然排序，是中小项目上线第一选择。
关键点不在“用不用 Redis”，而在原子性保障：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- score 必须用
time.Now().UnixMilli()，不能用Unix()（秒级精度易一次扫出几百条，OOM 风险） - Lua 脚本必须三步原子完成：
ZRANGEBYSCORE查、ZREM删、LPUSH推入待执行 LIST；分开调用必然重复消费 - 轮询前先
ZCOUNT delay_zset -inf ARGV[1]，有数据再扫，避免空轮询压 Redis - 消息体带唯一
id字段，消费端用sync.Map或 DB 记录已处理 ID，Lua 不是银弹，网络中断仍可能漏删
堆实现适合中低频、需精确控制的任务管理
当你要支持「随机删除」「重置到期时间」「批量查某时间段任务」时，container/heap 比时间轮更灵活，但不适合每秒上千任务的场景。
注意几个硬伤：
- 堆元素结构体必须实现
heap.Interface，Less(i, j int) bool要严格比较DueAt字段，别错写成After或漏判相等 - 别存外部状态指针（如指向某个 map 的 key），goroutine 并发修改会导致竞态；任务逻辑尽量无状态，或用
sync.Map配合 ID 查 - 只持有一个
*time.Timer，每次堆变更就Reset()它指向新堆顶；堆空了就Stop()，别在 for 循环里反复time.NewTimer -
heap.Pop或heap.Remove后必须立即更新元素内部下标字段，否则后续Fix失效，堆结构错乱不可逆
真正难的不是实现，是选型时对「精度、持久性、扩展性、运维成本」的权衡——时间轮快但易丢，ZSET 稳但要防 Lua 断电，堆灵活但 GC 压力随任务数线性涨。没银弹，只有匹配场景的解法。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
