Go中需手动实现Saga模式，每个步骤须拆分为正向与补偿函数，状态必须持久化且幂等，HTTP失败需按语义区分处理，不可依赖context自动重试或Redis主存。
Go 里没有现成的 Saga 框架，得自己编排步骤和补偿逻辑
Go 标准库和主流生态（如 sqlx、gorm）都不提供 Saga 抽象。这不是语法限制，而是模式本身依赖业务语义——哪一步该重试、失败后怎么反向执行、状态如何持久化，都得你定义清楚。别指望加个注解就自动变 Saga。
常见错误是把多个 db.Exec 包进一个函数，再套个 defer 做“回滚”，这根本不是 Saga：它没分离正向操作与补偿操作，也没处理跨服务调用失败后的异构补偿（比如调了支付接口成功，但本地扣库存失败，这时得调支付的退款接口）。
- 每个业务步骤必须拆成「正向动作 + 补偿动作」两个独立函数，例如：
chargeWallet()和refundWallet() - 步骤间不能共享内存状态；所有中间结果（如订单 ID、支付流水号）必须写入持久存储（DB 或 Redis），否则补偿时拿不到上下文
- 不要在补偿函数里做“如果原操作没执行就跳过”这类判断——Saga 要求补偿动作幂等且可重入，靠的是状态机或唯一事务 ID 去重，不是条件跳过
context.Context 控制超时，但 Saga 的重试必须自己实现
很多人以为传个带超时的 context.WithTimeout 就能管住整个 Saga 流程，其实只管得住单次 HTTP 调用或 DB 查询。Saga 中某一步卡住（比如下游服务响应慢），需要的是「步骤级重试 + 全局超时兜底」，而 Go 的 context 不会自动帮你重试。
典型场景：调第三方物流接口创建运单失败，你得决定是立即补偿前面的库存锁定，还是等 2 次重试后再补偿。这个策略不在 context 能力范围内。
立即学习“go语言免费学习笔记（深入）”；
- 用
time.AfterFunc或定时任务检查 Saga 状态表中超过阈值的“进行中”记录，触发超时补偿 - 重试逻辑要封装在步骤调用层，例如：
doWithRetry(chargeWallet, 3, time.Second)，而不是靠外层 context 反复 cancel/renew - 避免在补偿函数里再起 goroutine 做异步重试——这会让状态更难追踪；补偿本身也应是同步可监控的操作
状态持久化必须用支持事务的存储，且补偿操作要读最新状态
Saga 最容易崩在状态不一致上：比如正向步骤 A 成功写 DB，B 失败，开始补偿 A，但此时 A 的数据已被其他请求改写，补偿就可能出错。所以状态存储不仅要可靠，还得让补偿动作能准确读到“当时 A 执行完那一刻”的快照。
错误做法是只存最终状态字段（如 status VARCHAR(20)），正确做法是存事件或带版本的状态记录。
- 推荐用一张
saga_instances表，字段至少包含：id（全局唯一事务 ID）、step（当前执行到哪步）、payload（JSON，存各步骤输入输出）、updated_at - 补偿函数必须先查这条记录，确认当前
step和payload是否匹配预期，再执行反向逻辑；不要假设“既然走到补偿，A 一定成功了” - 避免用 Redis 做主状态存储——它不保证多 key 操作的原子性，Saga 中多个步骤更新不同 key 时，崩溃可能导致状态撕裂
HTTP 调用失败时，409 Conflict 和 500 Internal Server Error 的处理逻辑完全不同
这是最容易被忽略的语义细节。Saga 不是简单看 HTTP 状态码是否非 2xx 就触发补偿，而要看失败原因是否可重试、是否已产生副作用。
比如调库存服务减库存，返回 409 Conflict（库存不足），说明操作明确失败且无副作用，可以立刻补偿前序步骤；但若返回 500，可能是扣减成功了但响应没发回来，也可能是根本没执行——这时直接补偿可能造成重复退款。
- 对
4xx错误（除408、429外），通常视为确定性失败，可立即补偿 - 对
5xx或网络超时，必须走「幂等查询 + 状态确认」流程：用原请求的幂等 ID 查下游系统，确认是否已执行，再决定是否补偿 - 所有对外 HTTP 客户端必须支持幂等头（如
X-Idempotency-Key），否则无法安全确认
Saga 的复杂点从来不在代码行数，而在每一步都要回答三个问题：它有没有副作用？副作用是否可逆？逆操作是否真能抵消它？这些问题没法靠框架自动答，只能靠你对业务边界的清晰切割和对失败场景的穷举验证。
