下面把 **传播行为** 拆成“**有父事务时怎么做**”和“**无父事务时怎么做**”两个维度，比原来的「是否必须有父事务 / 是否会新建事务」更直观——一眼就能看出它在两种场景下的动作差异。

| 传播行为                | **父事务已存在时**                                 | **父事务不存在时**                   | 典型用途 / 说明                            |
| ----------------------- | -------------------------------------------------- | ------------------------------------ | ------------------------------------------ |
| **`REQUIRED`** *(默认)* | **加入父事务**→ 共提交 / 回滚                      | **创建新事务**                       | 日常业务写操作，保持一致性                 |
| **`REQUIRES_NEW`**      | **挂起父事务**→ **自己新建事务**                   | 自己新建事务                         | 写日志、发送 MQ 等：外层失败也要单独成功   |
| **`SUPPORTS`**          | 加入父事务                                         | **非事务方式执行**                   | 只读查询：有事务跟随一致性，没有就轻量查询 |
| **`NOT_SUPPORTED`**     | **挂起父事务**→ 非事务方式执行                     | 非事务方式执行                       | 大批量/耗时操作，避免长事务锁表            |
| **`MANDATORY`**         | 加入父事务                                         | **立即抛异常**                       | 防御性编程：强制要求调用方已开启事务       |
| **`NEVER`**             | **立即抛异常**                                     | 非事务方式执行                       | 禁止在事务里跑的代码（如特殊 DDL）         |
| **`NESTED`**            | 同一物理事务，打 **SAVEPOINT**→ 子回滚只回到保存点 | 创建新事务（与 `REQUIRED` 效果相同） | 分段回滚；需 DB / JDBC 支持保存点          |

### 使用 Tips

- **不想被外层事务拖垮** ➜ `REQUIRES_NEW`
- **可有可无事务的读操作** ➜ `SUPPORTS`
- **耗时任务要彻底裸跑** ➜ `NOT_SUPPORTED`
- **局部失败但整体继续** ➜ `NESTED`（保存点）
- **强约束外层必须有事务** ➜ `MANDATORY`
- **坚决拒绝在事务里执行** ➜ `NEVER`

这样，你只需关心：

> *「现在有没有父事务？✚ → 该传播行为会怎么做？」*

就能快速判断是否满足你的业务需求。