rollbackFor用于指定触发事务回滚的异常类型，默认仅对RuntimeException和Error回滚；受检异常需显式配置，如@Transactional(rollbackFor = IOException.class)，且必须继承Exception而非RuntimeException。
Java 中声明式事务的 rollbackFor 用于明确指定哪些异常类型会触发事务回滚。默认情况下，Spring 只对 RuntimeException 及其子类、Error 自动回滚；而 Exception 及其子类（即受检异常）不会回滚，必须显式配置。
基本写法：直接在 @Transactional 中指定异常类
支持单个或多个异常类型，注意必须使用 .class 后缀：
- 单个受检异常：
@Transactional(rollbackFor = IOException.class) - 多个异常：
@Transactional(rollbackFor = {IOException.class, SQLException.class}) - 混用运行时与受检异常：
@Transactional(rollbackFor = {CustomBizException.class, IllegalArgumentException.class})
关键前提：确保异常是真正抛出的受检异常
只有继承自 Exception（且非 RuntimeException 子类）的异常才需要 rollbackFor。例如：
- ✅ 正确（受检异常）：
public class InsufficientBalanceException extends Exception - ❌ 无效（运行时异常）：
public class InsufficientBalanceException extends RuntimeException—— 默认就回滚，无需配置
如果方法签名写了 throws Exception 但实际没抛出，或抛出的是包装后的新异常（如 new RuntimeException(e)），rollbackFor 不会生效。
立即学习“Java免费学习笔记（深入）”；
常见失效原因和避坑点
-
异常被吞掉：方法内
try-catch后未重新抛出，事务切面无法感知异常 -
调用方式错误：本类中
this.method()直接调用，绕过 Spring 代理，事务不生效 -
访问权限不足：注解加在
private或protected方法上，Spring 无法织入事务逻辑 -
noRollbackFor 优先级更高：若同时配置了
noRollbackFor = BusinessException.class，即使它也在rollbackFor列表里，也不会回滚
更推荐的实践方式
除非受限于外部 SDK 或历史规范，否则建议：
- 将业务异常统一定义为
RuntimeException子类（如BusinessException extends RuntimeException），避免重复写rollbackFor - 减少在 service 方法上声明
throws Exception，降低事务配置负担 - 必要时配合
propagation控制传播行为，比单纯依赖回滚更可控
