Seata AT模式中，throws声明异常不会自动触发回滚，真正触发回滚的是@GlobalTransactional方法抛出未被捕获的业务异常，从而驱动TM向TC发起globalRollback请求。
在 Seata 的 AT 模式中，throws 声明异常本身**不会自动触发全局回滚**。真正触发二阶段回滚的关键是：**全局事务的发起方（TM）主动向 TC 发起 globalRollback 请求**，而这个动作通常由业务方法抛出**未被捕获的、被 Seata 认为是“业务异常”的异常**来驱动。
一、Seata AT 模式回滚的触发逻辑
AT 模式下，Seata 通过代理数据源在 SQL 执行时自动记录 before image 和 after image，并注册分支事务。但是否回滚，取决于全局事务的最终状态：
- 全局事务成功：TC 通知各 RM 执行
commit（异步清理 undo log） - 全局事务失败：TC 通知各 RM 执行
rollback（根据 undo log 恢复数据）
而“全局事务失败”是由 全局事务的根方法（即标注 @GlobalTransactional 的方法）抛出未处理的异常决定的，不是靠 throws 声明，而是靠 实际抛出。
二、“throws” 声明的作用与误区
throws 只是方法签名的一部分，用于声明可能抛出的检查型异常（checked exception），它本身不改变执行流，也不通知 Seata。
立即学习“Java免费学习笔记（深入）”；
- 如果方法只写
throws Exception，但内部没抛，全局事务仍会正常提交 - 如果方法抛出的是
RuntimeException或其子类（如IllegalArgumentException），且未被捕获，Seata 默认将其视为业务异常，触发全局回滚 - 如果抛出的是 checked exception（如
IOException），而@GlobalTransactional方法没有显式 catch，该异常向上冒泡，同样会触发回滚（因为它是未处理的异常）
三、确保二阶段回滚生效的关键做法
-
在全局事务入口方法上使用
@GlobalTransactional，且该方法不能吞掉异常（避免空 catch 或 try-catch 后 return） -
避免在 @GlobalTransactional 方法内捕获后“静默处理”异常，例如：
❌ 错误示范：try { doBusiness(); } catch (Exception e) { log.error("忽略异常"); }→ 全局事务会正常提交 -
如需区分“业务失败”和“系统异常”，可通过
rollbackFor显式指定：@GlobalTransactional(rollbackFor = BusinessException.class)→ 只有抛出BusinessException及其子类才回滚 - 分支事务（如 Dubbo 调用、MQ 生产者等）必须正确参与全局事务，否则即使主事务回滚，下游可能已提交（形成悬挂事务）
四、一个典型可回滚的代码结构
以下代码能触发 Seata 二阶段全局回滚：
@GlobalTransactional
public void placeOrder(Order order) throws OrderException {
// 本地扣库存（Seata 自动代理，生成 branch）
storageService.deduct(order.getProductId(), order.getCount());
// 远程调用（需集成 Seata RPC 适配器，如 seata-dubbo、seata-spring-cloud-alibaba）
accountService.debit(order.getUserId(), order.getAmount());
// 主动抛出异常 → 触发 globalRollback
throw new OrderException("库存不足，下单失败");
}
此时，Seata TM 捕获到未处理的 OrderException，向 TC 发起回滚请求；TC 驱动所有已注册的分支（storage、account）执行 undo。
