Go微服务中database/sql的tx.Commit()无法保证跨服务一致性，因其仅作用于单个数据库连接，而Saga模式通过本地事务加补偿操作实现最终一致性。
Go 微服务里没法靠 database/sql 的 tx.Commit() 保证跨服务一致性——这不是你代码写得不够好，而是它根本就不是为这事设计的。
为什么 tx.Commit() 在微服务里完全失效
单个服务内用 sql.Tx 没问题，但订单服务扣库存、账户服务减余额、物流服务建运单，这三个操作分布在不同进程、不同数据库、甚至不同云区域。tx.Commit() 只能管住本机一个 DB 连接，对其他服务的数据库或 HTTP 接口毫无作用。
- 常见错误现象：订单创建成功，但库存没扣；用户扣款成功，但通知没发——日志里只看到一方成功、另一方超时或失败，却找不到回滚入口
- 硬把多个
http.Post()包进defer tx.Rollback()是典型误区：第二个服务的 DB 操作根本不在这个事务上下文中 - 用
context.Context透传事务 ID 并“手动控制”远端行为，既无法保证原子性，也缺乏隔离性和持久性保障
Saga 模式是唯一可落地的方案
Saga 把长事务拆成一系列本地事务，每个步骤配补偿操作，失败时反向执行。它不要求全局锁或协调器，天然适配 Go 的并发模型和轻量服务设计。
- 必须用状态机管理流程：把当前步骤、上一步、下一步都存进本地 DB（字段如
status、step、compensated_step），别用内存或 Redis 缓存进度——节点重启就丢 - 所有跨服务写操作必须拆解为「本地事务 + 外发事件」两步：本地事务成功后才发消息，推荐用 PostgreSQL 的
LISTEN/NOTIFY或 Kafka 事务性 producer - 补偿接口必须幂等：
RefundBalance(ctx, orderID, amount)内部先查是否已退过；RestoreStock(ctx, skuID)应基于版本号或状态字段校验，而非简单stock += 1 - 超时和重试需显式控制：用
time.AfterFunc启动补偿倒计时，用backoff.Retry控制重试间隔，避免指数退避打爆下游
别碰 TCC 和 2PC，除非你真有金融级强一致需求
TCC 要求每个服务暴露 Try/Confirm/Cancel 三个接口，Confirm/Cancel 必须严格幂等并支持空回滚；2PC 需要独立事务协调器（如 Seata），但 Go 生态缺乏成熟、低侵入的 SDK。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- Confirm 接口因网络延迟重复调用，导致余额被加两次——必须用唯一业务 ID +
SELECT FOR UPDATE锁住记录再判断是否已确认 - 引入
seata-golang客户端后，HTTP 中间件自动注入XID头，但 Gin 的中间件执行顺序错乱会导致tx.Begin()在 handler 之前失效 - 2PC 的 Prepare 阶段若某服务宕机，协调器将长期卡在“不确定状态”，Go 服务没有内置的悬挂事务恢复机制
最终一致性 + 补偿查询才是日常业务的底线
对电商下单、积分发放这类场景，接受秒级延迟的一致性，比强一致带来的复杂度和性能损耗更合理。
- 主流程只写本地 DB 并发事件，不等待下游结果；下游服务监听事件异步执行，失败时写入
failed_events表 - 搭配定时对账任务扫描不一致状态（比如订单已支付但库存未扣），主动触发补偿或告警
- 用
Temporal或Cadence管理 Saga 流程：自动处理重试、超时、补偿调度，大幅降低手动编排复杂度
真正容易被忽略的，是补偿逻辑的幂等边界和状态落库时机——不是“做了补偿”，而是“补偿能被反复执行且不改变结果”，且每步状态必须落库、带 version 字段防覆盖，否则一次重启或重试就能让整个事务链断裂。
