Go服务端不做幂等控制必然导致重复写入，必须用redis.SetNX（带EX过期时间）做首道拦截，key需拼业务上下文如idempotent:{user_id}:{idempotencyKey}，value存trace_id，context透传标识，Redis故障返回503，DB唯一索引兜底。
Go 服务端不做幂等控制，重复请求就一定会写多条数据——这不是概率问题，是确定性行为。HTTP 协议不保证幂等，框架（gin/echo/net/http）也不管这事，得你自己在关键路径上卡住。
redis.SetNX 必须带 EX 过期时间，不能只设 key
常见错误现象：SetNX 成功后业务 panic 或网络中断，key 永远留在 Redis 里，后续所有重试都被拦截，用户看到“重复提交”但实际没成功。
-
SetNX命令必须搭配EX参数，建议设为业务最长处理耗时 + 安全余量（如支付类接口设3600秒） - 别用
SET key value NX拆成两步：先EXISTS再SET，存在竞态窗口；也别SETNX后补EXPIRE，第二步失败就锁死 - Go-Redis v9 推荐直接调
rdb.SetNX(ctx, key, value, ttl)，它底层自动拼NX EX参数 - value 别存空字符串，建议填
trace_id或客户端传的X-Idempotency-Key，方便日志对齐
key 构造要拼业务上下文，不能裸用客户端 header
只用 X-Idempotency-Key 作 key，会导致不同用户、不同订单复用同一 key，引发误拒或漏判。
- 推荐格式：
idempotent:{user_id}:{idempotencyKey}，或更严谨点：idempotent:{business_type}:{user_id}:{idempotencyKey} - 从
c.Request.Header.Get("X-Idempotency-Key")取值，为空应直接拒绝，不默认生成 - 取到后必须正则校验格式，比如
^[a-zA-Z0-9_-]{12,64}$，防 Redis key 注入 - 别哈希整个请求 body——顺序、空格、gzip 编码都会导致哈希不一致；客户端可控的稳定标识才是可靠指纹
context 透传幂等标识，别用闭包变量存
Gin/Echo 中间件若用局部变量或闭包存 idempotent_key，并发请求会互相覆盖，一个请求的 key 被另一个覆盖，校验完全失效。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 中间件里解析完 header 后，必须通过
ctx = context.WithValue(ctx, "idempotent_key", key)绑定到 context - handler 里统一用
ctx.Value("idempotent_key")拿，而不是重新解析 header - 别在事务中间做幂等校验——DB 成功但 Redis 失败，下次请求因 key 存在被误拒；校验必须放在最外层入口
- Redis 故障时不能静默 fallback 到“放行”，得返回
503 Service Unavailable，否则幂等语义彻底崩塌
数据库唯一索引是兜底，不是主方案
Redis 校验只是第一道防线，它挡不住缓存击穿、集群故障、客户端绕过 header 等场景。DB 层唯一索引才是不可绕过的最后屏障。
- 建联合唯一索引，字段必须含业务维度，比如
UNIQUE INDEX idx_user_id_idempotency_key (user_id, idempotency_key) - 别只用
idempotency_key单字段索引——跨用户冲突风险高，且宽字段拖慢写性能 - 捕获唯一冲突错误要精准：
mysql.ErrDupEntry或pgx.ErrCodeUniqueViolation，不是所有 error 都能当“已存在”处理 - 冲突后别直接抛错，要查一次 DB 确认是否真已存在；部分执行已发生（如发了消息），需按状态机补救，不能简单返回 success
真正难的不是写几行 SetNX，而是把 key 的生命周期、context 的穿透边界、Redis 和 DB 的协作节奏全理清楚——少一个环节，幂等就形同虚设。
