spring事务传播机制定义了方法调用时事务的处理方式，共7种行为。1.propagation_required默认行为，有事务则加入，无则新建；适用于多数需原子性的操作。2.propagation_requires_new强制新建事务，挂起当前事务；用于独立事务控制如日志记录。3.propagation_supports支持当前事务或非事务执行；适合查询操作。4.propagation_not_supported以非事务执行并挂起当前事务；用于不依赖事务的操作。5.propagation_never拒绝事务，否则抛异常；用于明确不能运行在事务中的操作。6.propagation_mandatory必须存在事务，否则报错；用于强制要求事务上下文的操作。7.propagation_nested嵌套子事务，可独立提交或回滚；用于局部回滚场景，依赖数据库支持。
Spring事务传播机制是我们在使用声明式事务时绕不开的一个核心概念。很多人在开发过程中遇到事务失效的问题，往往是因为没有正确理解事务传播行为的含义和适用场景。
什么是事务传播机制？
简单来说，事务传播机制决定了当一个方法被另一个方法调用时，事务应该如何处理。比如：当前有事务，就继续用；没有事务，就新建一个；或者不管怎样都运行在非事务环境下等等。
Spring一共定义了7种事务传播行为，适用于不同的业务场景。
PROPAGATION_REQUIred：最常用的默认行为
这是 Spring 的默认事务传播行为，意思是：
如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。
这个行为非常实用，也是大多数业务逻辑中首选的方式。例如，你在 service 层的方法 A 上加了 @Transactional，它调用了另一个也加了 @Transactional 的方法 B，默认情况下它们会运行在同一个事务中。
@Transactional public void methodA() { // do something methodB(); } @Transactional public void methodB() { // 同一个事务上下文 }
适用场景：
- 多个操作需要保证原子性，要么全成功，要么全失败。
- 不关心调用链中是否已有事务。
PROPAGATION_REQUIRES_NEW：强制开启新事务
顾名思义，这个行为会 挂起当前事务（如果有），并开启一个新的事务。也就是说，无论调用方有没有事务，当前方法都会运行在一个全新的事务中。
@Transactional(propagation = Propagation.REQUIRES_NEW) public void methodC() { // 总是在新事务中执行 }
适用场景：
- 需要独立事务控制，比如日志记录、审计等不想受外层事务回滚影响的操作。
- 希望某些关键操作即使其他部分失败也不受影响。
注意点：
- 因为每次都要新开事务，性能上会有一定开销。
- 要确保方法是 public，并且走代理，否则事务不会生效。
PROPAGATION_SUPPORTS：支持当前事务，无则不启用
这种行为比较“随缘”：
- 如果当前有事务，就在事务中执行；
- 如果没有事务，就以非事务方式执行。
常用于查询类操作，因为查询通常不需要事务，但如果在事务中调用也没问题。
@Transactional(propagation = Propagation.SUPPORTS) public User getUserById(Long id) { return userRepository.findById(id); }
适用场景：
- 查询操作或只读操作，希望不影响整体事务流程。
- 方法可能被事务方法调用，也可能被非事务方法调用。
PROPAGATION_NOT_SUPPORTED：不支持事务，挂起已有事务
与 SUPPORTS 相反，它总是以非事务方式执行，如果当前有事务，就先挂起。
@Transactional(propagation = Propagation.NOT_SUPPORTED) public void logSomething() { // 即使被事务方法调用，也不会参与事务 }
适用场景：
- 日志、统计等对事务无依赖的操作，避免事务带来的资源占用。
- 某些外部系统调用，不想受事务管理器控制。
PROPAGATION_NEVER：坚决不接受事务
这个行为表示：当前方法不能在事务中执行，否则抛异常。
@Transactional(propagation = Propagation.NEVER) public void nonTransactionalMethod() { // 只能在非事务环境下运行 }
适用场景：
- 明确要求某些操作不能运行在事务中，比如异步通知、回调等。
- 开发调试阶段用来检测是否有意外的事务传播进来。
PROPAGATION_MANDATORY：必须存在事务，否则报错
这个行为刚好相反：当前必须有事务，否则抛出异常。
@Transactional(propagation = Propagation.MANDATORY) public void mustInTransaction() { // 必须由事务方法调用 }
适用场景：
- 强制某些操作只能在事务上下文中执行，比如数据变更前的校验。
- 确保调用链中事务的完整性。
PROPAGATION_NESTED：嵌套事务
这是一个稍微复杂的行为：在当前事务中嵌套一个子事务。这个子事务可以独立提交或回滚，但主事务回滚会影响子事务。
@Transactional(propagation = Propagation.NESTED) public void nestedOperation() { // 嵌套事务内可单独回滚 }
适用场景：
- 某些操作可以局部回滚而不影响整个事务。
- 数据库支持保存点（Savepoint）的情况下使用。
注意：
- 是否真正支持嵌套事务取决于底层数据库和驱动是否支持 Savepoint。
- 在 mysql 中默认是不支持的，除非你手动配置。
基本上就这些，Spring 提供的七种事务传播行为各有用途，选择合适的行为能有效避免事务失效问题。在实际开发中，推荐根据业务需求合理使用，而不是一味追求“全部加 @Transactional”。
掌握这几种传播行为后，在设计服务层接口时就能更清晰地控制事务边界，提升系统的稳定性和一致性。
