如果spring事务中出现了RuntimeException CheckedException,事务会如何处理

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对比：直接throwRuntimeException更清晰、更易测试；而setRollbackOnly()适合需要统一返回码、不暴露异常细节的API层

嵌套事务与REQUIRES_NEW的陷阱

PROPAGATION_REQUIRES_NEW看似能隔离子事务，但实际会挂起父事务，生成全新事务——这意味着父事务的隔离级别、超时设置、甚至数据库连接都失效了。

• 日志/审计写入可能丢失：如果父事务回滚，而子事务（如发MQ消息）已提交，会出现状态不一致
• 不能依赖父事务的数据库连接：REQUIRES_NEW 强制获取新连接，可能触发连接池耗尽
• 慎用于“记录操作日志”：应优先用事件驱动或异步补偿，而非REQUIRES_NEW硬写库

真正需要隔离的场景，比如支付扣款+积分变更，建议拆成两个独立服务调用，靠最终一致性保障，而不是堆砌事务传播属性。

https://www.php.cn/faq/1998193.html