单纯加重试不能解决数据不一致问题，它只放大错误；真正有效的是区分“调用失败”与“业务失败”，并以幂等设计和状态机兜底，辅以异步对账机制。
单纯加重试不能解决数据不一致问题——它只放大错误。真正起作用的是把“调用失败”和“业务失败”区分开，再用幂等+状态机兜底。
为什么重试会让数据不一致更严重
网络抖动导致的超时或连接中断，Go 服务收到的往往是 context.DeadlineExceeded 或 codes.Unavailable，但此时下游可能已成功处理请求（比如转账扣款已写库），只是响应没回来。如果上层无条件重试，就会重复扣款。
- HTTP/2 流复位、TCP RST、LB 静默丢包，都可能让请求“半成功”
-
grpc.Dial()返回的*grpc.ClientConn是异步建立的，第一次client.DoSomething(ctx, req)才暴露真实状态，此时 ctx 已过期也拦不住下游执行 - 用
viper.Unmarshal加载配置时静默忽略字段，可能导致重试策略参数（如max_retries）根本没生效，你以为设了 3 次，实际是默认 0 次
必须实现的三个业务层控制点
协议层超时和重试只是基础，数据一致性必须靠业务逻辑显式收敛：
- 每个对外 RPC 接口必须带唯一
idempotency_key字段（例如 UUIDv4），由调用方生成并透传；服务端用该 key 在 DB 建唯一索引或 Redis SETNX 校验是否已处理 - 状态机驱动：不要用“成功/失败”二值判断，改用
pending → processing → succeeded | failed | timeout多态。超时后不是立即重试，而是查状态再决定动作 - 所有长耗时操作必须在入口处检查
ctx.Done()，并在关键节点（如 DB commit 前）再次检查；否则客户端取消了，服务端还在提交，状态彻底失联
最容易被跳过的兜底动作
即使上面都做了，仍可能因网络分区、时钟漂移或中间件 bug 导致状态不一致。这时需要异步对账：
立即学习“go语言免费学习笔记（深入）”；
- 核心业务表必须带
created_at、updated_at、version三字段，且version在每次更新时原子自增 - 每小时跑一次对账 job，扫描
status = 'pending'且updated_at < now() - 5m的记录，调用下游GetOrderStatus(id)补全状态 - 对账失败不 panic，记 error log 并发告警；避免用
log.Fatal或未 recover 的 panic 导致整个 job 崩溃，漏掉后续批次
真正的难点不在代码怎么写，而在所有模块是否共用同一套 idempotency key 生成规则、同一套状态流转定义、同一套对账时间窗口——配置漂移会让这些机制在某个环境里形同虚设。
