直接回答：2PC（XA）由协调者分“准备-提交”两阶段驱动所有参与者，任一节点 prepare 失败则全体回滚，强一致但同步阻塞——协调者宕机时参与者持有锁进退两难。3PC 增加预询问（canCommit）与参与者超时自动提交，降低阻塞概率但分区下仍可能数据不一致，实践中几乎没人用。TCC 把事务挪到业务层：Try 预留资源（冻结库存）、Confirm 确认扣减、Cancel 释放预留，靠业务幂等与状态机推进，不锁数据库行，吞吐量高，是互联网高并发场景的主流。

展开解析：工程取舍的本质是一致性与可用性的兑换：2PC 一致性最强（数据库层 XA 协议兜底），代价是同步锁持有时间长、吞吐低、协调者单点，适合金融核心这类“宁可慢不可错”的低并发链路；TCC 可用性高、粒度可控，但把事务复杂度转移给业务——每个操作要拆三个接口、处理空回滚（Try 没执行却收到 Cancel）、悬挂（Cancel 先于 Try 到达）与幂等，开发成本数倍于本地事务。落地建议：跨服务调用优先用“本地消息表/事务消息 + 最终一致”规避分布式事务本身；必须强一致再看 TCC（Seata 框架能接管状态机）；XA 只在同构数据库短事务里考虑。还要清醒：这些方案都解决不了业务补偿语义（退款不是简单的回滚）， Saga 与对账系统仍是最后的兜底。

追问方向：TCC 的空回滚与悬挂分别怎么处理？Seata AT 模式与 TCC 有何本质差异？

（约 490 字）