Go微服务幂等性需业务层显式设计，核心是idempotency-key+状态机+幂等存储；仅校验HTTP头key会漏掉重启、分布式、下游失败等场景；必须持久化状态，优先Redis原子占位，高一致要求则DB事务落库；key须客户端生成且全局唯一；状态机须三态（pending/success/failed）配合CAS；结果缓存需含完整响应并设TTL与版本控制。
Go 微服务接口的幂等性不能靠框架自动保证，必须在业务逻辑层显式设计；没有银弹，idempotency-key + 状态机 + 幂等存储是目前最稳妥的组合。
为什么 http.Header.Get("Idempotency-Key") 不能单独用
仅校验请求头里的 Idempotency-Key 并拒绝重复提交，看似简单，但会漏掉关键场景：服务重启后内存状态丢失、分布式节点间无共享状态、下游调用失败但上游已返回成功。它只防“重放”，不防“重复执行”。
- 客户端可能因超时重试，带相同
Idempotency-Key的请求落到不同实例 - 若只用本地 map 缓存 key，实例扩容或重启即失效，导致同一 key 被二次执行
- HTTP 层拦截无法感知业务是否真正完成（例如 DB 写入成功但响应丢包）
必须持久化幂等状态：选 Redis 还是 DB？
优先用 Redis 存幂等记录（key = idempotency:{key}），因其支持原子写入 + 过期时间 + 高吞吐；但最终一致性要求高的场景（如资金扣减），需落库并和业务操作同事务。
-
Redis：用SET idempotency:abc123 "processing" EX 300 NX原子判断并占位，避免竞态 - 若 Redis 不可用，降级策略不是跳过校验，而是同步写 DB 的
idempotency_records表（含key、status、result_json、expired_at） - 不要用 MySQL 的唯一索引代替状态机——插入失败 ≠ 执行成功，需额外查状态确认结果
idempotency-key 的生成必须由客户端控制
服务端生成 key 会导致客户端无法重试，违背幂等设计初衷；key 必须具备业务语义且全局唯一，比如：pay_{order_id}_{timestamp}_{nonce} 或 UUIDv4。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 禁止用随机数或时间戳单独作 key（冲突概率高）
- 客户端应在首次请求前就确定 key，并在所有重试中复用同一个值
- 服务端需校验 key 长度（建议 16–64 字符）、字符集（只允许字母、数字、下划线、短横线），防止注入或存储溢出
- 若业务天然有唯一标识（如订单创建请求中的
order_no），可直接用作 key，省去客户端额外生成
状态机比布尔标记更安全："pending" → "success" → "failed"
只存一个 is_executed 布尔字段，无法区分“执行中”和“已成功”，会导致并发请求卡死或错误返回。必须用三态（或四态加 "canceled"）配合 CAS 更新。
- 首次请求：尝试插入
status = "pending"，成功则执行业务逻辑，完成后用UPDATE ... SET status = "success", result = ? WHERE key = ? AND status = "pending" - 重复请求：查到
status = "success"直接返回缓存结果；查到"failed"则原样返回错误；查到"pending"可选择等待（轮询）或快速失败（返回 409 Conflict） - 务必给幂等记录设 TTL（如 24 小时），避免冷数据堆积；TTL 要长于最长业务链路耗时（含人工干预）
最容易被忽略的是“结果缓存”的一致性：返回的 result_json 必须是完整响应体序列化结果，而非数据库快照——因为响应可能含动态字段（如时间戳、签名）。一旦业务逻辑变更，旧幂等记录的缓存结果可能不再合法，需要版本号或清失效机制。
