分布式事务回滚需依赖全局事务管理器统一协调，任一环节异常即触发所有分支回滚；@GlobalTransactional自动捕获异常并通知TC，本地事务须可逆、上下文不丢失，超时与网络异常需兜底处理，日志监控助定位失败原因。
在分布式事务中，异常触发的回滚不是靠单个数据库的 ROLLBACK 就能完成的，必须依赖事务协调机制来统一控制所有参与节点的动作。核心逻辑是：**只要任一环节抛出未捕获异常，全局事务管理器就要驱动所有分支事务回滚**。
全局事务注解自动捕获异常
使用 Seata、DTX 或 Spring Cloud Alibaba 的 @GlobalTransactional 时，框架会在方法入口开启全局事务上下文。一旦方法内抛出运行时异常（如 RuntimeException）或声明的检查异常（通过 rollbackFor 指定），框架会自动向 TC（Transaction Coordinator）发起回滚指令。
- 不需要手动调用
rollback()，异常传播到代理层即触发流程 - 建议显式指定回滚条件，例如
@GlobalTransactional(rollbackFor = Exception.class) - 避免
try-catch吞掉关键异常——若捕获后没重新抛出，框架无法感知失败
分支事务需保证本地可逆性
全局回滚能否成功，取决于每个微服务本地事务是否真正执行了回滚操作。这要求：
- 数据库操作必须在本地事务管理下进行（如 Spring 的
@Transactional） - 避免在事务方法内开启新线程或异步调用，否则脱离事务上下文
- 若使用 TCC 模式，
Cancel方法必须幂等且能真正释放 Try 阶段预留的资源（如冻结金额、锁定库存）
网络异常与超时场景的兜底处理
分布式环境下，协调者可能收不到某参与者的响应（如网络抖动、服务宕机）。此时不能无限等待，需依赖框架的超时回滚策略：
立即学习“Java免费学习笔记（深入）”；
- Seata 默认 60 秒未收到分支反馈，会主动向该分支发送回滚请求
- XA 协议中，参与者在 prepare 后长期无 commit 指令，应启动本地回滚定时任务
- 业务侧可配置重试 + 补偿任务（如定时扫描“状态为 PREPARING 超过5分钟”的订单，触发人工介入或自动 Cancel）
日志与监控辅助定位回滚失败原因
回滚失败往往不是代码写错，而是环境或配置问题。重点关注：
- 查看 TC 日志，确认是否发出 rollback 指令；再查各 TM（Transaction Manager）日志，看是否收到并执行
- 检查数据库连接是否启用 XA 支持（如 MySQL 需开启
innodb_support_xa=ON） - 确认分支事务的 resourceId（如数据源名）配置一致，否则 TC 找不到对应参与者
