Go 中无开箱即用Saga框架，需手动设计可逆步骤、幂等补偿及基于select的异步执行流。
Go 里没有现成的 Saga 框架，得自己搭骨架
Go 生态里没有像 Java 的 Seata、Python 的 py-saga 那样开箱即用的 Saga 实现。官方 database/sql 和 net/http 都不感知事务跨服务，context.Context 也传不了补偿逻辑。你得自己定义「正向操作」和「反向补偿」的配对关系，并确保它们能被可靠触发。
常见错误是把补偿写成普通函数调用——一旦第二步服务宕机，补偿根本不会执行。Saga 的核心不是“写了补偿”，而是“补偿能被重试且幂等”。
-
Saga不是靠数据库 ACID，而是靠业务层的「可逆性设计」：每个步骤必须自带Compensate()方法，且该方法要能多次执行不翻车 - 推荐用结构体封装步骤：
type Step struct { Do func() error; Undo func() error; Name string }，避免散落的匿名函数难追踪 - 别在
Do里直接提交 HTTP 请求后就认为成功——要等收到明确响应码（如200 OK）再进下一步，否则补偿可能对着一个压根没发生的操作“撤回”
Undo 函数必须幂等，否则重试会雪崩
网络超时、服务重启、消息重复投递……这些都会导致 Undo 被调多次。如果补偿逻辑是「减库存」或「删订单」，第二次执行就可能把数据搞错。
典型错误现象：Undo 执行后返回 sql.ErrNoRows，但上层没判断就报错退出，下次重试又来一遍，结果库存变成负数。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 所有
Undo必须查状态再操作：比如先SELECT status FROM orders WHERE id = ?，只对status = 'confirmed'的才执行退款 - 用数据库唯一约束兜底：给补偿记录加
compensation_log(order_id, step_name, created_at)表，INSERT IGNORE或ON CONFLICT DO NOTHING防重 - HTTP 补偿请求头带上
X-Compensation-ID: <step-id>，下游服务据此做去重（比如 RedisSETNX compensation:order_123:pay 1 EX 3600）
用 chan + select 控制 Saga 执行流，别用同步阻塞
跨服务调用天然高延迟，如果每个 Do 都用 http.DefaultClient.Do 同步等，整个 Saga 流程卡死在某一步，既无法超时熔断，也无法并发推进后续补偿。
真实场景里，你常需要：等待正向结果、同时监听取消信号、超时后自动触发补偿——这恰好是 select 的主场。
select {
case <-time.After(10 * time.Second):
log.Warn("step payment timeout, triggering compensate")
err = step.Undo()
case res := <-doResult:
if res.err != nil {
err = step.Undo()
}
case <-ctx.Done():
err = step.Undo()
}- 每个
Step的Do应启动 goroutine 发请求，结果写入chan，主流程用select统一收口 - 别把
ctx.WithTimeout直接传给http.Client就完事——HTTP 超时只管连接/读写，Saga 层超时还要管「补偿是否跑完」 - 如果用了消息队列（如 Kafka），
Undo触发后别立刻commit offset，等补偿结果落库成功再提交，否则补偿失败却丢了消息，数据就永远不一致了
补偿失败不能静默，必须进死信队列或告警
最危险的情况不是补偿没触发，而是补偿触发了但失败了，代码里只打一行日志就继续往下走。比如支付服务退款接口返回 503 Service Unavailable，你的 Undo 却没重试机制，也没通知运维，这笔钱就锁死了。
实际线上，Undo 失败率远高于 Do——因为正向操作是主动发起的，而补偿往往是被动响应异常，下游服务此时很可能已经过载。
- 单次
Undo失败后，至少重试 3 次，间隔指数退避（1s → 3s → 9s） - 重试仍失败，必须把失败步骤序列化后发到死信 topic（如
saga_dead_letter），带完整上下文：order_id、failed_step、error、trace_id - 监控要盯住
saga_undo_failure_total{step="refund"}这类指标，阈值超过 0.1% 就电话告警——Saga 的脆弱点永远在补偿侧，不在正向链路
Saga 的复杂度不在代码量，而在每一步都得预设「它会失败」。很多人卡在第一步：没想清楚哪个服务该负责哪段补偿，或者把本该由 A 服务做的 Undo 塞进 B 服务的回调里，结果 B 宕机，A 的补偿就彻底失联。
