Spring事务默认仅对RuntimeException回滚，受检异常需显式配置rollbackFor；且事务依赖AOP代理，同类内直接调用会失效；传播行为与异常类型共同决定回滚范围。
Spring事务默认只对RuntimeException回滚
Spring的@Transactional注解默认采用「只对未检查异常（即RuntimeException及其子类）自动触发回滚」的策略。这意味着，如果你手动抛出Exception、IOException或SQLException这类受检异常（checked exception），事务**不会自动回滚**，即使方法已标注@Transactional。
常见错误现象：数据库写入成功，但业务逻辑因new Exception("xxx")中断，外部却看不到数据回滚——根本原因是Spring没把它当“事务失败信号”。
- 默认行为由
TransactionDefinition.getDefaultTimeout()和rollbackFor配置共同决定，但rollbackFor不设时仅响应RuntimeException - 受检异常必须显式声明：
@Transactional(rollbackFor = Exception.class)或更精确地指定rollbackFor = {IOException.class, SQLException.class} - 若用
try-catch吞掉了异常，且未重新抛出或调用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()，事务照样提交
被代理对象调用导致@Transactional失效
Spring事务基于AOP代理实现，只有**通过代理对象进入的方法**才能被TransactionInterceptor拦截。如果在同一个类里，方法A（带@Transactional）被本类另一个方法B直接调用（即this.methodA()），事务就完全不生效——因为绕过了代理，Spring根本没机会介入。
典型场景：Service内部分拆逻辑时，把数据库操作封装进private方法，再由public事务方法调用它；或者用this.saveOrder()而非注入自身bean来调用。
立即学习“Java免费学习笔记（深入）”；
- 解决方式一：把目标方法抽到另一个
@Service类中，通过Spring注入调用 - 解决方式二：在当前类中注入自己：
@Autowired private OrderService self;，然后用self.saveOrder() - 解决方式三：使用
TransactionTemplate在代码中显式控制事务边界，绕过代理限制
事务传播行为影响异常处理结果
当多个@Transactional方法嵌套调用时，propagation属性决定事务如何传递，而不同传播行为对异常的反应差异极大。例如PROPAGATION_REQUIRES_NEW会挂起外层事务、开启全新事务，此时内层事务抛异常只会回滚自己，不影响外层；而PROPAGATION_REQUIRED（默认）则共享同一事务上下文，任一层抛出未被捕获的回滚异常，整个事务都会回滚。
容易踩的坑是：以为加了@Transactional就“绝对安全”，却忽略了传播行为让异常隔离或扩散的方式完全不同。
-
PROPAGATION_NESTED支持保存点（savepoint），内层异常可回滚到保存点，外层仍可继续——但仅HikariCP + MySQL/Oracle支持，H2等嵌入式数据库通常不支持 -
PROPAGATION_SUPPORTS或PROPAGATION_NOT_SUPPORTED下，方法根本不运行在事务中，抛任何异常都不会触发回滚 - 修改传播行为后，务必同步检查异常是否仍在预期范围内被事务管理器捕获
自定义异常未继承RuntimeException时需显式配置
很多团队会定义自己的业务异常，比如InsufficientBalanceException。如果它直接继承Exception，哪怕语义上明显属于“应该回滚”的错误，Spring也不会自动处理——除非你在@Transactional里明确列出它。
示例：
@Transactional(rollbackFor = {InsufficientBalanceException.class, ValidationException.class})
public void transferMoney(Long fromId, Long toId, BigDecimal amount) {
// ...
if (balance < amount) {
throw new InsufficientBalanceException("余额不足");
}
}
- 更稳妥的做法是让所有需触发回滚的业务异常统一继承
RuntimeException，避免每个地方都写rollbackFor - 注意不要滥用
rollbackFor = Exception.class，它会让IO异常、空指针等本该暴露的程序错误也被静默回滚，掩盖真实问题 - 若使用Lombok的
@Data或@AllArgsConstructor，确保自定义异常有合适的构造函数（如含String message和Throwable cause），否则日志可能丢失根因
