Go语言无开箱即用分布式事务支持，本质是选型+编排+防错；database/sql和gorm仅支持单库ACID，跨服务HTTP调用无法回滚，必须靠幂等接口、本地消息表、状态校验与分布式锁保障最终一致性。
Go 语言没有分布式事务的“开箱即用”支持，所谓“处理策略”本质是选型 + 编排 + 防错，而不是找一个函数调用就完事。直接套用 dtmcli.SagaNew 或 seata-go 客户端，但不处理幂等、状态校验、消息投递可靠性，反而会让问题更难定位。
为什么 database/sql 和 gorm 无法跨服务保证原子性
标准库和 ORM 只能对单个数据库连接做 tx.Commit() 或 tx.Rollback()，一旦涉及 HTTP 调用另一个服务（比如订单服务调用库存服务），远端的数据库操作完全不受当前事务控制。defer tx.Rollback() 对远程服务无效，网络超时、服务宕机、重试失败都会导致状态撕裂。
常见错误现象：
- 订单写入成功，库存扣减失败 → 用户看到下单成功，但库存没变
- 库存扣减成功，订单写入因 panic 回滚 → 库存被占，订单不存在
- HTTP 中间件自动注入
XID头，但 Gin 的中间件顺序错乱，tx.Begin()在 handler 执行前就结束了
本地消息表比直连 Kafka/RocketMQ 更可控
直连 MQ 的 Producer.Send() 成功只代表消息进了 broker，不代表下游消费成功，也不代表业务逻辑执行成功。一旦消费者 crash 且没配置死信队列或人工干预，就会卡在“已发未处理”状态，数据长期不一致。
立即学习“go语言免费学习笔记（深入）”；
本地消息表把消息持久化到业务库同一事务中，靠定时任务驱动投递，状态可查、可人工修正：
- 消息表必须和业务表在同一个数据库实例，否则无法保证原子写入
-
INSERT INTO message (biz_id, content, status) VALUES (?, ?, 'pending')必须紧跟在业务 SQL 后面，不能用异步goroutine包裹 - 投递任务要加分布式锁，例如
Redis SET lock:msg:dispatch NX EX 30，避免多个实例重复扫描同一批消息
Saga 补偿操作必须查状态再决策，不能简单反向执行
很多人写补偿函数只传 ID，然后无脑“加库存”或“回滚余额”，但真实场景中：订单可能已被用户取消、库存可能已被其他订单占用、商品可能已下架——直接加库存会超卖，直接回滚余额会导致资金错乱。
正确姿势：
- 补偿函数签名里带
context.Context和原始请求快照（如req *CreateOrderRequest），不是只传orderID - 补偿前先查最新状态：
SELECT status, stock_version FROM orders WHERE id = ? FOR UPDATE - 只在满足条件时执行补偿，例如 “订单状态为
created且库存版本未变更” 才恢复库存
DTM 和 seata-go 的选型关键不在功能，而在工程落地成本
DTM 更适合中小团队快速落地：dtmcli.SagaNew 两行代码发起编排，自带控制台、HTTP/gRPC 接口、跨语言支持，对 go-zero、Kratos 有开箱即用集成；失败自动触发补偿链，但前提是所有参与服务都实现幂等接口。
Seata-Go 更适合已有 Java 微服务集群的统一治理：它依赖 seata-server 协调器，启动失败常见报错是 no available service 或 failed to register branch，本质是注册中心不通或 service.vgroupMapping 分组名不匹配；2026 年主流用 1.8+ 版本，必须确认客户端与 server 兼容。
两者都绕不开的核心约束：
- 所有参与服务的数据库操作必须包装成幂等接口，否则
Confirm或Try重试会写脏数据 - 本地消息表 + 状态校验 + 分布式锁，这三者缺一不可，否则补偿链本身就会成为新的不一致源头
最易被忽略的一点：Saga 不是“自动回滚”，而是“手动编排 + 显式状态判断”。哪怕用了 DTM，如果补偿函数里没查订单当前状态就直接 UPDATE stock += 1，上线后超卖问题只会更隐蔽、更难复现。
