Redis ZSET+Lua是中小项目最稳的延迟队列方案，核心是用毫秒时间戳作score、消息体作member，并通过Lua原子执行查删推三步，避免竞态导致的重复消费或丢失。
别用 time.Sleep 模拟延迟队列，也别指望 time.AfterFunc 能当队列用——它只是单次回调注册，进程一挂全丢，无法并发、不可持久、不支持动态增删。真要落地，得按场景选方案：强一致选 Redis ZSET + Lua，轻量单机用最小堆 + 单 *time.Timer 复用，已有 RabbitMQ 就启用插件，但得盯死单位和兼容性。
Redis ZSET + Lua 是中小项目最稳的起点
核心是把毫秒时间戳当 score，消息体当 member，再用 Lua 原子执行「查到期项 → 删除 → 推入待消费 LIST」三步。不封进 Lua，多个 worker 同时扫同一窗口必重复投递。
-
score必须用time.Now().UnixMilli()，别用Unix()：秒级精度在高并发下容易一次拉出几百条，内存爆炸 - Lua 脚本里
KEYS[1]是 ZSET key（如"delay_zset:order"），KEYS[2]是目标 LIST key（如"ready_list:order"），ARGV[1]是当前毫秒时间戳字符串 - 轮询间隔设 500ms～1s，别用 100ms：先
ZCOUNT delay_zset -inf ARGV[1]判断有无到期项，再扫，省连接和 CPU - 消息体必须带唯一
msg_id字段，消费端做幂等——Lua 原子性不是银弹，网络分区或脚本中断时仍可能漏删 - 长期堆积要防膨胀：给 ZSET key 加
EXPIRE，或定期ZREMRANGEBYSCORE delay_zset -inf (now-86400000)清理过期项
container/heap + 单 *time.Timer 适合单机轻量调度
适用于任务生命周期短、不跨进程、失败不重试的场景，比如缓存刷新、健康检查、本地通知。它不解决持久化和水平扩展，但零依赖、低延迟、可控性强。
- 堆元素结构体必须实现
heap.Interface，Less(i, j int) bool比较的是DueAt字段，不是 ID 或状态 - 只持有一个
*time.Timer，每次堆变更后调用timer.Reset(nextDue)；Reset返回false表示已触发或已Stop，此时必须先timer.Stop()再time.NewTimer() -
select收到timer.C后，要循环heap.Pop所有DueAt 的任务，不止一个 - 任务函数里别做阻塞操作（如 DB 写入、HTTP 请求），应转给
worker pool异步处理 - goroutine panic 会中断整个调度循环，必须用
recover包裹执行体
RabbitMQ rabbitmq_delayed_message_exchange 插件要注意单位和版本
已有 AMQP 架构时可快速接入，但插件非官方内置，不同 RabbitMQ 版本行为不一致，升级集群时容易失效。它不是“把消息塞进去等 TTL 过期”，而是在路由阶段拦截，未到时间根本不出队。
立即学习“go语言免费学习笔记（深入）”；
- Exchange 类型必须声明为
"x-delayed-message"，且args中指定"x-delayed-type"（如"direct"） -
x-delayheader 单位是毫秒，不是秒："5"就是延迟 5ms，手抖写错就真成毛刺了 - 消息不会进死信队列再转发——没到时间它压根不参与路由，所以不存在 TTL 过期逻辑
- 插件启用后，发消息时加
header["x-delay"] = "30000"即可，消费端无需改任何逻辑 - 务必验证你用的 RabbitMQ 版本是否完全兼容该插件，2026 年主流版本中，3.11.x 和 3.12.x 对插件支持仍有细微差异
真正难的不是选哪个方案，而是判断业务能不能容忍重启丢任务、要不要跨节点调度、有没有现成中间件团队兜底。Redis 方案看着简单，但 Lua 脚本写错一行就卡死整个轮询；最小堆看似干净，但一旦堆结构乱了（比如忘了 heap.Fix），后续所有 Pop 都返回错的任务。这些细节不踩一遍坑，很难真正用稳。
