time.now().unixnano() 不适合做幂等 key，因其纳秒级时间戳在高并发或容器环境下易重复，且脱离业务上下文，无法区分真实重试与新请求。
为什么 time.Now().UnixNano() 不适合做幂等 key
时间戳精度再高，也挡不住并发请求在同一纳秒抵达——尤其在本地测试或容器内，系统时钟可能被调度器压缩，time.Now().UnixNano() 会重复。更糟的是，它完全不绑定业务上下文，用户重试、前端刷新、网关重发都会生成新时间戳，导致“本该幂等”的请求被当成新请求处理。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用业务唯一标识拼接，比如
"order_create:" + userID + ":" + orderID，不是为了“全局唯一”，而是确保同一笔订单的多次提交命中同一个 key - 避免把 HTTP 请求头（如
X-Request-ID）直接当幂等 key——它由客户端或网关生成，不可信；只可作为日志追踪字段，不参与逻辑判断 - 如果必须用时间，至少取到秒级 + 用户 ID + 操作类型，例如
"pay_retry:" + userID + ":" + strconv.FormatInt(time.Now().Unix(), 10)，但依然不如业务 ID 可靠
Redis SETNX 配合 EXPIRE 为什么不能拆成两条命令
用 SETNX 判断存在，再用 EXPIRE 设过期，看似合理，实则存在竞态：中间若服务崩溃或网络中断，key 就永久残留，后续所有请求都被拒绝，等于服务雪崩。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须用 Redis 2.6.12+ 的原子命令：
SET key value EX 300 NX，其中NX表示仅当 key 不存在时设置，EX 300表示 300 秒后自动过期，整个操作不可分割 - Go 客户端推荐用
redis.Client.Set(ctx, key, value, ttl)并传入redis.SetArgs{NX: true}（基于github.com/redis/go-redis/v9），它底层自动拼装原子命令 - 不要自己拼字符串发
SET命令——容易漏掉空格、大小写错误，且不同 Redis 版本对参数顺序要求不同
如何让幂等逻辑不污染核心业务代码
把校验塞进 handler 里，很快就会变成 “if err := checkIdempotent(); err != nil { return }” 堆砌，一旦要加审计、降级、监控，就得改所有接口函数。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 封装成 Gin/Mux 中间件或独立函数，例如
idempotent.Middleware("order_submit", idempotent.RedisStore{Client: rdb})，只关心 key 构造和存储动作，不碰业务逻辑 - 幂等结果应返回明确状态：
idempotent.StatusAlreadyHandled（已成功）、idempotent.StatusProcessing（正在处理中）、idempotent.StatusNew（首次请求），让上层决定是直接返回缓存结果，还是继续执行 - 关键点：幂等存储的 value 必须包含原始请求的响应摘要（比如 JSON 序列化的成功结果），否则“已存在”时你无法安全返回一致数据——别指望每次重查 DB
DB 写操作失败后，幂等 key 该怎么清理
不是所有失败都需要删 key。比如 DB 主键冲突、唯一索引报错，说明业务已发生，此时删 key 会导致下次重试变成“新请求”，重复插入；但如果是网络超时、事务回滚，又得删 key，否则永远卡住。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 只在明确知道“本次操作未产生任何副作用”时才删 key，典型场景：DB 连接失败、context 超时、预校验不通过
- 不要在 defer 里无条件
DEL——万一 DB 成功但响应没发出去，用户重试，你就把已生效的记录“解锁”了 - 更稳妥的做法是：用带版本号的幂等记录表（如
idempotent_records(key, status, result_json, version)），status 字段区分pending/success/failed_no_effect，清理逻辑由状态机驱动，而不是靠 delete
真正难的从来不是“怎么设 key”，而是“怎么定义一次操作是否真的完成”。数据库 commit 成功、消息发出、第三方回调收到……这些边界点稍有偏差，幂等就从保险丝变成定时炸弹。
