Golang原生不支持分布式事务，因标准库和ORM仅保障单库ACID，跨服务HTTP调用脱离本地事务上下文；Saga模式是最佳实践，通过事件驱动、幂等补偿、超时重试与最终一致性实现可控分布式事务。
为什么 Golang 原生不支持分布式事务
Go 标准库的 database/sql 和所有主流 ORM（如 gorm、sqlc）只提供单数据库 ACID 保证，无法跨服务协调提交或回滚。一旦事务涉及 HTTP 调用另一个微服务（比如订单服务调用库存服务扣减），就脱离了本地事务上下文——defer tx.Rollback() 对远端服务毫无作用。
常见错误是试图用 Go 的 context.Context 透传事务 ID 并“手动控制”远端行为，这既无法保证原子性，也缺乏隔离性和持久性保障。
Saga 模式是最可行的落地选择
Saga 是由一系列本地事务组成的长活事务，每个步骤都配有对应的补偿操作。它不要求两阶段锁或全局协调器，在 Go 微服务中实现轻量、可控、可观测。
- 使用
github.com/ThreeDotsLabs/watermill或go-micro/v4/broker发布/订阅事件驱动 Saga，避免服务间强耦合 - 每个服务只对自己 DB 执行
INSERT或UPDATE，成功后发OrderCreatedEvent；失败则触发本地CompensateCreateOrder() - 补偿操作必须是幂等的：例如“恢复库存”应基于版本号或状态字段校验，而非简单
stock += 1 - 超时和重试需显式控制：用
time.AfterFunc启动补偿倒计时，用backoff.Retry控制重试间隔
不要在 Go 中硬套 TCC 或 2PC
TCC（Try-Confirm-Cancel）要求每个服务暴露三个接口，且 Confirm/Cancel 必须严格幂等并支持空回滚；2PC 需要独立事务协调器（如 Seata），但 Go 生态缺乏成熟、低侵入的协调器 SDK。
立即学习“go语言免费学习笔记（深入）”；
实际项目中容易踩的坑：
-
Confirm接口因网络延迟重复调用，导致余额被加两次——必须用唯一业务 ID +SELECT FOR UPDATE锁住记录再判断是否已确认 - 引入
seata-golang客户端后，HTTP 中间件自动注入XID头，但 Gin 的中间件执行顺序错乱会导致tx.Begin()在 handler 之前失效 - 2PC 的 Prepare 阶段若某服务宕机，协调器将长期卡在“不确定状态”，Go 服务没有内置的悬挂事务恢复机制
最终一致性 + 补偿查询是更务实的做法
对大多数业务（如电商下单、积分发放），接受秒级延迟的一致性，比强一致带来的复杂度和性能损耗更合理。
- 主流程只写本地 DB 并发事件，不等待下游结果；下游服务监听事件异步执行，失败时写入
failed_events表 - 单独起一个 Go worker（用
github.com/robfig/cron/v3）定时扫描失败事件，调用对应补偿函数 - 关键字段加
status和updated_at，前端查订单时若状态为processing且 5 秒未更新，可主动触发CheckOrderConsistency()查询各服务当前状态
真正难的不是写补偿逻辑，而是定义清楚“什么算不一致”以及“谁负责发现”。Go 没有银弹，但把状态机、事件日志、定时校验三者串起来，就能扛住大部分分布式场景的真实压力。
