必须用lua原子封装“查+删+标记”三步，因zrangebyscore与zrem分离调用存在时间窗口导致重复消费或永久丢任务，且score须统一为毫秒级整数并校准redis服务器时间。
直接用 redis.ZAdd + ZRangeByScore 轮询是错的起点——并发下必然重复消费或永久丢任务，必须用 Lua 原子封装「查 + 删 + 标记」三步，且所有时间戳统一为毫秒级整数并校准 Redis 服务器时间。
为什么 ZRANGEBYSCORE + ZREM 分开调用会翻车
两个命令之间存在不可消除的时间窗口：Worker A 查到 3 条到期消息，还没来得及 ZREM，Worker B 同样查到这 3 条，结果两边都开始处理；更糟的是，若 A 处理失败又没重入逻辑，B 也没拿到，任务就永久丢失。
- 常见错误现象：
ZRangeByScore返回空但消息该执行了？八成是score单位不一致（比如 Go 侧用time.Now().UnixMilli()存，Redis 查询却用秒级"1714000000"） - 时区漂移也会导致失效：用
redis-cli time对比本地date +%s，偏差超 1 秒就得同步 NTP -
ZREM不是原子删除：它只删 member，不保证你刚查到的那几条真被删了——可能已被其他 worker 先手抢走
ZPOPMIN 是解法但不是万能钥匙
ZPOPMIN 是 Redis 6.2+ 原生支持的原子出队命令，但它只管“弹出”，不管“后续怎么活”。生产环境单靠它上线三天必出问题。
- 它返回
ZSetZ结构，Score是毫秒时间戳，别忽略校验：用time.UnixMilli(int64(score))再比对当前时间，防系统时钟回拨或网络延迟误触发 - 默认只 pop 1 个，吞吐低；传
count参数（如 10）批量取，但注意：同一毫秒内插入多条任务，ZPOPMIN按 member 字典序返回——顺序不可控，业务扛不住压测 - pop 成功后必须立刻标记，否则 worker panic 就彻底丢任务；推荐用 Lua 把
ZPOPMIN和HSET delay_processing {member} {worker_id}绑定为一个原子操作
Lua 脚本必须覆盖“取→标→推”全链路
只封装“查+删”不够，只封装“取+标”也不行。真正难的不是第一次写对，而是节点宕机、consumer crash 后还能自己续上——所有状态变更都得有反向可逆路径，且每条路径都得进 Lua。
- 脚本里不能只
ZPOPMIN或ZRangeByScore，必须紧接着HSET到delay_processinghash，并返回完整 payload + score，Go 侧才能做幂等和重试 - 重试不是简单
ZADD回原 key：得用指数退避算新score，比如time.Now().Add(1 * time.Second).UnixMilli()，再把retry_count写进 payload JSON - 守护 goroutine 扫描
delay_processing时，回滚动作（ZADD+HDEL）必须也用 Lua 原子执行，否则ZADD成功但HDEL失败，就会无限循环重投
score 必须用毫秒，且不能依赖浮点精度
用秒级时间戳当 score 是最常见的时间精度翻车点。哪怕业务延迟要求是分钟级，也得用 time.Now().UnixMilli()。
- 秒级
score下，1 秒内插入 500 个任务，它们score全一样，ZRANGEBYSCORE返回结果不稳定，ZCOUNT会把整秒所有任务全算作“到期”，造成批量误触发 - 别用
float64(time.Since().Seconds())算score：有精度风险；也别用time.Now().UnixNano()：Redisscore是 double，纳秒转 float64 会丢失精度 - 所有
ZADD的score必须是整数毫秒，Go 侧传strconv.FormatInt(time.Now().UnixMilli(), 10)，别硬写死字符串"1714000000000"
最容易被忽略的其实是 TTL 和内存水位：delay_queue 这个 zset key 必须显式设 EXPIRE delay_queue 86400，否则失败任务、测试残留永久堆积；而 delay_processing hash 里堆满超时未清理的 entry，不是靠 HDEL 就能清干净的——得靠 Lua 原子回滚，且每次回滚前要 HEXISTS 二次确认。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
