简介面向中高级 Spring Boot 开发者的代码类技术笔记聚焦事务使用与回滚这一高频疑难解决 Transactional 不生效、异常被吞掉后数据仍提交等实际问题。文档从开启事务管理讲起说明 EnableTransactionManagement 与 Transactional 的使用边界强调只有 public 方法可被代理并解释默认仅对 RuntimeException 与 Error 自动回滚随后通过 rollbackFor Exception.class 展示如何覆盖检查性异常并结合 try-catch 吞异常、finally 中 return 等典型场景直观说明事务未回滚的原因以及使用 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly() 手动回滚的写法。此外还梳理了 REQUIRED、REQUIRES_NEW 等传播行为便于理解嵌套调用下的隔离边界。资源为单个 docx 文档压缩包仅 136KB无需搭建环境、打开即用轻量易读适合个人复习或团队内部培训速查目前已有 400 人学习下载。对事务边界把握不准、排错缺乏头绪的开发者可从中获得可落地的配置思路与排查方向。1. 事务边界比想象中窄从一次库存扣减事故看 SpringBoot 事务默认行为接手过一个库存系统业务方反馈了一个诡异现象订单创建失败但库存却被扣掉了。查日志发现 Service 层方法正常执行完异常发生在 Controller 层组装响应时——一个空指针导致接口返回 500而数据库里库存字段已经变了。这个案例几乎完美复现了 SpringBoot 事务最容易踩的坑事务边界不是从接口进入到最后返回而是以 Transactional 注解标注的方法为界。方法一旦正常返回事务就提交了之后 Controller 层再抛什么异常都跟这次事务无关。很多人以为在 Service 方法上加个 Transactional 就万事大吉实际上 Spring 的声明式事务基于 AOP 代理它拦截的是目标方法的调用边界超出这个边界的所有操作都不受事务保护。本文以这份《SpringBoot的事务使用和回滚功能讲解》为基础把事务的生效条件、回滚策略、异常吞噬问题以及传播行为实际边界全部拆开讲一遍适合刚接触声明式事务的开发者也适合在线上排查过事务没回滚但始终没想通根因的熟手。2. 事务是怎么接管方法的代理链、public 限制与注解生效条件2.1 EnableTransactionManagement 到底做了什么Spring Boot 的自动配置机制让很多注解看起来加了没反应、不加也不报错。EnableTransactionManagement 就是典型例子官方文档说它用于开启注解驱动的事务管理但 Spring Boot 的 DataSourceTransactionManagerAutoConfiguration 在 classpath 下存在 Spring Data JPA 或 MyBatis 相关依赖时会自动注册事务管理器同时自动激活 Transactional 的解析。可以这样理解Spring Boot 应用里几乎不需要手动加 EnableTransactionManagement数据源和事务管理器一配好注解驱动就默认生效。但显式加上有两个实际价值一是明确表达该模块需要事务能力二是在自定义多数据源场景下你需要指定由哪个事务管理器来驱动注解。如果是单数据源项目不加也不影响行为如果是多数据源项目默认的事务管理器可能指向主数据源副数据源上的 Transactional 会静默失效。SpringBootApplication EnableTransactionManagement public class OrderApplication { public static void main(String[] args) { SpringApplication.run(OrderApplication.class, args); } }这里 EnableTransactionManagement 默认会查找容器中类型为 PlatformTransactionManager 的 Bean。Spring Boot 自动配置已经注册了一个所以上面这段代码在实际运行中和不写注解没有区别但保留了显式控制的能力。2.2 为什么只有 public 方法支持事务Spring 声明式事务的底层是 AOP 代理。默认使用 JDK 动态代理时代理对象只暴露接口方法切到 CGLIB 代理时虽然能代理类但 private、final 方法依然无法被增强。原因是 CGLIB 生成子类覆盖非 final 方法时private 方法本身就不参与继承分派调用方在编译期就绑定了目标对象的直接方法调用不会经过代理逻辑。Service public class OrderService { // 正确用法public 方法 Transactional Transactional(rollbackFor Exception.class) public void createOrder(OrderDTO dto) { orderMapper.insert(dto); stockService.deduct(dto.getSkuId(), dto.getCount()); } // 错误用法private 方法上注解不生效 Transactional private void deductStock(Long skuId, Integer count) { stockMapper.deduct(skuId, count); } }第二个方法的事务注解不会生效。调用 deductStock 的方法如果和它在同一个类里走的还是 this 引用根本没有经过代理对象。这是 Spring 事务失效最常见的场景排查时先看方法修饰符再看调用链路上有没有绕过代理。2.3 事务管理器与数据源的绑定关系事务管理器决定了一个事务最终作用在哪条数据库连接上。Spring Boot 默认创建的 DataSourceTransactionManager 绑定主数据源。如果你的项目里配置了多数据源就必须显式定义多个事务管理器并在 Transactional 注解中通过 transactionManager 属性指定使用哪一个。Bean public PlatformTransactionManager secondaryTransactionManager( Qualifier(secondaryDataSource) DataSource dataSource) { return new DataSourceTransactionManager(dataSource); } Transactional(transactionManager secondaryTransactionManager, rollbackFor Exception.class) public void writeToSecondary() { // 操作副库的业务逻辑 }不指定 transactionManager 时会按类型查找唯一的事务管理器多数据源场景下容器里有多个 PlatformTransactionManagerSpring 启动阶段会抛出 NoUniqueBeanDefinitionException。这一点在配置多数据源时要特别注意报错信息里的 bean 名称会直接告诉你缺了什么。3. 回滚规则与异常吞噬RuntimeException、rollbackFor 与 try-catch 的真实行为3.1 默认回滚规则为什么会漏掉检查性异常先看默认行为Transactional 不配置任何属性时Spring 只对 RuntimeException 和 Error 执行回滚检查性异常即 Exception 下非 RuntimeException 的子类不会触发回滚。这个设计初衷是检查性异常通常代表可预期的业务分支比如文件不存在、参数校验失败Spring 认为调用方可以处理这些情况不应该直接推翻整个事务而 RuntimeException 代表系统级异常程序无法继续正常执行需要回滚保持数据一致。Transactional public void createOrderWithCheckedException() throws IOException { orderMapper.insert(order); FileUtils.writeToDisk(order.getReceipt()); // 抛出 IOException }上面这个方法里orderMapper.insert 已经执行FileUtils.writeToDisk 抛出 IOException 时insert 操作不会回滚。文件写入失败但订单数据已经落库这种设备状态不一致的问题相当隐蔽。3.2 rollbackFor Exception.class 的完整写法把回滚范围扩大到所有异常只需要一个属性Transactional(rollbackFor Exception.class)。这个写法把检查性异常也纳入了回滚范围在实际业务系统中是主流做法因为绝大多数业务场景宁可全部回滚也不希望数据处于中间状态。Transactional(rollbackFor Exception.class) public void transferAmount(Long fromAccount, Long toAccount, BigDecimal amount) { accountMapper.decrease(fromAccount, amount); accountMapper.increase(toAccount, amount); // 假设这里的调用抛出业务异常检查性异常 if (amount.compareTo(BigDecimal.ZERO) 0) { throw new BizException(转账金额不能为负数); } }BizException 是检查性异常时没有 rollbackFor 配置事务会照常提交转账双方金额各减各加数据直接错乱。加了之后会在抛出时触发回滚两条 SQL 都撤销。注意 rollbackFor 的值是异常的 Class 对象配置 Exception.class 就把所有 Exception 子类都覆盖了不用再单独列 RuntimeException。3.3 try-catch 吞掉异常后事务为什么成功提交这是实际开发中翻车率最高的场景。把抛出异常的逻辑放进 try-catchcatch 块里打了日志但没有重新 throwSpring 的代理逻辑看到的是方法正常返回判定业务执行成功于是提交事务。数据库的值已经写进去但业务侧没有感知到任何异常。Transactional(rollbackFor Exception.class) public void createOrderWithoutRethrow(OrderDTO dto) { try { orderMapper.insert(dto); int result stockClient.deduct(dto.getSkuId(), dto.getCount()); if (result 0) { throw new BizException(库存不足); } } catch (BizException e) { log.error(库存扣减失败订单创建流程继续但数据已写入, e); // 没有重新抛出异常 } }orderMapper.insert 执行成功stockClient.deduct 抛出库存不足异常被 catch 捕获后没有重新抛出整个方法正常返回——事务提交订单数据落库。这种代码在逻辑上是有意的但错误被吞掉后事务不会被感知到。3.4 手动回滚的正确打开姿势setRollbackOnly被 catch 捕获且不想重新抛出异常时想让事务回滚就必须主动标记。TransactionAspectSupport.currentTransactionStatus().setRollbackOnly() 是官方提供的编程式回滚入口它把当前事务标记为 rollback-only事务管理器在方法返回后执行回滚而不是提交。Transactional(rollbackFor Exception.class) public void createOrderWithManualRollback(OrderDTO dto) { try { orderMapper.insert(dto); int result stockClient.deduct(dto.getSkuId(), dto.getCount()); if (result 0) { throw new BizException(库存不足); } } catch (BizException e) { log.error(库存扣减失败手动回滚, e); TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); } }TransactionAspectSupport.currentTransactionStatus() 获取的是当前线程绑定的事务状态对象setRollbackOnly 只是打标记真正回滚动作由事务拦截器在方法返回时执行。需要留意的是这行代码必须在事务方法内部执行脱离事务上下文调用会抛出 NoTransactionException。3.5 finally 里的 return 如何覆盖异常还有一种更隐蔽的写法catch 里重新抛出了异常但 finally 块里带 returnJava 编译器允许 finally 的 return 覆盖 catch 抛出的异常事务拦截器看到的还是方法正常返回。Transactional(rollbackFor Exception.class) public void createOrderWithFinallyReturn(OrderDTO dto) { try { orderMapper.insert(dto); throw new BizException(业务异常); } catch (BizException e) { log.error(捕获异常并重新抛出, e); throw new BizException(e); } finally { return; // 覆盖了 catch 里抛出的异常事务拦截器认为方法正常返回 } }代码里 catch 明显抛出了新异常但 finally 的 return 会把异常吞掉方法直接返回事务判定为成功并提交。这个语法层面的坑在编译期不报错、运行时也没有堆栈只有在数据层面发现异常落库才能定位到。规避方式就一条不要在 finally 块里写 return这属于 Java 层面公认的反模式在事务方法里危害加倍。4. 传播机制与嵌套调用的实际边界从 service 调用 service 说起4.1 七种传播行为如何影响嵌套事务Spring 在 Transactional 中通过 propagation 属性控制事务的传播行为实际开发中主要用到两种REQUIRED 和 REQUIRES_NEW。默认值是 REQUIRED当前存在事务则加入没有则新建REQUIRES_NEW 则是挂起当前事务新建一个独立事务。传播行为外层有事务外层无事务典型用途REQUIRED加入外层事务新建事务默认值大部分业务REQUIRES_NEW挂起外层新建独立事务新建事务日志记录、审计NESTED创建嵌套事务JDBC 保存点新建事务分段回滚SUPPORTS加入事务以非事务方式执行查询操作NOT_SUPPORTED挂起事务非事务执行非事务执行大文件导出MANDATORY加入事务抛异常强制事务上下文NEVER抛异常非事务执行禁止事务场景REQUIRES_NEW 的典型场景是审计日志无论主业务是否回滚操作记录必须写入。如果日志表操作和主业务共用事务主业务回滚时日志也没了完全失去审计意义。REQUIRES_NEW 让日志事务独立提交不受主事务影响。4.2 同一个类里方法互调为什么传播行为失效事务传播行为有一个常见的失效场景同一个类内部方法直接调用比如 Service 方法 A 调用了同类中的方法 B而 B 标注了 TransactionalB 的事务不会生效。原因和 private 方法事务失效一样方法调用没有经过代理对象this.method() 直接调的是原生方法。Service public class OrderService { Transactional(rollbackFor Exception.class) public void createOrder(OrderDTO dto) { // 直接调用同类方法事务注解不生效 this.deductStock(dto.getSkuId(), dto.getCount()); } Transactional(propagation Propagation.REQUIRES_NEW, rollbackFor Exception.class) public void deductStock(Long skuId, Integer count) { stockMapper.deduct(skuId, count); } }deductStock 的 REQUIRES_NEW 不会生效它只是 createOrder 事务里的普通数据库操作异常时不会独立回滚而是跟着外层事务一起回滚。要解决这个问题把 deductStock 拆到单独的 Service 类里或者注入自身代理对象再或者用 AopContext.currentProxy() 获取代理后调用。4.3 自调用场景的三种改写方式自调用场景的推荐方案是拆分独立类其次是注入代理对象。拆分独立类最符合 Spring 的设计哲学把可复用的业务操作提取到独立 Service代理链路清晰也方便单元测试。Service public class OrderService { private final StockService stockService; public OrderService(StockService stockService) { this.stockService stockService; } Transactional(rollbackFor Exception.class) public void createOrder(OrderDTO dto) { stockService.deduct(dto.getSkuId(), dto.getCount()); } } Service public class StockService { Transactional(propagation Propagation.REQUIRES_NEW, rollbackFor Exception.class) public void deduct(Long skuId, Integer count) { stockMapper.deduct(skuId, count); } }两块逻辑在不同类里Spring 代理能正常拦截 StockService.deduct 的调用REQUIRES_NEW 生效。注意如果 StockService.deduct 自己内部再调用同类别的另一个 Transactional 方法同样会失效多层嵌套时要逐层检查调用链。5. 事务提交与否的验证技巧从日志到拦截器确认回滚真实发生5.1 在日志中观测事务提交与回滚Spring 的事务抽象层预留了日志输出能力把日志级别调到 DEBUG 就能看到事务管理的完整轨迹。logging: level: org.springframework.jdbc.datasource.DataSourceTransactionManager: DEBUG org.springframework.transaction: DEBUG org.springframework.jdbc.support.JdbcTransactionManager: DEBUG配置后运行时日志会出现关键标记Creating new transaction 开启新事务Initiating transaction commit 表示执行提交Initiating transaction rollback 表示执行回滚Rolling back to savepoint 表示回滚到保存点。看到 commit 而你预期应该回滚的日志时就能快速定位到异常吞噬或者边界问题。5.2 用 TransactionSynchronizationManager 查看当前事务状态TransactionSynchronizationManager 提供了获取当前事务信息的静态方法可以直接在业务代码里打印出来辅助排查。Transactional(rollbackFor Exception.class) public void createOrder(OrderDTO dto) { boolean isActualTransactionActive TransactionSynchronizationManager.isActualTransactionActive(); String currentTransactionName TransactionSynchronizationManager.getCurrentTransactionName(); log.info(事务是否激活: {}, 事务名称: {}, isActualTransactionActive, currentTransactionName); // 业务逻辑 }isActualTransactionActive 返回 true 说明当前线程确实绑定了一个激活状态的事务false 说明方法根本没被事务代理拦截。getCurrentTransactionName 返回事务方法名可以核对注解是否作用在预期的方法上。5.3 下沉一个实用的回滚验证工具方法实际项目中可以封装一个回滚工具类专门处理 catch 块里不想重新抛异常但必须回滚的场景Component public class TransactionHelper { private static final Logger log LoggerFactory.getLogger(TransactionHelper.class); public static void rollback(String reason) { TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); log.warn(事务标记为回滚, 原因: {}, reason); } public static void rollbackQuietly(String reason) { try { TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); log.warn(事务标记为回滚, 原因: {}, reason); } catch (Exception e) { log.error(标记回滚失败, 可能当前没有事务上下文, 原因: {}, reason, e); } } }rollbackQuietly 在事务上下文缺失时不会抛出异常适合用在捕获异常后不确定当前是否处于事务边界的场景。调用方在 catch 块里执行 TransactionHelper.rollbackQuietly(订单创建失败) 即可完成回滚标记。注意这个工具方法在 Transactional 标注的方法内才有效脱离开事务上下文调用没有任何副作用因为内部已经捕获了 NoTransactionException。5.4 一个组合验证动作错误日志 数据库对照排查线上问题时我的习惯做法是三步走第一步开启 DataSourceTransactionManager 的 DEBUG 日志观察日志里 commit 还是 rollback第二步在 catch 块里临时打印 TransactionSynchronizationManager.isActualTransactionActive() 确认事务上下文确实存在第三步在数据库侧对比操作前后的数据快照确认最终提交结果。三步组合起来事务边界、异常吞噬、回滚标记三个问题基本都能一次性定位。本文还有配套的精品资源点击获取