go没有开箱即用的tcc框架，因try/confirm/cancel逻辑必须由业务代码实现，框架无法替代判断扣减量、锁记录等核心行为，且需状态机+日志表兜底保障可靠性。
tcc 在 go 里没法靠一个 import 就跑通，必须自己写 try/confirm/cancel 逻辑，并用状态机+日志表兜底。
为什么 Go 没有开箱即用的 TCC 框架
Go 生态缺乏像 Java Seata 那样成熟的 TCC 框架，不是因为技术做不到，而是 TCC 的核心行为（比如“冻结库存”“解冻积分”）必须由业务代码决定——框架无法替你判断该扣多少、锁哪条记录、是否要加唯一索引防重。常见错误包括：
-
panic: call to Confirm after Try failed：没检查事务状态就直接调 Confirm，导致资源误扣 - Confirm 被重复执行造成资损：数据库里没加
WHERE status = 'trying'条件，或没用业务 ID + 状态做联合幂等校验 - 服务重启后事务卡死：没设计定时任务扫描
tx_log表中status = 'trying'的记录来驱动恢复
Try/Confirm/Cancel 必须满足的硬约束
这三个阶段不是随便写的函数，每一步都有明确语义和执行前提：
-
Try()必须是本地事务，只做资源预留（如UPDATE stock SET frozen = frozen + ? WHERE sku_id = ?），不改最终状态；同时必须插入一条tx_log记录，status设为'trying' -
Confirm()和Cancel()必须带context.Context，SQL 层需设置超时（例如context.WithTimeout(ctx, 3*time.Second)），避免卡死整个分布式流程 - 两者都必须先
SELECT ... FOR UPDATE查tx_log，确认当前status符合预期（Confirm 要求'trying'，Cancel 同理），再更新业务表和日志状态 - 所有 SQL 更新都得带
WHERE tx_id = ? AND status = 'trying'，否则可能误操作已终态的记录
日志表设计与性能陷阱
tx_log 不是可有可无的辅助表，它是 TCC 可靠性的唯一事实来源。但设计不当会拖垮性能：
- 别用
uuid当主键：高并发下INSERT成瓶颈，建议用id BIGINT AUTO_INCREMENT+tx_id VARCHAR(64) UNIQUE组合 - 必须建复合索引：
INDEX idx_status_txid (status, tx_id)，支撑定时任务快速捞出待处理记录 - 单次
Try至少触发 2 次 DB 写（业务表 + 日志表），比本地事务多一倍 IO，压测时要重点看磁盘 IOPS - Confirm/Cancel 若漏掉
WHERE status条件，可能把'confirmed'的记录又执行一遍，后果是双倍扣减或双倍解冻
跨服务调用时上下文不能靠 context.WithValue 透传
RPC 或 HTTP 跨服务时，context.WithValue 会丢失，导致 Confirm/Cancel 拿不到原始 tx_id 或 branch_id。正确做法是：
- 在请求头（如
X-TX-ID、X-BRANCH-ID）显式传递事务标识 - 每个服务入口统一解析并注入到结构体字段，而不是塞进
context里靠 goroutine 传递 - 所有
Try/Confirm/Cancel方法签名必须接收txID string和branchID string参数，杜绝隐式依赖
最易被忽略的是超时控制和日志表索引——前者让事务卡在锁上没人知道，后者让恢复任务扫表变全表扫描，线上出问题时根本来不及反应。
