Spring事务回滚取决于异常类型及是否穿透代理：默认仅RuntimeException、Error回滚；受检异常需显式rollbackFor配置；异常被吞则不回滚。
Spring 中事务是否回滚，不取决于“有没有异常”，而取决于“抛出的是什么异常、有没有被代理捕获到”。@Transactional 的行为由 TransactionAspectSupport 控制，它的 completeTransactionAfterThrowing 方法才是决定回滚与否的关键逻辑。
受检异常默认不回滚，是设计选择，不是 bug
Java 中的受检异常（如 IOException、SQLException、自定义 Exception）必须显式声明或捕获。Spring 认为这类异常属于“业务可预期、应主动处理”的场景，因此事务管理器不会自动介入回滚。
- throw new IOException("文件读取失败") → 事务照常提交，数据库变更保留
- 即使方法签名写了
throws IOException，也不影响默认行为 - 根本原因：TransactionAspectSupport 默认只将
RuntimeException及其子类、Error列入回滚候选
非受检异常天然触发回滚
运行时异常（NullPointerException、IllegalArgumentException、自定义 RuntimeException 子类）无需强制捕获，Spring 将其视为“意外崩溃”，默认纳入回滚范围。
- 只要抛出且未被吞掉，代理就能捕获并回滚整个事务
-
throw new RuntimeException("xxx")或throw new CustomRuntimeException()都生效 -
Error（如OutOfMemoryError）也默认回滚，但业务中不应主动 throw
让受检异常回滚：必须显式配置 rollbackFor
不能靠方法签名或 try-catch 捕获后重抛来“绕过”规则，必须在注解上明确声明：
- 全局兜底：
@Transactional(rollbackFor = Exception.class) - 精准控制更安全：
@Transactional(rollbackFor = {IOException.class, SQLException.class}) - 可与
noRollbackFor配合使用，例如排除某类业务异常：@Transactional(rollbackFor = Exception.class, noRollbackFor = BusinessException.class)
异常被吞掉，事务一定不回滚
事务回滚的前提是异常“穿透代理”。任何在方法内捕获后未重新抛出的行为，都会导致回滚失效。
- 错误写法：
try { ... } catch (IOException e) { log.error(e); }→ 事务提交，数据残留 - 补救方式一：在 catch 块末尾
throw new RuntimeException(e) - 补救方式二：手动标记回滚：
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()
