在go微服务中应优先使用dtm实现saga而非手写2pc，因go缺乏jta级分布式事务支持，2pc在生产环境不可靠；dtm已封装补偿、重试、幂等及日志持久化，需正确配置gid、steps、timeout等参数，并确保补偿接口基于业务状态实现幂等。
Go 里用 github.com/yedf/dtm 实现 Saga，比手写 2PC 现实得多
直接说结论：在 Go 微服务中，别自己实现两阶段提交（2PC），它几乎不可能在生产环境可靠运行；Saga 是更可行的选择，而 dtm 这类库已经封装了补偿、重试、幂等、事务日志持久化等关键逻辑。
常见错误现象：context deadline exceeded 导致 Prepare 阶段卡住、协调者挂掉后分支事务状态不一致、手动写补偿逻辑漏掉边界情况（比如退款成功但通知失败）。
-
dtm的Saga模式默认走 HTTP 或 gRPC，每个子事务需提供正向接口和对应compensate接口，框架自动按反序调用补偿 - 必须为每个子事务设置
idempotent key（如订单号+操作类型），dtm会基于该 key 做去重，否则重复回调会引发资金/库存双扣 - 不要把数据库本地事务和 Saga 混在一起用——例如在子服务里先
Begin()再调dtm提交 Saga，这会让本地事务无法被 Saga 协调器感知，失去原子性保障
为什么 Go 标准库和主流 ORM 不支持真正的 2PC？
Go 生态里没有类似 Java JTA 的标准化分布式事务协调层，database/sql 的 Tx 只作用于单个 DB 连接，跨服务时 Prepare 和 Commit 无法原子协调。
使用场景：有人试图用 pgx + PostgreSQL 的 PREPARE TRANSACTION 模拟 2PC，但这要求所有参与方都用同一套 PG 集群、且协调者必须持久化 gid 并人工处理 in-doubt 事务——实际运维成本远超收益。
立即学习“go语言免费学习笔记（深入）”；
- PostgreSQL 的
PREPARE事务在 coordinator crash 后不会自动回滚，需要 DBA 手动ROLLBACK PREPARED，Go 服务无法安全接管 -
sql.DB不暴露 XA 接口，github.com/lib/pq和jackc/pgx都不支持 XA START/END/RECOVER 等命令 - 即使强行封装，网络分区时会出现部分服务收到
Commit、部分收到Abort，最终状态分裂
dtmcli 发起 Saga 时，哪些参数不能错？
参数填错是导致 Saga 卡死或跳过补偿的最常见原因，尤其在多环境部署时容易忽略。
-
req.Gid必须全局唯一且可追溯（建议用uuid.NewString()+ 业务标识拼接），重复Gid会导致 dtm 直接返回409 Conflict -
req.Steps中每个Step的Action和CompensateURL 必须可被 dtm 访问（注意容器网络、host 配置、HTTPS 证书），否则卡在第一个 step 的Waiting状态 -
req.Timeout建议设为子事务最长耗时的 3 倍（如子服务 SLA 是 2s，这里填 6000），太短会导致 dtm 过早触发补偿，太长则阻塞后续请求
示例片段：
req := &dtmcli.SagaReq{
Gid: "order_20240521_" + uuid.NewString(),
Timeout: 6000,
Steps: []dtmcli.TransReq{
{Action: "http://service-order/api/v1/create", Compensate: "http://service-order/api/v1/cancel"},
{Action: "http://service-pay/api/v1/charge", Compensate: "http://service-pay/api/v1/refund"},
},
}
补偿失败后，靠日志和告警而不是“自动修复”
Saga 的本质是“尽力而为+人工兜底”，不存在 100% 自动恢复的 magic。dtm 会重试补偿最多 5 次（可配），但第 6 次失败后就停在 Failed 状态，此时必须靠外部手段介入。
- 务必监听 dtm 的
/api/dtmsvr/notify回调或轮询/api/dtmsvr/getBranches?gid=xxx，把status == "failed"的 Gid 推送到告警通道（如企业微信机器人） - 每个补偿接口内部必须记录完整上下文到结构化日志（含
Gid、Step、入参、出参、错误堆栈），否则排查时根本不知道哪一步、哪个参数导致失败 - 不要在补偿逻辑里加“自动重试远程服务”的代码——这会让问题更隐蔽；重试应由 dtm 控制，你的补偿函数只做一次确定性操作
最常被忽略的一点：补偿接口的幂等性校验，必须基于业务状态而非请求参数。比如退款补偿不能只查“是否已发过 refund 请求”，而要查“账户余额是否已回退”，否则对账系统会漏掉差异。
