go中无现成saga框架，需手动建模事务步骤、补偿函数及状态，确保幂等、持久化状态、分层超时与消息驱动。
Go 里没有现成的 Saga 框架，得自己编排补偿逻辑
Go 标准库和主流生态（如 go-kit、grpc-go）都不提供开箱即用的 Saga 实现。这不是语言缺陷，而是 Saga 本质依赖业务语义——哪一步失败、该回滚谁、补偿操作是否幂等，这些必须由你定义。
常见错误是试图用一个通用“Saga 引擎”包住所有服务调用，结果发现补偿路径写不全、状态漏更新、重试时重复执行补偿。真实项目里更稳妥的做法是：用结构体显式建模事务步骤 + 补偿函数 + 当前状态，比如：
type TransferSaga struct {
FromAccountID string
ToAccountID string
Amount int64
Status SagaStatus // Pending, Executed, Compensated
}
func (s *TransferSaga) Execute() error {
if err := debit(s.FromAccountID, s.Amount); err != nil {
return err
}
if err := credit(s.ToAccountID, s.Amount); err != nil {
// 立即补偿：这里不能只写 rollback()，要明确调用 compensateDebit()
compensateDebit(s.FromAccountID, s.Amount)
s.Status = Compensated
return err
}
s.Status = Executed
return nil
}
- 每步正向操作后，必须紧跟着可执行的补偿函数，且补偿函数本身也要能幂等（比如基于 version 或 status 字段判断是否已补偿过）
- 不要把补偿逻辑塞进 defer —— defer 在 panic 时才触发，而网络超时、返回码非 200 等“软失败”不会触发它
- 状态字段（如
Status）必须持久化到数据库或 Redis，否则服务重启后无法续跑 Saga
用 context.Context 控制 Saga 全链路超时，但别只靠它做补偿触发
context.WithTimeout 能帮你中断卡住的步骤，但它不等于“自动补偿”。超时只是信号，后续动作仍需手动调度。
典型误用：在 ctx.Done() 的 select 分支里直接调补偿函数。问题在于，这个 select 可能发生在任意步骤中，而你并不知道上一步是否已成功、是否需要补偿、补偿是否已执行过。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法是：每个步骤执行前记录“即将执行 X”，执行成功后立即记“X 已完成”，失败或超时时查日志/状态表，按已完成的步骤逆序触发对应补偿
- 超时时间要分层设置：
debit()和credit()各自的 HTTP 客户端 timeout 应短于整个 Saga 的总 timeout，避免某一步拖死全局 - 别用
context.CancelFunc去主动 cancel 其他服务——对方未必支持 cancel，反而造成状态不一致
补偿操作必须设计为幂等，否则重试会雪崩
网络抖动、节点重启、K8s Pod 重建都会导致 Saga 步骤重试。如果 compensateDebit 每次都减账户余额，那一次失败后重试三次，就多扣了两倍钱。
幂等的关键不是“加锁”，而是“用状态说话”。比如：
// 错误：无条件扣款
func compensateDebit(accountID string, amount int64) {
db.Exec("UPDATE accounts SET balance = balance + ? WHERE id = ?", amount, accountID)
}
// 正确：只对特定状态的操作做补偿
func compensateDebit(accountID string, amount int64, sagaID string) {
var status string
db.QueryRow("SELECT status FROM saga_logs WHERE saga_id = ? AND step = 'debit'", sagaID).Scan(&status)
if status == "executed" {
db.Exec("UPDATE accounts SET balance = balance + ? WHERE id = ?", amount, accountID)
db.Exec("UPDATE saga_logs SET status = 'compensated' WHERE saga_id = ? AND step = 'debit'", sagaID)
}
}
- 补偿函数入参里带上
sagaID和步骤名，用于查状态表，而不是靠内存变量或局部 flag - 状态表（如
saga_logs）建议用数据库行级锁（SELECT ... FOR UPDATE）或带 CAS 的 Redis 命令（SETNX+ TTL）来防并发重复补偿 - HTTP 补偿接口也必须校验请求里的
saga_id和step_id，服务端二次确认状态再执行
本地事务 + 消息队列组合比纯内存 Saga 更可靠
纯内存或单机内存状态的 Saga 在进程崩溃时直接丢失上下文。生产环境强烈建议把关键状态落库，并用消息驱动补偿。
例如转账 Saga 中，“已扣款但未入账”这种中间态，必须先写入 saga_state 表并提交本地事务，再发消息触发下一步。这样即使 credit 服务宕机，消息积压，只要 Saga 状态已存，就能被定时任务捞出重试。
- 不要用
defer publishMsg()发送补偿消息——defer 不保证执行，panic 时可能跳过 - 消息内容必须包含完整上下文：
saga_id、step、payload、attempt_count，方便下游判断是否重复 - 用 RabbitMQ 的死信队列或 Kafka 的重试主题处理失败补偿，避免无限循环；最大重试次数建议设为 3–5 次，之后告警人工介入
Saga 最难的从来不是代码怎么写，而是想清楚每一步失败后，系统到底处于什么状态、用户感知如何、资金有没有双花、日志能不能对齐。这些没法靠框架自动推导，得一行行 case 拆解，一个个接口翻文档，一遍遍和上下游对状态码和幂等规则。
