事务传播行为决定事务方法间调用时的上下文接续方式：REQUIRED复用或新建事务；REQUIRES_NEW强制独立事务；NESTED基于保存点局部回滚；SUPPORTS等按需选型。
事务传播行为解决的是“一个事务方法调用另一个事务方法时，事务该怎么接续”的问题。它不决定事务要不要存在，而是决定新方法是加入当前事务、新建一个、还是干脆不用事务。理解的关键在于：传播行为只在方法间调用且双方都加了 @Transactional时才起作用；它描述的是事务上下文如何流转，不是孤立地看单个方法。
REQUIRED：默认值，同一事务链的基石
这是最常用、也最符合直觉的行为。如果当前已有事务（比如外层 Service 方法已开启），被调用的方法就直接加入这个事务；如果没有，它自己启动一个新事务。
- 适合绝大多数业务操作，如订单创建、库存扣减、积分发放等需强一致性的连贯步骤
- 整个调用链共用一个事务 ID，任意一处抛出未捕获异常，全部回滚
- 注意：即使被调用方法声明为 REQUIRED，它也不会“开启新事务”，只是复用或继承——所以不要指望靠它隔离失败影响
REQUIRES_NEW：强制独立，适合旁路操作
不管外层有没有事务，它都挂起当前事务（如有），并开启一个全新的、完全独立的事务。两个事务互不影响：外层回滚，它已提交；它自己失败，外层照常提交。
- 典型用于审计日志、异步消息发送、通知类操作——这些动作不该因主流程失败而丢失
- 慎用于数据库写操作密集场景，因为挂起/恢复事务有开销，还可能延长锁持有时间
- 不能在同一个类内通过 this.method() 调用生效（代理失效），必须走 Spring 代理对象调用
NESTED：带保存点的嵌套，支持局部回滚
它依赖数据库对“保存点（Savepoint）”的支持。如果有外层事务，就在其中设一个保存点，内层操作在这个保存点范围内执行；若内层异常，可仅回滚到该保存点，外层事务继续运行。
立即学习“Java免费学习笔记（深入）”；
- 适合批量处理中某条记录失败但不想中断整体流程的场景，例如导入 100 条用户数据，第 5 条格式错误，只跳过它
- MySQL 和 PostgreSQL 支持良好，但某些数据库或连接池配置下可能退化为 REQUIRED
- 与 REQUIRES_NEW 不同：它不挂起外层事务，也不新建物理事务，开销更小
SUPPORTS / NOT_SUPPORTED / MANDATORY / NEVER：按需选型
这四种偏场景化，使用频率较低，但能精准表达语义：
- SUPPORTS：读操作首选。有事务就参与，没事务也照常运行，不强求上下文
- NOT_SUPPORTED：明确拒绝事务，比如导出报表、复杂计算等耗时非关键操作，避免拖慢主事务
- MANDATORY：强制校验调用方是否已在事务中，适用于核心资金操作，防止被误用在非事务上下文
- NEVER：极少用。确保方法绝对不能出现在任何事务里，多见于测试或特殊工具类
