Spring事务不回滚的根本原因是异常被try-catch拦截未抛出，导致事务切面无法感知；需确保异常穿透方法边界，或通过重抛运行时异常、手动setRollbackOnly、显式抛受检异常并配置rollbackFor来修复。
Spring 事务不回滚，不是因为“异常太晚出现”，而是因为事务切面根本没看到异常——try-catch 把异常拦在了方法内部，事务管理器误以为一切顺利执行完毕。只要异常没“逃出方法体”，@Transactional 就不会触发回滚逻辑。
为什么吞掉异常就等于放弃回滚
Spring 声明式事务基于 AOP 代理，核心判断逻辑非常简单：方法结束时有没有未捕获的、匹配 rollbackFor 规则的异常？
- 默认只对
RuntimeException和Error自动回滚；IOException、SQLException等受检异常不会触发回滚，除非显式配置rollbackFor = Exception.class - 哪怕加了
@Transactional(rollbackFor = Exception.class)，前提是异常必须穿透方法边界，被代理层捕获到 -
catch { log.error(...); }或catch { return "fail"; }都等于主动切断传播路径，事务切面完全无感知
三种可靠且常用的修复方式
业务中往往需要捕获异常做日志、返回提示或清理资源，完全不 catch 并不现实。下面三种方式兼顾健壮性与可维护性：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
重抛为运行时异常：在 catch 中立即封装并抛出
RuntimeException，例如throw new RuntimeException("操作失败", e);。简洁、符合 Spring 设计意图，推荐作为首选 -
手动标记回滚：调用
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();。适合不能抛异常的场景（比如要返回统一 DTO、需执行收尾逻辑） -
显式抛出原异常（需配套配置）：若坚持抛
Exception子类，必须同时满足两个条件——方法签名声明该异常（如throws SQLException），且@Transactional明确指定rollbackFor = SQLException.class，否则无效
快速验证是否真解决了问题
别只看代码改了没，要用实际行为确认：
立即学习“Java免费学习笔记（深入）”；
- 开启事务调试日志：
logging.level.org.springframework.transaction=DEBUG，观察日志中是否出现Initiating transaction rollback；若只有Completing transaction，说明仍被提交 - 写隔离单元测试：让 DAO 层明确抛出
SQLException，Service 层 try-catch 但不做重抛或手动回滚，断言数据库记录是否残留 - 检查代理是否生效：日志中应有
TransactionInterceptor.invoke调用记录；若无，可能是自调用（this.method()）、非 public 方法或 Bean 未被 Spring 托管
容易踩的隐藏陷阱
有些写法看似正确，实则不起作用：
-
noRollbackFor配置会覆盖rollbackFor，例如全局设置spring.transaction.no-rollback-for: java.io.IOException，会让所有IOException永远不回滚 - 嵌套异常未解包：比如
ExecutionException包裹了真实的SQLException，直接匹配rollbackFor = SQLException.class会失败，需用e.getCause()获取真实类型 - 自调用绕过代理：
this.transfer()不走代理，事务压根不启动，和“吞异常”无关，但现象相似，需单独排查
