java事务嵌套依赖spring的传播行为：required复用事务，requires_new挂起并新建独立事务，nested基于保存点实现局部回滚；须通过代理调用、避免this调用，并注意数据库与orm兼容性。
Java 中事务的嵌套调用不能靠简单的方法调用实现，核心在于 Spring 的 @Transactional 传播行为控制，而非“手动开启子事务”。默认情况下，同一事务上下文中多次调用带 @Transactional 的方法，不会创建新事务，而是复用外层事务——即“伪嵌套”，所有操作仍在同一个数据库事务中。
理解事务传播行为（Propagation）
Spring 通过 propagation 属性决定被调用方法如何参与事务。最常用且易误解的是：
- PROPAGATION_REQUIRED（默认）：如果当前存在事务，则加入该事务；否则新建一个。这是最常见的选择，但不是嵌套事务，只是复用或新建，不支持独立回滚。
- PROPAGATION_REQUIRES_NEW：无论当前是否存在事务，都挂起当前事务，新建一个独立事务。内部方法回滚不影响外层，外层回滚也不影响已提交的内层（但注意：若外层回滚后抛出异常导致内层事务管理器未正常关闭，可能引发不确定性）。
- PROPAGATION_NESTED：仅在 JDBC DataSourceTransactionManager + 支持保存点（savepoint）的数据库（如 MySQL、PostgreSQL）下有效。它在当前事务内建立保存点，内层“回滚”仅回退到该保存点，外层仍可继续执行或整体回滚。不是真正的新事务，但提供类似嵌套的局部回滚能力。
正确使用 REQUIRES_NEW 实现“独立操作”
当需要某个数据操作失败时不拖垮整个流程（例如：主业务必须成功，日志记录或通知类操作失败可容忍），适合用 REQUIRES_NEW：
- 确保被调用方法是 public，且由 Spring 容器代理调用（不能 this.xxx() 直接调用，否则 AOP 失效）。
- 被调用方法所在类需被 Spring 管理（加
@Service等），方法上标注：
@Transactional(propagation = Propagation.REQUIRES_NEW) - 注意异常处理：内层事务抛出的异常默认会传播出去，外层如不捕获，会导致外层也回滚。若希望内层失败不中断外层，需在调用处 显式 try-catch 内层方法抛出的异常。
用 NESTED 实现真正的事务内局部回滚
适用于需要强一致性又允许部分修正的场景，比如批量处理中某条失败只回滚该条：
- 配置事务管理器支持保存点（Spring Boot 默认的
DataSourceTransactionManager即可）。 - 外层方法用默认
REQUIRED，内层方法标注：
@Transactional(propagation = Propagation.NESTED) - 在内层方法中抛出异常，将触发回滚到其对应的保存点，外层事务不受影响，可继续执行后续逻辑或做补偿。
- 注意：JPA/Hibernate 对
NESTED支持有限（尤其在使用 JTA 时），建议优先验证实际效果。
不推荐的做法和常见陷阱
- 手动 new TransactionTemplate().execute(...)：虽可行，但绕过声明式事务统一管理，增加维护成本，易出错。
-
在同一个类中直接 this.methodB()：AOP 代理失效，
@Transactional完全不生效。 -
混淆“嵌套事务”与“多数据源事务”：跨库操作需用 JTA 或 Seata 等分布式事务方案，
NESTED或REQUIRES_NEW均无法解决跨数据源一致性问题。 -
忽略只读事务与传播行为组合：例如
REQUIRES_NEW + readOnly=true在某些数据库连接池下可能报错，需实测兼容性。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
