简介：面向中高级 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 时会按类型查找唯一的事务管理器，多数据源场景下容器里有多个 PlatformTransactionManager，Spring 启动阶段会抛出 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-catch，catch 块里打了日志但没有重新 throw，Spring 的代理逻辑看到的是方法正常返回，判定业务执行成功，于是提交事务。数据库的值已经写进去，但业务侧没有感知到任何异常。
@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 块里带 return，Java 编译器允许 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 标注了 @Transactional，B 的事务不会生效。原因和 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() 确认事务上下文确实存在；第三步在数据库侧对比操作前后的数据快照，确认最终提交结果。三步组合起来，事务边界、异常吞噬、回滚标记三个问题基本都能一次性定位。
本文还有配套的精品资源，点击获取
