Go分布式系统幂等性需用唯一业务ID+状态机（Redis原子操作）+DB唯一索引兜底，配合context超时查询与异步副作用拆分，覆盖缓存失效、网络分区等边界场景。
在Go语言编写的分布式系统中，实现接口幂等性不是加个“重试机制”就能解决的，核心在于识别重复请求、隔离执行状态、并确保多次调用产生相同结果——不依赖外部时序或临时锁。
用唯一业务ID + 状态机控制执行边界
每个外部请求（如支付、下单）必须携带客户端生成的、全局唯一的业务ID（如trace_id或biz_id），服务端将其作为幂等键存入Redis或本地缓存（带过期时间）。首次请求写入状态为processing，成功后更新为success；失败则设为failed。后续同ID请求直接查状态，success则返回原结果，failed可选择重试或拒绝。
- Go中可用
redis.SetNX()原子写入初始状态，避免竞态 - 状态更新务必用Lua脚本或Redis事务保证原子性，防止“查-判-写”中间被覆盖
- 业务ID不应由服务端生成（否则重试时无法复用），推荐客户端用UUIDv4或Snowflake+时间戳拼接
数据库层面用唯一约束兜底
仅靠缓存无法100%防重，尤其在缓存失效、网络分区或节点重启时。关键操作（如插入订单、扣减库存）应在DB表中添加唯一索引，例如：UNIQUE KEY `uk_user_id_order_type` (`user_id`, `order_type`, `external_ref_id`)。Go代码中捕获mysql.ErrDuplicateEntry或PostgreSQL的unique_violation错误，转为幂等响应。
- 索引字段要覆盖业务语义，不能只建在
external_ref_id单列上（防不了同一用户重复提交不同业务） - 不要用“先查再插”做判断——分布式下查和插之间存在时间窗口，必然导致脏写
- 错误处理需区分：唯一冲突是幂等成功；主键冲突、外键失败等属于真实业务异常，需告警而非静默忽略
利用Go的context与超时避免“假成功”
分布式调用中，网络超时≠操作失败。若上游因超时重发，而下游实际已执行完毕，就会造成重复。因此，所有RPC调用必须携带context.WithTimeout，并在超时后主动发起幂等查询（查DB或缓存），确认最终状态，而非简单重试。
立即学习“go语言免费学习笔记（深入）”；
- HTTP服务可用
X-Request-ID头透传业务ID，中间件自动注入到context.Value中，便于日志追踪和幂等判定 - gRPC场景建议在metadata里塞
biz_id，服务端拦截器统一提取并绑定到context - 避免在超时后无条件重试——应先查后决，查不到结果才按策略重试（如指数退避+最大次数限制）
幂等不是万能的，要明确边界和降级方案
不是所有操作都能天然幂等。例如“发短信”、“发邮件”、“调第三方支付回调”，这类副作用操作必须拆分为两阶段：先落库标记“待通知”，再由后台任务异步推送，并记录推送结果。失败时只重推未成功项，且对同一通知ID去重。
- 对无法回滚的操作（如银行转账），幂等设计重点转向“防重复发起”，而非“重复执行无害”
- 上线前用混沌工程模拟网络延迟、Redis宕机、进程OOM等场景，验证幂等逻辑是否仍生效
- 监控必须覆盖：幂等命中率、状态不一致告警（如DB有记录但缓存无状态）、重复请求量突增
