Go原生不支持跨服务全局事务，因其设计哲学排斥2PC等强一致性协议；实际需用Saga模式实现最终一致，配合消息队列与幂等处理。
为什么 Go 原生不支持跨服务的全局事务
Go 语言标准库和主流框架（如 net/http、gin、echo）本身不提供分布式事务能力，因为两阶段提交（2PC）这类强一致性协议与 Go 强调简洁、轻量、高并发的设计哲学存在张力。数据库连接池、HTTP 超时、服务实例漂移都会让传统 XA 事务难以落地。
实际项目中，直接用 database/sql 的 Begin()/Commit() 只能管住单个 DB 实例；一旦涉及订单服务扣库存 + 用户服务改余额 + 物流服务建单，就必须靠业务层协调。
Saga 模式是 Go 微服务最可行的落地选择
Saga 把一个长事务拆成一系列本地事务，每个步骤配有对应的补偿操作。它不要求锁表或协调器全程阻塞，适合 HTTP/gRPC 场景，也契合 Go 的显式错误处理风格。
- 正向操作用
POST /orders创建订单，成功后发消息触发下一步 - 补偿操作写成独立函数，比如
CancelOrder(ctx, orderID)，由失败时主动调用或通过消息重试触发 - 推荐用
go.temporal.io/sdk或asynq（Redis 后端）管理 saga 流程状态，避免自己维护状态机 - 注意：Saga 不保证实时强一致，只保证最终一致；补偿逻辑必须幂等，比如用
UPDATE ... WHERE status = 'pending'防止重复执行
如何用消息队列实现可靠事件传递
HTTP 调用失败即中断，而消息队列（如 Kafka、NATS、RabbitMQ）可提供 at-least-once 投递，是 Saga 的关键支撑。
