NESTED传播行为通过数据库Savepoint实现逻辑嵌套事务，内层异常仅回滚至保存点，外层提交则一并持久化；手动Savepoint可编程控制回滚粒度，需确保同一物理连接。
Java 中处理嵌套事务与保存点，核心在于理解 Spring 的传播行为（尤其是 NESTED）和 JDBC 底层的 Savepoint 机制。二者不是等价概念，但 NESTED 的实现依赖 Savepoint；而 Savepoint 是数据库原生能力，可编程调用，不依赖 Spring。
NESTED 传播行为：真正的嵌套事务
NESTED 不是开启新事务，而是在当前事务内设一个保存点（Savepoint），形成逻辑上的“子事务”。它的行为特点是：
- 内层方法抛异常时，仅回滚到该保存点，外层事务其余操作不受影响
- 外层事务提交时，连同所有未回滚的保存点一并持久化
- 外层事务回滚，则整个事务（含所有保存点）全部撤销
- 要求数据库支持 Savepoint（MySQL、PostgreSQL、Oracle 均支持；H2、Derby 也支持）
- 必须使用 JdbcTemplate 或声明式事务配合
@Transactional(propagation = Propagation.NESTED)
手动管理 Savepoint：脱离 Spring 的精细控制
当需要更灵活的回滚粒度（比如在同一个方法里多次分段控制），可直接通过 Connection 操作 Savepoint：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 调用
connection.setSavepoint("sp1")创建保存点 - 出错时调用
connection.rollback(savepoint)回滚至此 - 成功后可选调用
connection.releaseSavepoint(savepoint)清理资源 - 注意：需确保获取的是同一个物理连接（如用
DataSourceUtils.getConnection()而非直接 new） - 这种方式绕过 Spring 代理，适合复杂流程或工具类封装（如 TransactionUtils 支持嵌套部分回滚）
REQUIRES_NEW vs NESTED：别混用场景
两者都常被误称为“嵌套事务”，但机制和适用性完全不同：
立即学习“Java免费学习笔记（深入）”；
- REQUIRES_NEW：挂起外层事务，开启全新事务（新连接、新隔离、独立提交/回滚）。适合日志、通知、审计等弱一致性操作
- NESTED：共享同一连接和事务上下文，靠保存点实现局部回滚。适合“主流程中某步失败需补偿但不中断整体”的场景，如扣库存失败时只回滚这一步，不影响订单创建
- 关键区别：REQUIRES_NEW 有连接开销和锁竞争风险；NESTED 更轻量，但无法跨数据源，也不支持非 Savepoint 数据库（如 SQL Server 默认不启用，需确认配置）
常见踩坑与规避方式
实际开发中容易忽略的细节：
- NESTED 在 JDK 17+ + Spring 6.x 中默认可用，但若底层 DataSource 封装过深（如某些云数据库连接池），可能静默退化为 REQUIRED —— 建议单元测试验证回滚行为
- 同一个类内自调用（this.methodB()）会导致 @Transactional 失效，NESTED 同样不生效，必须走 Spring 代理（注入自身 Bean 或拆分到不同 Service）
- 若业务中混合用了 REQUIRES_NEW 和 NESTED，要注意外层事务挂起后，NESTED 保存点其实是在新事务里创建的——这种组合极少合理，通常说明设计需重构
- Savepoint 名称无需全局唯一，但同一事务内重复使用相同名称会覆盖前一个，建议用有意义前缀（如 "order_create_sp"）便于排查
