go语言分布式事务需手动实现业务语义，本地事务表（outbox）因acid保障最稳；saga推荐temporal.io但需显式定义执行与补偿逻辑；tcc易出错主因是状态校验、超时控制和日志表主键设计不当。
Go 语言没有开箱即用的分布式事务框架，所谓“框架支持”本质是帮你封装了状态流转、重试、日志表轮询等样板逻辑，但 Try/Confirm/Cancel 的业务语义、资源冻结方式、幂等判断条件，必须由你亲手写死在代码里。
本地事务表（Outbox）为什么是最稳的起点
它把“改数据库”和“发消息”塞进同一个 db.BeginTx()，靠数据库 ACID 保证原子性，不依赖外部协调器，也不挑战 Go 生态缺失的 2PC 实现能力。
- 必须让
outbox表和业务表在同一个数据库实例、同一个事务中 —— 跨库就失效 -
INSERT INTO outbox前，建议先SELECT ... FOR UPDATE锁住对应业务行，否则高并发下可能重复发事件 - 下游消费端必须幂等：
INSERT IGNORE、UPSERT、或用idempotency-keyHTTP header + 唯一索引校验 - 轮询
outbox的 goroutine 要控制频率（如 100ms 间隔），太密打爆 DB，太慢拖长延迟
Saga 模式在 Go 里怎么避免漏补偿
协同式 Saga 容易因事件丢失或消费者 crash 导致后续步骤不触发；编排式 Saga 则依赖 Orchestration 服务的可靠性。Temporal.io 是目前 Go 生态最接近“开箱即用”的选择，但它不是魔法 —— 你仍需显式定义每步的 Execute 和 Compensate 函数。
- 每个
Compensate必须带context.Context并设超时，防止 Cancel 卡死阻塞整个流程 - 不要假设“上一步成功了，这一步就一定该执行”：Temporal 的 workflow ID + run ID 是唯一上下文，别用内存变量或
context.WithValue传状态 - 如果不用 Temporal，自己实现编排器时，务必把每步的执行状态（
executing/compensating）落库，否则服务重启后无法续跑
TCC 的 Confirm/Cancel 为什么总出错
典型错误是 panic: call to Confirm after Try failed 或资损，根源不在框架，而在没管住三件事：状态校验、超时控制、日志表主键设计。
-
Confirm()开头必须SELECT ... FOR UPDATE WHERE status = 'trying'，否则并发调用会误操作已 Cancel 的记录 -
tx_log表主键别用uuid，高并发 INSERT 会成热点；推荐(tx_id, branch_id)联合主键 + 时间戳字段做分片依据 -
Confirm和Cancel的 SQL 都要加context.WithTimeout，并透传到底层db.ExecContext，否则锁等待卡住整个事务链路
真正容易被忽略的是时钟漂移：别用 time.Now().Before(expireTime) 判断 TCC 超时，节点间毫秒级偏差就会导致 Cancel 被跳过；统一用 NTP 同步后的单调时钟，或直接依赖数据库 NOW() 返回值做比较。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
