Go语言无内置分布式事务支持，需通过Saga模式、本地消息表、DTM/Seata-Golang等工具实现可控最终一致性，核心是状态机、幂等、补偿与可靠消息。
Go 语言本身不提供分布式事务的内置支持，但可以通过成熟的模式和工具在微服务架构中可靠地实现最终一致性。关键不是“强一致”，而是“可控的最终一致”——用补偿、幂等、状态机和可靠消息来兜底。
基于 Saga 模式的事务编排
Saga 是微服务中最常用且 Go 生态支持良好的分布式事务模式。它把一个长事务拆成多个本地事务，每个步骤都有对应的补偿操作。
- 正向操作失败时，按反序执行已成功步骤的补偿（如：创建订单 → 扣库存 → 支付；若支付失败，则先退款（无），再恢复库存，最后取消订单）
- 推荐使用 状态机驱动：用数据库记录事务当前阶段（如 pending → reserved → paid → done），避免重复执行或漏执行
- Go 中可用 Watermill 或 kafka-go 发布/订阅事件，配合 pgx + PostgreSQL 的 upsert 和 RETURNING 实现原子性状态更新
可靠消息 + 本地消息表（Local Message Table）
解决“业务操作与发消息不同步”的经典方案：在同一个本地事务中，写业务数据 + 写消息记录，再由独立的投递服务异步发到 MQ。
- 消息表结构建议包含：
id, topic, payload, status (pending/sent/failed), created_at, next_retry_at - 用 goroutine + ticker 定期扫描待发送消息（加 for update 跳过并发处理），失败则指数退避重试
- 消费者端必须实现 幂等写入（如用唯一业务键 + UPSERT，或 Redis SETNX 校验）
使用 Seata-Golang 或 DTM 的客户端接入
如果你需要更接近 AT（自动补偿）模型的体验，可考虑对接成熟分布式事务中间件：
立即学习“go语言免费学习笔记（深入）”；
- DTM（国产，Go 编写，文档友好）：提供 HTTP/gRPC 接口，支持 Saga、TCC、XA；Go 客户端 dtmcli 简单易集成，一行代码开启全局事务
- Seata-Golang：适配 Seata Server 的 Go 客户端，支持 AT/TCC 模式，适合已有 Java+Seata 技术栈的混合场景
- 注意：这类中间件会引入额外运维成本，建议从 Saga 起步，再按需升级
规避事务：设计上减少跨服务强依赖
最有效的“分布式事务方案”，其实是让它不发生。
- 用 CQRS 拆分读写模型：写服务只管状态变更并发事件，读服务异步构建聚合视图
- 允许短暂不一致：比如下单成功后显示“支付中”，而不是阻塞等待支付结果
- 核心数据尽量收口：用户余额、库存等敏感状态，统一由专用服务管理，其他服务只通过 API 间接操作
基本上就这些。Go 微服务做分布式事务，不靠框架黑盒，而靠清晰的状态边界、可追溯的日志、确定性的补偿逻辑。写好 retry、幂等、超时和告警，比追求“一次搞定”更实际。
