如何通过7种场景代码实战吃透Spring事务传播行为？

作为后端开发，Spring 事务是日常工作的基础，但不少人只会用 @Transactional 注解加个 rollbackFor，对底层的事务传播行为一知半解。直到遇到“嵌套调用事务不回滚”“重复提交导致数据异常”等问题，才发现对传播行为的理解不足会踩大坑。 其实事务传播行为的核心很简单：当一个带有事务的方法，调用另一个方法时，如何决定新方法的事务边界（是复用当前事务，还是新建事务，或是不参与事务）。Spring 定义了 7 种标准传播行为，本文结合实际业务场景，逐一拆解每种行为的用法、代码示例和适用场景，帮你彻底吃透。 先铺垫两个基础前提，避免理解偏差： 所有示例基于 Spring Boot 2.x+，依赖 spring-boot-starter-data-jpa 或 mybatis-plus（本文用 JPA 简化数据库操作）； 事务传播行为仅对 @Transactional 注解修饰的方法生效，且必须通过 Spring 代理调用（同类方法内部调用需注意代理失效问题）。 一、Spring 7 种事务传播行为全解析 Spring 事务传播行为通过 propagation 属性配置，默认值为 REQUIRED。下面按“日常使用率”排序，逐一讲解。 1. REQUIRED（默认）：如果有事务就复用，没有就新建 核心逻辑：这是最常用的传播行为，遵循“能复用则复用，无则新建”的原则。如果调用方已经存在事务，被调用方就加入当前事务，两者共用一个事务边界（要么一起提交，要么一起回滚）；如果调用方没有事务，被调用方就新建一个独立事务。 业务场景：绝大多数核心业务流程，比如“创建订单+扣减库存”，两者必须在同一事务中，要么都成功，要么都失败。