默认仅runtimeexception和error触发spring事务回滚；检查异常需通过rollbackfor显式配置；事务失效还常因方法非public、自调用、未启用事务管理等导致。
在Java中，异常确实可能导致事务失效或触发回滚，但并非所有异常都会导致事务回滚，关键取决于异常类型、事务配置方式（如Spring的@Transactional）以及传播行为等细节。
默认情况下只有运行时异常（RuntimeException）和错误（Error）触发回滚
Spring的@Transactional默认只对未检查异常（即继承自RuntimeException）和Error自动回滚。比如：
NullPointerExceptionIllegalArgumentExceptionOutOfMemoryError
而像IOException、SQLException这类检查异常（Checked Exception），即使抛出，事务也不会自动回滚——除非显式配置。
如何让检查异常也触发回滚
通过@Transactional的rollbackFor属性指定：
立即学习“Java免费学习笔记（深入）”；
@Transactional(rollbackFor = {IOException.class, SQLException.class})
也可以写成更宽泛的形式：
-
rollbackFor = Exception.class（慎用，可能掩盖预期的业务异常处理逻辑） -
noRollbackFor = {CustomBizException.class}：明确排除某些异常不回滚
事务失效的常见“非异常”原因
比异常更隐蔽的是事务根本没生效，常见情况包括：
- 方法不是
public：Spring AOP代理仅对public方法生效 - 自调用问题：同一个类内方法A调用带
@Transactional的方法B，B的事务注解不会生效（代理未介入） - 未启用事务管理：忘了加
@EnableTransactionManagement或对应XML配置 - 使用了错误的数据源或事务管理器：比如多数据源时未正确指定
transactionManager
手动控制回滚的方式
除了声明式事务，还可以编程式干预：
- 在方法内调用
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly() - 适用于复杂判断逻辑下“不抛异常但也要回滚”的场景
注意：该操作不可逆，且需确保当前确实在事务上下文中，否则会抛NoTransactionException。
事务回滚机制不是“有异常就回滚”的简单逻辑，而是由框架规则、配置和代码结构共同决定的。理解默认行为、明确配置意图、排查代理失效点，才能真正掌控事务边界。
