Spring 事务传播机制是 Spring 事务中最核心也最易混淆的概念，它定义了一个带有事务的方法被另一个方法调用时，事务如何传递和生效（比如是否新建事务、是否加入已有事务、是否挂起事务等）。
核心前提：传播机制仅适用于Spring 管理的 Bean 之间的方法调用（即通过代理对象调用），内部调用仍会导致事务失效（前文提到过）。
一、先理解核心概念
事务传播机制解决的核心问题：当方法 A（有事务）调用方法 B（有/无事务）时，B 的事务如何与 A 的事务交互？
- 当前事务：调用方方法已存在的事务上下文；
- 新事务：被调用方方法重新创建的独立事务；
- 无事务：被调用方方法不使用任何事务。
二、Spring 事务传播机制（7种核心类型）
Spring 在 TransactionDefinition 接口中定义了 7 种传播行为，按使用频率和场景分为三大类：
| 传播行为常量 | 中文名称 | 核心规则（关键！） | 典型使用场景 |
|---|---|---|---|
| REQUIRED（默认） | 必须有事务 | 有则加入，无则新建 | 绝大多数业务场景（增删改） |
| SUPPORTS | 支持事务 | 有则加入，无则无事务 | 查询类方法（可选事务） |
| MANDATORY | 强制事务 | 有则加入，无则抛异常 | 必须在事务中执行的核心操作 |
| REQUIRES_NEW | 新建事务 | 无论有无，都新建事务，挂起当前事务 | 日志记录、异步通知（独立事务） |
| NOT_SUPPORTED | 不支持事务 | 无论有无，都无事务，挂起当前事务 | 纯内存操作（无需事务） |
| NEVER | 禁止事务 | 有事务则抛异常，无则无事务 | 绝对不允许在事务中执行的操作 |
| NESTED | 嵌套事务 | 有则嵌套（保存点），无则新建 | 主事务回滚不影响子事务（极少） |
逐类详解（附代码示例）
1. 最常用：REQUIRED（默认）
核心逻辑：调用方有事务则加入，无则新建。
这是 Spring 事务的默认传播行为，也是日常开发中 90% 场景的选择。
@Service
public class OrderService {@Autowiredprivate StockService stockService;// 调用方：有事务@Transactional(propagation = Propagation.REQUIRED)public void createOrder() {// 1. 保存订单（当前事务）saveOrder();// 2. 调用库存服务（加入当前事务）stockService.reduceStock();// 3. 任意一步失败，整个事务回滚}
}@Service
public class StockService {// 被调用方：REQUIRED（默认）@Transactionalpublic void reduceStock() {updateStock(); // 与创建订单在同一个事务中}
}
效果：
- 如果
createOrder先执行（有事务），reduceStock会加入该事务，两者同成功/同失败； - 如果直接调用
reduceStock（无事务），则新建事务执行。
2. 独立事务：REQUIRES_NEW
核心逻辑：无论调用方有无事务，都新建独立事务，原事务会被挂起，新事务执行完后恢复原事务。
适用于“即使主事务失败，子操作也必须提交”的场景（如记录操作日志）。
@Service
public class OrderService {@Autowiredprivate LogService logService;// 主事务@Transactionalpublic void createOrder() {saveOrder(); // 主事务操作try {// 调用日志服务（新建独立事务）logService.recordLog("创建订单");} catch (Exception e) {// 日志记录失败不影响主事务}// 主事务失败回滚，日志事务已提交，不会回滚}
}@Service
public class LogService {// 新建独立事务@Transactional(propagation = Propagation.REQUIRES_NEW)public void recordLog(String content) {insertLog(content); // 独立事务，与主事务无关}
}
关键区别（REQUIRED vs REQUIRES_NEW）：
| 场景 | REQUIRED | REQUIRES_NEW |
|---|---|---|
| 主事务回滚 | 子操作一起回滚 | 子操作已提交，不回滚 |
| 事务隔离 | 同一事务，共享锁/数据 | 独立事务，互不影响 |
3. 其他常用传播行为
- SUPPORTS：有事务则加入，无则无事务。适合查询方法（如
getOrderById），如果外层有事务则用，没有也能执行； - MANDATORY：必须在事务中执行，否则抛
IllegalTransactionStateException。比如核心资金操作，强制要求外层有事务； - NOT_SUPPORTED：无论有无事务，都以无事务执行。比如纯缓存操作，不需要事务；
- NEVER：绝对禁止事务，有则抛异常。比如某些敏感的非事务操作；
- NESTED：嵌套事务（基于数据库保存点），主事务回滚到保存点时，子事务可独立回滚，极少使用（依赖数据库支持，如 MySQL InnoDB）。
三、经典场景对比（帮你快速选型）
| 业务场景 | 推荐传播行为 | 原因 |
|---|---|---|
| 订单创建 + 库存扣减 | REQUIRED | 同成功/同失败 |
| 订单创建 + 操作日志记录 | REQUIRES_NEW | 日志必须保存，不受主事务影响 |
| 仅查询订单详情 | SUPPORTS | 有事务则用，无则直接查 |
| 核心资金转账操作 | MANDATORY | 强制外层有事务，避免裸奔 |
| 纯内存计算/缓存更新 | NOT_SUPPORTED | 无需事务，提升性能 |
四、避坑要点
- 传播机制仅对代理调用生效：同一类内部调用（如
A.method1()调用A.method2()），传播机制失效，仍遵循“内部调用事务失效”规则； - REQUIRES_NEW 可能导致锁问题：新建事务会持有数据库锁，若主事务执行时间长，可能导致锁等待；
- 嵌套事务（NESTED）依赖数据库：仅支持有保存点（Savepoint）的数据库（如 MySQL/Oracle），且 Spring 对其支持有限，尽量用 REQUIRES_NEW 替代；
- 异常处理影响传播效果：如果子事务抛异常但被主事务捕获，需手动设置回滚（
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()），否则可能导致事务状态不一致。
五、实战验证方法
想验证传播机制是否生效？推荐 2 种方式：
- 日志调试：开启 Spring 事务日志，查看事务创建/挂起/提交日志：
<!-- logback 配置 -->
<logger name="org.springframework.transaction" level="DEBUG"/>
<logger name="org.springframework.jdbc.datasource.DataSourceTransactionManager" level="DEBUG"/>
- 数据库锁验证：在方法中加
Thread.sleep(10000)，同时用show processlist查看数据库连接的事务状态。
总结
- Spring 事务传播机制定义了多方法调用时事务的传递规则，核心是 7 种传播行为，其中
REQUIRED（默认）和REQUIRES_NEW是日常开发的核心； REQUIRED适用于“同成功/同失败”的关联操作，REQUIRES_NEW适用于“独立执行、不受主事务影响”的操作；- 传播机制仅对 Spring 代理调用生效，内部调用会失效，需通过注入代理对象解决。