go中无开箱即用saga框架，需基于context、状态机、消息队列和幂等/可重试补偿逻辑手动构建，核心是正向与反向操作的可靠编排。
Go 里没有现成的 Saga 框架，得自己搭骨架
Go 生态里没有像 Java 的 Seata 或 .NET 的 MassTransit 那样开箱即用的 Saga 实现。你得靠 context.Context、状态机、消息队列（如 RabbitMQ 或 Kafka）和补偿逻辑手动组装。核心不是“选哪个库”，而是“怎么把正向操作和反向补偿串成可恢复的链”。
常见错误是直接用 defer 写补偿——它只在当前函数退出时触发，跨服务、跨网络调用完全不生效；还有人把所有步骤塞进一个 HTTP handler，一崩全挂，根本谈不上“事务性”。
- 正向步骤必须幂等：每个
CreateOrder、ReserveInventory接口都要支持重复调用不翻倍扣库存 - 补偿操作必须可重试：比如
CancelPayment要能处理“支付已退”“支付不存在”“退款中”多种状态，不能一错就卡死 - 状态必须落库：用一张
saga_instances表存id、current_step、status、data（JSON），别存在内存或 Redis 里——节点重启就丢状态
func (s *Saga) Execute() 怎么避免阻塞和超时雪崩
很多人写个 for 循环串行调用各服务，结果第一步耗时 2s，第二步网络抖动卡住 30s，整个 Saga 实例 hang 死，下游还在不断重发请求，形成雪崩。
必须拆开执行流：每步都走异步消息（如发一条 order.created 到 RabbitMQ），由独立消费者处理，并设置 per-step 的 timeout 和 retry 策略。Go 里推荐用 github.com/streadway/amqp + time.AfterFunc 做超时兜底。
立即学习“go语言免费学习笔记（深入）”；
【极品模板】出品的一款功能强大、安全性高、调用简单、扩展灵活的响应式多语言企业网站管理系统。 产品主要功能如下： 01、支持多语言扩展（独立内容表，可一键复制中文版数据） 02、支持一键修改后台路径； 03、杜绝常见弱口令，内置多种参数过滤、有效防范常见XSS； 04、支持文件分片上传功能，实现大文件轻松上传； 05、支持一键获取微信公众号文章（保存文章的图片到本地服务器）； 06、支持一键
- 不要用
http.Post同步等响应：改用发布事件 + 监听回调，把“等待”转为“状态轮询”或“事件驱动” - 每步执行前查
saga_instances.status：如果是compensating，直接跳过正向逻辑，进入补偿分支 - 超时后不立即失败，先更新数据库为
timeout状态，再触发补偿——避免“超时但实际成功了”的双花问题
补偿失败怎么办？Compensate() 不是万能的
补偿本身可能失败：比如库存服务宕机，ReleaseInventory 一直 503。这时候 Saga 不能停，也不能无限重试——要引入“人工干预点”。
关键是在补偿失败时，把实例状态设为 failed_compensation，并把失败原因（如 "inventory service unreachable"）写进 error_message 字段，同时发告警到钉钉/企业微信。别试图自动降级或跳过补偿——那等于放弃一致性。
- 补偿接口必须返回明确结果：不是
error != nil就算失败，要解析响应体里的result_code，区分“业务拒绝”和“网络失败” - 重试次数建议设为 3～5 次，间隔用指数退避（
time.Second * 1, 2, 4, 8），别固定 100ms 狂刷 - 所有补偿调用必须带 traceID 和 sagaID，否则排查时根本分不清是哪个订单的哪一步卡住了
本地事务和 Saga 怎么共存？sql.Tx 别和 Saga 混用
一个常见误区：在同一个 sql.Tx 里既更新本地订单表，又调用远程库存服务。这是错的——sql.Tx 只管数据库，不管 HTTP 或 MQ。一旦远程调用失败，你回滚了本地事务，但库存已经扣了，没法自动恢复。
正确做法是：本地状态只存 Saga 协调元数据（如 saga_id, step, status），所有业务变更（创建订单、扣库存）都作为独立的、幂等的外部调用。本地数据库只是 Saga 的“记事本”，不是“业务数据库”。
- 别在
tx.Commit()前发 MQ 消息：MQ 发送失败，事务已提交，无法回滚——应该先发消息，成功后再 commit 本地状态 - 如果真要强一致本地操作（比如更新用户余额），把它做成 Saga 的第一步，并配好对应的补偿（
RevertBalance），而不是塞进外围事务 - 日志打全：每个正向/补偿调用前后，都 log
saga_id、step_name、input（脱敏）、output（脱敏）、elapsed_ms
Saga 的复杂度不在代码多寡，而在状态分支覆盖是否完整——漏掉一种补偿失败后的重试策略，或少判一种中间状态，线上就可能出现“订单已创建但库存没扣”或“钱退了但订单还待支付”这种难复现、难定位的一致性裂缝。
