Java嵌套事务由Spring传播机制决定，非简单方法调用；PROPAGATION_REQUIRED是共享事务，PROPAGATION_NESTED依赖保存点实现内层独立回滚，PROPAGATION_REQUIRES_NEW则完全隔离；需规避自调用失效、循环调用全回滚等陷阱，并依场景选传播类型，配合TransactionSynchronizationManager确保提交后操作精准执行。
Java 中嵌套事务不是“方法里调方法”就自动嵌套，而是由 Spring 的事务传播机制（propagation）决定行为。设计不当会导致全部回滚、部分失效、数据不一致甚至死锁。关键不在“嵌套”本身，而在传播行为的选择和异常处理的配合。
明确事务传播行为的含义
Spring 默认是 PROPAGATION_REQUIRED，它不创建新事务，而是加入已有事务——这其实是“共享事务”，不是真正嵌套。真要实现“内层可独立提交/回滚”，必须满足两个前提：
- 底层数据库支持保存点（savepoint），如 MySQL（InnoDB）、PostgreSQL、Oracle；
- 使用
PROPAGATION_NESTED，它通过 savepoint 实现内层回滚而不影响外层； -
PROPAGATION_REQUIRES_NEW是另起炉灶：挂起外层事务，开启全新事务，彼此完全隔离； - 避免误用
PROPAGATION_SUPPORTS或NOT_SUPPORTED，它们会脱离事务上下文，导致意外提交。
避免常见设计陷阱
很多问题源于对调用方式和代理机制的误解：
- 同一类中自调用（
this.methodB()）不会触发事务代理，@Transactional失效；必须改为外部 Bean 调用或使用AopContext.currentProxy()（不推荐）； - 循环内多次调用带事务的方法（如 for 中反复调
saveOrder()），若都用REQUIRED，等于所有操作绑在同一个事务里，一处失败全盘回滚； - 用
NESTED时，若内层抛出未声明的运行时异常（如NullPointerException），默认回滚，但外层仍可继续；若想外层也回滚，需显式配置rollbackFor； - 不要在
NESTED方法里手动调用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()，易与 savepoint 冲突。
按场景选对传播类型
没有万能配置，要结合业务语义判断：
- 订单创建 + 库存扣减 + 日志记录 → 全部用
REQUIRED，强一致性，一荣俱荣、一损俱损； - 主流程成功后发通知、更新缓存、写审计日志 → 这些可容忍失败，用
REQUIRES_NEW，确保不影响主事务； - 批量导入中某条数据校验失败，只跳过该条，其余继续 → 外层
REQUIRED，每条处理用NESTED，并在 catch 中调status.setRollbackOnly()回滚当前 savepoint； - 支付回调中先查单再更新状态，中间可能调第三方 → 查询用
SUPPORTS（无事务也可跑），更新用REQUIRED，避免不必要的事务开销。
配合 registerSynchronization 做精准收尾
当需要在事务真正提交后执行动作（如发 MQ 消息、清理临时文件），别在方法末尾硬写逻辑，而应注册同步器：
- 用
TransactionSynchronizationManager.registerSynchronization()注册回调； - 在
afterCommit()中执行最终操作，此时数据库已持久化，且只在外层事务真正提交时触发一次； - 注意：
NESTED的afterCommit()在 savepoint 提交时就会触发，不代表外层已提交，所以关键操作应放在外层事务的回调里； - 为防重复注册（比如循环中多次调用），可用
ThreadLocal标记是否已注册。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
