Go没有开箱即用的TCC框架，因Try/Confirm/Cancel逻辑必须由业务代码实现，框架无法替代冻结库存、扣减积分等核心决策，且需状态机+日志表兜底保障可靠性。
Go 语言生态里没有开箱即用的强一致性分布式事务框架，硬要上 2PC 或 TCC，得自己搭状态机、管日志表、控超时、防悬挂——不是框架不行，是强一致本身和微服务松耦合理念天然冲突。
为什么 Go 没有像 Seata 那样的 TCC 框架
不是技术做不到，而是 TCC 的 Try/Confirm/Cancel 逻辑必须由业务代码定义：冻结库存怎么写、积分怎么扣、失败后怎么释放，框架没法替你决策。强行封装只会把复杂度藏得更深，出问题更难定位。
- 常见错误现象：
panic: call to Confirm after Try failed，本质是没在Confirm前查tx_log状态，直接操作了已失败的分支 - Confirm 被重复调用导致资损，往往因为数据库没加
WHERE status = 'trying'条件，或没用唯一业务 ID + 状态字段做幂等校验 - 很多人用
context.WithValue透传事务上下文，但跨 goroutine 或 RPC 后就丢了，结果Cancel找不到原始tx_id
2PC 在 Go 里跑不起来的真实原因
Go 的 goroutine + channel 确实能模拟两阶段流程，但生产环境根本扛不住：
- 协调者单点故障：一旦崩溃，所有参与者卡在
prepared状态，没人知道该提交还是回滚 - 网络分区下阻塞严重：某个参与者失联，整个事务 hang 住，超时设置太短会误判，太长又拖垮吞吐
- 没有内置的事务日志持久化机制，重启后无法恢复未完成事务，得额外设计
tx_recovery服务轮询状态表
TCC 最小可行实现的关键控制点
不依赖框架，靠三个方法 + 一张日志表就能跑通，但以下四点漏一个就容易线上出事：
立即学习“go语言免费学习笔记（深入）”；
-
Try必须是本地事务，且只做资源预留（如UPDATE stock SET frozen = frozen + ?），不能动真实余额 -
Confirm和Cancel必须带context.Context，SQL 层显式设置超时，避免锁表卡死 - 日志表主键别用
uuid，高并发下 INSERT 成瓶颈；推荐用tx_id + branch_id组合主键 + 时间戳索引 - Confirm/Cancel 执行前，必须
SELECT ... FOR UPDATE查日志状态，确认是'trying'才继续，否则直接返回
强一致场景下真正该做的取舍
与其花大力气在 Go 里硬刚 2PC/TCC，不如回到业务本身判断：
- 是否真的需要“立即一致”？比如支付成功后订单状态必须秒级同步，还是允许几秒延迟？后者走事件驱动 + 对账更稳
- 有没有可能把强一致收敛到单服务内？例如把订单+库存聚合进一个服务，用本地事务兜底，再对外提供幂等接口
- 如果必须跨服务强一致，优先评估是否能用数据库层方案（如 PostgreSQL 的逻辑复制 + 行级触发器），比应用层 TCC 更轻量、更可靠
强一致的代价是可用性与开发成本，Go 生态的选择不是“缺工具”，而是主动避开那些本就不该在应用层解决的问题。
