go中saga模式核心是状态机+幂等补偿，tcc需严格隔离try/confirm/cancel且预留资源不改主数据，二者均需协调器驱动、避免本地事务跨服务传播。
Go 里用 Saga 模式做分布式事务，核心是状态机 + 补偿动作
Saga 不是 Go 标准库提供的功能，得自己搭骨架。它适合长流程、跨服务、最终一致的场景，比如下单→扣库存→发优惠券→通知物流，其中任意一步失败，前面成功的步骤得靠补偿回滚。
常见错误是把补偿逻辑写成“反向操作”，比如 createOrder 的补偿写成 deleteOrder —— 实际上订单可能已被下游引用，删不掉；正确做法是补一个 cancelOrder 状态变更。
- 每个正向步骤必须对应一个幂等的补偿函数，且补偿函数本身也要可重试
- 推荐用状态机（如
github.com/looplab/fsm）管理 Saga 当前阶段，避免靠 DB 字段轮询判断进度 - 本地事务和远程调用要分离：DB 更新和发 MQ 必须在同一个本地事务里提交，否则可能丢消息
- Go 中建议用
context.Context透传 saga_id 和 step_id，方便日志追踪和人工干预
TCC 在 Go 中落地难在 Try 阶段的资源预留与 Confirm/Cancel 的幂等性
TCC 要求服务提供三个接口：Try（检查+预留）、Confirm（真正执行）、Cancel（释放预留），三者都必须幂等。Go 项目里最容易翻车的是 Try 做了 DB 写操作但没加唯一约束或防重表，导致重复预留。
典型问题现象：Confirm 执行时发现库存已扣减两次，或者用户账户余额被多减了一笔——根本原因是 Try 成功后网络超时，发起方重试，又跑了一遍 Try。
立即学习“go语言免费学习笔记（深入）”；
-
Try阶段不要改业务主数据，只写冻结表（如account_freeze），字段含saga_id+business_key并建联合唯一索引 -
Confirm和Cancel必须基于冻结记录是否存在来决策，而不是查主表余额 - 别在
Confirm里做复杂计算或远程调用，它应该只是原子更新：把冻结金额转成实扣，或清空冻结记录 - Go 的 HTTP handler 里别直接调
Confirm，先落库标记“待确认”，再由后台 goroutine 异步执行，避免请求超时导致状态卡住
Go 生态里没有开箱即用的分布式事务框架，别指望 go-zero 或 kratos 自带 TCC/Saga 支持
它们提供 RPC、限流、注册中心这些基建，但事务编排得自己写。有人试图用 ent 的 hook 或 gorm 的 callback 插入 Saga 逻辑，结果发现难以覆盖跨服务边界——callback 只管本服务 DB，管不了调用下游的超时、重试、回滚。
真实项目中更可行的路径是：用轻量协调器（如自研的基于 ETCD 的 saga coordinator）管状态流转，每个服务只实现 Do/Undo 或 Try/Confirm/Cancel 接口，通过 HTTP/gRPC 暴露，由协调器按序调用。
- 避免用 Redis 做 Saga 状态存储——它不保证强一致，ETCD 或 PostgreSQL 更稳妥
- 别把补偿逻辑写进业务 service 层，单独抽成
saga_handler.go，和主业务解耦，方便独立测试和灰度 - 所有远程调用必须设超时（
context.WithTimeout），且超时后协调器要主动触发Cancel，不能等下游自己恢复
本地事务和分布式事务混用时，Go 的 sql.Tx 无法跨服务传播
这是最常被忽略的一点：你在 A 服务里用 db.Begin() 开了个事务，然后调 B 服务的 Try 接口，B 服务也开了自己的 sql.Tx —— 这两个事务完全无关，A 回滚不影响 B。Saga/TCC 的“事务感”全靠应用层协议维持，不是数据库层面的 XA。
所以当你看到“本地事务嵌套分布式事务”这种说法，本质是伪命题。Go 里只能做到：本地事务保障单次 DB 操作的原子性，Saga/TCC 协议保障跨服务操作的最终一致性。
- 别在
Try函数里手动db.Begin()后又 defertx.Rollback()，这会让补偿逻辑失效；应统一用 repository 层的预置事务方法 - 如果一个服务既要处理本地业务又要参与 Saga，它的 DB 操作必须拆成两组：一组进本地事务（如记日志），一组进 Saga 流程（如冻结资金）
- 调试时重点看各服务的
saga_id是否全程透传，以及每步的status字段是否及时更新，这是定位卡点的唯一线索
