不能直接用ZADD+ZRANGEBYSCORE做延时队列，因ZSET无自动触发能力，ZRANGEBYSCORE仅查询需手动ZREM、执行与重试；多消费者并发查询会导致重复拉取，须用ZPOPMIN（6.2+）或Lua脚本保证原子性。
为什么不能直接用 ZADD + ZRANGEBYSCORE 做延时队列
因为 Redis 的有序集合没有“自动触发”能力，ZRANGEBYSCORE 只是查，查完还得手动 ZREM、执行任务、处理失败重试——这些逻辑全得自己兜底。更关键的是：多个消费者并发 ZRANGEBYSCORE 会重复拉取同一任务，不加锁就会丢任务或重复执行。
常见错误现象：ZRANGEBYSCORE 拉到任务后没来得及 ZREM 就崩溃，下次又拉一遍；或者两个 worker 同时拉到同一个 score 最小的元素，都去执行。
- 必须用
ZPOPMIN（Redis 6.2+）或EVAL原子脚本替代多次命令组合 - 若 Redis 版本 ZRANGEBYSCORE +
ZREM，否则无法保证原子性 -
ZPOPMIN返回值包含 member 和 score，别只取 member 忽略时间戳校验
如何用 ZPOPMIN 实现安全出队
Go 客户端（如 github.com/redis/go-redis/v9）对 ZPOPMIN 的封装是 ZPopMin 方法，但注意它默认只 pop 1 个，且不带超时——延时队列需要“等待到期”，所以得轮询 + sleep，或结合 BLPOP 做伪阻塞（不推荐），更稳妥的是用定时器驱动。
使用场景：每 100ms 扫描一次，pop 出所有 score ≤ now 的任务，批量处理。
- 调用
ZPopMin时传入count参数（比如 10），避免单次只取一个导致吞吐低 - pop 出来的每个
ZSetZ结构里，Score是时间戳（毫秒），务必用time.UnixMilli(int64(score))校验是否真的到期，防止系统时钟回拨或网络延迟造成误执行 - pop 成功后立即写入临时集合（如
processing:{task_id}）或用SETNX做幂等标记，防 crash 后重复消费
任务失败后怎么重新入队
失败重试不是简单 ZADD 回原 key，否则会覆盖原始 score（即原定时间），必须按退避策略计算新 score。比如指数退避：第一次重试 +1s，第二次 +2s，第三次 +4s……
参数差异：ZADD 的 score 必须是毫秒时间戳（不是相对秒数），别错用 time.Now().Add(2 * time.Second).Unix()（那是秒级，精度不够）。
- 重试时用
time.Now().Add(duration).UnixMilli()算 score，确保毫秒精度 - 记录重试次数到任务 payload 里（比如 JSON 字段
retry_count），避免无限循环；超过阈值就转存到死信队列dlq:delay - 不要在重试时修改原始 member 内容，而是整个 payload 重新序列化，否则可能因结构变更引发反序列化失败
Go 代码里怎么组织这个循环不泄漏 goroutine
核心是控制扫描频率和退出信号。用 time.Ticker 驱动，但别直接 go func() { for range ticker.C } —— 没有退出机制，defer 不会触发，连接和 timer 都会泄漏。
性能影响：ticker 间隔太短（如 10ms）会导致 Redis QPS 暴涨；太长（如 5s）则延时毛刺明显。实测 100–500ms 是平衡点。
- 启动时用
context.WithCancel创建可取消 ctx，把 ticker 放进 for-select 循环，监听ctx.Done() - 每次 pop 前检查
ctx.Err() != nil，及时 break - 连接 Redis 用
redis.NewClient并设置PoolSize（建议 10–20），别为每次 pop 新建 client
容易被忽略的是：任务执行函数本身可能 panic，必须用 recover 捕获，否则整个 goroutine 退出，后续任务再也不会被扫描到。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
