内部捕获并“吞掉”异常是Spring声明式事务失效的高频原因——事务看似执行了，但异常未上抛导致回滚逻辑不触发，最终数据部分写入、状态不一致；排查关键在于确认异常是否穿透到代理层，重点检查try-catch是否未重抛、是否为checked异常且未配置rollbackFor、是否缺少事务DEBUG日志验证。
内部捕获并“吞掉”异常是 spring 声明式事务失效的高频原因——事务看似执行了，但异常没上抛，回滚逻辑根本不会触发，最终导致数据部分写入、状态不一致。排查这类问题，关键不是看有没有 @transactional，而是看异常是否真正穿透到了代理层。
确认事务方法中是否存在 try-catch 且未重新抛出
这是最直接的切入点。检查带 @Transactional 的方法体，重点找：
- 是否有
try { ... } catch (Exception e) { /* 空处理 or 只打日志 */ } - 是否有
catch块里调用了e.printStackTrace()或log.error(...)，但没throw e或throw new RuntimeException(e) - 是否在 catch 中做了补偿操作（如发消息、更新状态），却忘了事务本身已无法回滚
验证异常类型是否被 Spring 默认支持
Spring 默认只对 运行时异常（RuntimeException 及其子类） 自动回滚。如果 catch 的是 IOException、SQLException、FileNotFoundException 这类检查异常（checked exception），即使你再 throw 出去，事务也不会响应——除非显式配置。
检查注解是否包含 rollbackFor：
- ❌ 错误写法：
@Transactional public void transfer(...) { try { ... } catch (SQLException e) { log.error(e); } } - ✅ 正确写法：
@Transactional(rollbackFor = {SQLException.class, Exception.class}) public void transfer(...) { ... }，或统一用rollbackFor = Exception.class
观察日志与调试代理调用链
开启 Spring 事务相关 DEBUG 日志，能快速暴露事务是否真正介入：
- 在
application.properties中添加：
logging.level.org.springframework.transaction=DEBUG
logging.level.org.springframework.jdbc.datasource.DataSourceTransactionManager=DEBUG - 正常事务开启时，会打印类似
Creating new transaction with name [xxx]: PROPAGATION_REQUIRED... - 如果方法执行全程无任何事务日志，说明代理根本没生效——可能异常被捕获后方法“安静结束”，事务拦截器甚至没机会判断要不要回滚
- 进阶：在
TransactionInterceptor.invoke()方法打断点，看方法执行完后是否进入completeTransactionAfterThrowing()—— 如果没进，基本可断定异常没抛到这一层
用最小可复现案例隔离验证
写一个极简测试方法，复现疑似场景：
- 建一个
@Service类，含一个@Transactional方法 - 方法内手动抛出
new SQLException("test")，不加任何 catch - 再写一个版本：加上
try-catch(SQLException e) { log.info("caught"); }，观察数据库是否回滚 - 对比两个结果。若前者回滚、后者不回滚，就坐实是“异常被吞”问题
