go中tcc无法靠库自动搞定，因其try/confirm/cancel逻辑必须与业务强耦合，框架无法替代开发者决策冻结库存、扣减积分等具体实现，且需手动保障幂等、状态校验、超时控制及日志表设计。
为什么 TCC 在 Go 里不能靠库自动搞定
Go 生态没有像 Java 的 Seata 那样开箱即用的 TCC 框架，不是因为技术难，而是 TCC 的核心逻辑（Try/Confirm/Cancel）必须和业务强耦合——框架没法替你决定“冻结库存”具体怎么写、“扣减积分”要不要加幂等锁。
常见错误现象：panic: call to Confirm after Try failed，本质是没自己管好状态流转；或者 Confirm 被重复调用导致资损，因为忘了在数据库加 status = 'trying' 的前置校验。
- 所有
Try必须是本地事务，且只做“预留资源”，不真正变更最终状态 -
Confirm和Cancel必须设计为幂等：用唯一业务 ID + 状态字段联合判断是否已执行过 - 不要依赖全局事务协调器自动重试：Go 服务重启后，得靠定时任务扫描
tx_log表里status = 'trying'的记录来兜底
Go 中实现 TCC 的最小可行结构
不需要引入复杂中间件，一个带状态机的结构体 + 三个方法就能跑通。关键是把事务上下文（tx_id、branch_id）透传到每个阶段，而不是靠 goroutine 或 context.WithValue 传递——后者在线程切换或 RPC 跨服务时会丢。
使用场景：跨微服务的下单流程（订单服务 Try、库存服务 Try、积分服务 Try），各服务各自落 tx_log 表，再由独立的事务恢复服务驱动 Confirm/Cancel。
立即学习“go语言免费学习笔记（深入）”；
-
Try()：插入一条tx_log记录，status设为'trying'，同时执行预留逻辑（如UPDATE stock SET frozen = frozen + ? WHERE sku_id = ?） -
Confirm()：先SELECT ... FOR UPDATE查tx_log，确认status = 'trying'后才更新真实数据（如UPDATE stock SET total = total - ?, frozen = frozen - ?），最后改日志状态为'confirmed' -
Cancel()：同理查日志状态，只释放预留（如UPDATE stock SET frozen = frozen - ?），状态改为'cancelled'
Go 里最容易被忽略的两个坑
一个是超时控制：TCC 的 Confirm 如果卡在数据库锁上，整个分布式事务就卡死。另一个是日志表设计：很多人用 uuid 当主键，结果高并发下 INSERT 成瓶颈，拖慢所有 Try。
性能影响：单次 Try 涉及 2 次 DB 写（业务表 + 日志表），比本地事务多 1 倍 IO；Confirm/Cancel 若不做 where status 条件，可能误操作已终态的记录。
-
Confirm和Cancel接口必须带context.Context，并在 SQL 层设置ctx, cancel := context.WithTimeout(ctx, 3*time.Second) -
tx_log表主键建议用(tx_id, branch_id)联合主键，聚簇索引天然支持按事务维度快速扫描 - 别在
Confirm里调其他服务：它必须是纯本地操作，否则又引入新分布式风险
什么时候该放弃 TCC 改用 Saga
TCC 适合短流程、高一致性要求、分支数少（≤3）的场景。一旦业务链路变长（比如下单 → 通知物流 → 推送消息 → 更新推荐权重），Confirm/Cancel 的开发和测试成本指数上升。
错误信号：Cancel 开始需要调第三方 API（比如退优惠券要调营销服务），或者 Try 预留逻辑本身就要查多个表做校验，已经接近真实业务复杂度了。
- Saga 模式下，每个服务只管自己的正向操作和补偿接口（
CompensateRefund()），不用管别人的状态机 - Go 实现 Saga 只需一个轻量状态机库（比如
go-statemachine）+ 消息队列（RabbitMQ或Kafka）保序投递 - 如果当前系统已有可靠的消息重试机制，Saga 的落地难度远低于 TCC
事情说清了就结束。TCC 不是银弹，它把分布式一致性的复杂性从基础设施层搬到了你的业务代码里——写错一行 WHERE status = 'trying'，就可能引发资损。
