spring事务传播机制共7种：required（默认，同生共死）、requires_new（独立事务，挂起外层）、nested（嵌套子事务，支持部分回滚）、supports（有则加入，无则不启）、mandatory（必须在事务中调用）、not_supported（挂起当前事务）、never（禁止在事务中执行）。
Spring 事务传播机制一共有 7 种，它们定义了当一个带事务的方法调用另一个带事务的方法时，后者如何参与或管理事务边界。选择哪一种，关键看业务逻辑对事务一致性、隔离性、失败影响范围的要求。
REQUIRED：绝大多数场景的默认选择
如果当前存在事务，就加入；没有就新建一个。这是 @Transactional 的默认行为。
- 适用于下单、支付、库存扣减等必须“同生共死”的操作链
- 两个方法共享同一个事务上下文：任一出错，全部回滚
- 无需显式写
propagation = Propagation.REQUIRED，省略即可
REQUIRES_NEW：需要完全独立事务的场景
不管外层有没有事务，都强制开启一个新事务，并把当前事务挂起（暂停）。
- 适合日志记录、审计、通知发送等“事后动作”——即使主流程失败，这些操作也要执行成功
- 内层事务失败不影响外层事务提交；外层回滚也不触发内层回滚
- 注意：挂起事务有开销，频繁使用可能影响性能
NESTED：支持部分回滚的嵌套事务
如果外层已有事务，则开启一个嵌套子事务（基于 Savepoint 实现）；没有外层事务时，等同于 REQUIRED。
- 典型用于批量处理中“单条失败不中断整体”的需求，比如导入 100 条数据，第 50 条失败只回滚它自己
- 依赖数据库对 Savepoint 的支持（如 MySQL InnoDB 支持，但需确认 JDBC 驱动配置）
- 不能跨数据源生效，且外层事务回滚会连带回滚所有嵌套事务
SUPPORTS / MANDATORY / NOT_SUPPORTED / NEVER：按读写性质和约束强度细分
这四种更多用于明确控制事务上下文的存在与否，常见于辅助类或基础设施层：
- SUPPORTS：纯查询方法首选。有事务就跟着走，没事务也无妨，避免无谓开销
- MANDATORY：强调“只能被事务方法调用”，比如订单状态更新工具方法，单独调用应直接报错
- NOT_SUPPORTED：明确要脱离事务，比如发邮件、调用第三方 HTTP 接口等耗时且非数据库操作
- NEVER：严格禁止在事务中执行，常用于测试或校验场景，一旦检测到事务上下文立即抛异常
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
