Java中异常是否触发事务回滚取决于异常类型、事务配置及处理方式：默认仅RuntimeException和Error导致回滚；checked异常需显式配置rollbackFor；捕获后未重抛或未设setRollbackOnly则事务不回滚；非public方法上@Transactional无效；传播行为如REQUIRES_NEW使内层异常不影响外层事务。
Java中异常确实会影响事务，但不是所有异常都会导致回滚——关键看异常类型、事务配置以及是否被正确捕获和处理。
哪些异常会触发事务回滚
Spring默认只对unchecked异常（即继承自RuntimeException或Error）自动回滚事务。比如NullPointerException、IllegalArgumentException、SQLException（若未被捕获）等。
- checked异常（如
IOException、SQLException显式抛出且未声明回滚）默认不会回滚 - 可通过
@Transactional(rollbackFor = Exception.class)强制对所有异常回滚 - 也可用
noRollbackFor指定某些异常不回滚（如业务异常BusinessException）
异常被“吃掉”就等于事务失效
如果在@Transactional方法内捕获了异常但没重新抛出，事务管理器根本感知不到异常发生，就会正常提交。
- 错误写法：
try { doDBOperation(); } catch (Exception e) { log.error(e); }→ 事务照常提交 - 正确做法：捕获后要么重新抛出（
throw e;），要么明确标记回滚（TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();）
非public方法加@Transactional无效
@Transactional基于动态代理实现，只能拦截public方法调用。private、protected或包级方法上的注解会被忽略，即使抛出异常也不会触发回滚。
立即学习“Java免费学习笔记（深入）”；
- 常见陷阱：在同一个类中，public方法A调用private方法B，B里抛异常 → A的事务不受影响
- 解决方式：拆分到不同Bean，或使用
AopContext.currentProxy()（需开启expose-proxy）
事务传播行为也会影响异常处理效果
比如PROPAGATION_REQUIRES_NEW会挂起外层事务，新建独立事务。此时内层事务的异常只回滚自己，不影响外层；而PROPAGATION_SUPPORTS不支持事务，异常根本不会触发回滚。
- 默认
REQUIRED：加入当前事务，异常统一回滚 - 调试时可结合日志确认实际生效的事务边界（如查看“Creating new transaction”或“Participating in existing transaction”）
基本上就这些。事务和异常的配合不是自动可靠的，得靠设计+配置+代码习惯三者到位。
