Spring默认仅对RuntimeException及其子类、Error回滚事务，对IOException等Checked Exception不回滚；需用rollbackFor显式声明，且@Transactional仅对public方法生效，自调用、异常被吞等场景会导致失效。
Java中哪些异常会导致Spring事务自动回滚
Spring默认只对 RuntimeException 及其子类、Error 触发事务回滚，对普通 Exception（如 IOException、SQLException）不会回滚。这是最容易踩的坑——你抛了 Exception，数据库却已提交。
- 显式声明回滚：用
@Transactional(rollbackFor = Exception.class)覆盖默认行为 - 避免吞掉异常：在
try-catch中捕获后没重新抛出或没调用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()，事务照样提交 -
checked exception不触发回滚不是Bug，是Spring的设计选择——它假设你捕获这类异常后会主动处理业务逻辑分支
@Transactional 失效的常见场景
事务失效往往和代理机制有关，不是配置错了，而是代码没落在Spring代理能拦截到的位置。
- 自调用失效：同一个类里方法A调用本类的@Transactional方法B，B的事务注解不生效（因为走的是this.B()，没经过CGLIB/JDK代理）
- 非public方法：@Transactional 只对
public方法有效；protected、private或包级方法加了也无效 - 异常被吞：catch住异常后既没throw，也没调用
setRollbackOnly() - 使用了错误的事务管理器：比如配置了
JpaTransactionManager，但DAO层用的是JDBC模板，事务无法传播
手动控制回滚：setRollbackOnly() vs throw新异常
当业务逻辑需要“条件性回滚”，又不想抛出异常中断流程时，setRollbackOnly() 是唯一可靠方式。
- 必须在事务上下文中调用：
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly() - 不能替代异常抛出：它只标记回滚，不终止方法执行；后续代码仍会运行，可能引发脏数据或NPE
- 与throw对比：直接throw
RuntimeException更清晰、更易测试；而setRollbackOnly()适合需要统一返回码、不暴露异常细节的API层
if (user.getBalance() < order.getAmount()) {
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
return Result.fail("余额不足");
}
嵌套事务与REQUIRES_NEW的陷阱
PROPAGATION_REQUIRES_NEW 看似能隔离子事务，但实际会挂起父事务，生成全新事务——这意味着父事务的隔离级别、超时设置、甚至数据库连接都失效了。
立即学习“Java免费学习笔记（深入）”；
- 日志/审计写入可能丢失：如果父事务回滚，而子事务（如发MQ消息）已提交，会出现状态不一致
- 不能依赖父事务的数据库连接：REQUIRES_NEW 强制获取新连接，可能触发连接池耗尽
- 慎用于“记录操作日志”：应优先用事件驱动或异步补偿，而非REQUIRES_NEW硬写库
真正需要隔离的场景，比如支付扣款+积分变更，建议拆成两个独立服务调用，靠最终一致性保障，而不是堆砌事务传播属性。
