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 的关键支撑。
立即学习“go语言免费学习笔记（深入）”；
在 Go 中常见陷阱：
- 消费者没做幂等校验：同一消息被重复消费导致多次扣款 → 建议用
order_id+event_type构造唯一索引存 DB，消费前先INSERT IGNORE - 消息未确认就返回成功：用
nats.JetStream的Ack()或kafka-go的MarkOffset()显式控制位点 - 事务与消息不同步：不要在 DB
Commit()前发消息；更稳妥的是用本地消息表（先写 DB + 消息记录，再异步投递）或 WAL 日志解析（如 Debezium）
什么时候该放弃全局事务，改用最终一致性+人工干预
不是所有场景都值得上 Saga。如果跨服务操作频率极低（如每月一次财务对账）、或补偿成本极高（如已通知第三方物流发车），硬套分布式事务反而增加系统脆弱性。
此时更务实的做法：
- 核心链路只做「尽力而为」：下单成功即返回，后台用定时任务扫描异常订单
- 暴露修复接口：比如
POST /orders/{id}/reconcile，供运维手动触发状态对齐 - 记录完整上下文日志：每个服务在处理时写入
trace_id、step、input、output，方便问题定位
真正难的不是写 CompensatePayment()，而是定义清楚「什么算失败」「补偿到哪一步为止」「谁来兜底超时未响应的服务」——这些必须在服务契约里白纸黑字写进 OpenAPI spec 或 Protobuf 注释里。
