结论：tcc模式在go微服务中需手动实现prepare/confirm/cancel三方法，代码量与测试成本显著增加，但可规避at模式的数据库锁依赖，适用于高并发、强一致性且愿承担复杂度的场景。
直接说结论：在 Golang 微服务中用 Seata 做分布式事务，TCC 模式不是“更高级的选择”，而是明确的权衡——你得自己写 Prepare、Confirm、Cancel 三个方法，代码量翻倍、测试成本陡增，但能绕过 AT 模式对数据库锁的依赖，适合高并发、强一致性要求且愿意承担开发复杂度的场景。
为什么 Go 里 TCC 必须手动实现三个接口
Seata-go 的 TCC 模式不生成反向 SQL，也不代理数据源，它只负责协调调用时机。所有业务逻辑的“预留”“确认”“回滚”动作都由你定义，框架只做两件事：按顺序触发 Prepare，再统一发 Confirm 或 Cancel 请求。
-
Prepare阶段必须是幂等的，且不能真正提交数据（比如扣减库存要冻结而非真实扣减） -
Confirm和Cancel必须能根据Prepare的返回结果独立执行，不能依赖上下文状态 - 每个参与服务都要注册为
TCCResource，通过tcc.NewTCCServiceProxy(&YourService{})包装，否则rm模块无法识别和调度
AT 模式 vs TCC 模式在 Go 中的真实性能差异
很多人以为 TCC 一定更快，实际要看瓶颈在哪。AT 模式在分支事务提交时立即释放数据库行锁，全局锁由 TC 管理（存在 Redis 或 DB），所以数据库压力小；而 TCC 的 Prepare 阶段如果做了大量校验或远程调用，反而会拖慢整体耗时。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- AT 模式写入
UNDO_LOG表有 IO 开销，但可异步清理；TCC 不写日志，但每个阶段都是同步 RPC 调用 - TC 对 TCC 分支的超时控制粒度更粗——
Confirm失败后不会自动重试Cancel，需你自己在Cancel方法里处理幂等和重试 - 若服务间网络延迟高，TCC 的两轮 RPC（Try + Confirm/Cancel）比 AT 的一阶段提交 + 异步回滚更敏感
Go 中接入 TCC 最容易漏掉的初始化步骤
不同于 Java 的注解扫描，Go 的 seata-go 必须显式注册资源并启动 TM/RM 客户端。漏掉任一环节，Prepare 调用就变成普通函数，TC 根本收不到分支事务注册请求。
- 调用
client.Init()后，必须紧接着调用rm.GetRmCacheInstance().GetResourceManager(branch.BranchTypeTCC).RegisterResource(...) -
tm.WithGlobalTx的 context 必须携带从 TC 获取的XID，HTTP 场景下要靠req.Header.Set("XID", rootContext.GetXID())透传，gRPC 场景则需自定义拦截器注入 metadata -
TCCResource的ResourceGroupId必须与配置文件中service.vgroup-mapping的值严格匹配，否则 TC 找不到对应分组，直接拒绝注册
真正难的不是写三个方法，而是让 Confirm 和 Cancel 在任意时刻、任意重试次数下都能安全执行——这要求所有状态变更操作自带幂等键，且不能依赖本地内存缓存。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
