Spring事务中为何优先使用Propagation.REQUIRED而非Propagation.NESTED

优先选择Propagation.REQUIRED而非NESTED的典型场景 #

我们可以先明确两者的核心差异：REQUIRED会让所有被调用的事务方法共享同一个外层事务，所有操作同生共死；NESTED则会为子事务创建独立保存点，子事务回滚仅撤销自身修改，不影响父事务，但父事务回滚时子事务也会一起回滚。以下场景更适合用REQUIRED：

1. 强原子性要求的关联业务操作 #

绝大多数业务流程的多个数据库操作天然要求完全绑定，不允许出现部分成功的中间状态。比如经典的订单创建流程：扣减商品库存→生成订单记录→扣减用户余额，三个操作必须全部成功或全部失败。
如果用NESTED实现，一旦扣减余额失败仅回滚余额相关操作，就会出现库存被扣、订单已生成但用户未支付的不一致问题，完全违背业务逻辑。而REQUIRED天然保证所有加入事务的操作只要任意一个触发回滚，整个流程的所有修改都会被撤销，不需要额外开发一致性校验逻辑，适配这类场景的成本极低。

2. 追求更高的事务性能与兼容性 #

NESTED的实现完全依赖数据库的保存点（Savepoint） 机制：每次进入NESTED级别的子事务都要创建保存点，子事务结束要释放保存点，嵌套层级越多、并发越高，额外的性能开销就越明显。
此外不是所有数据库和事务管理器都支持保存点：比如部分老旧关系型数据库、JTA分布式事务场景下，NESTED传播级别直接不可用。REQUIRED是所有兼容事务的数据库都支持的基础特性，不需要额外开销，性能和兼容性远优于NESTED。

3. 公共通用方法的事务适配 #

对于DAO层、通用基础服务层的公共方法（比如通用的插入、更新、查询加锁操作），本身不需要独立的事务逻辑，事务的边界应该由上层业务决定。
用REQUIRED作为这些公共方法的传播级别，上层业务开启事务后，所有调用的公共方法会自动加入当前事务，由上层统一管控事务的提交/回滚逻辑，不需要每个调用方都额外适配子事务的回滚处理，大幅降低团队协作的维护成本。

4. 跨资源的分布式事务场景 #

当业务使用JTA等分布式事务方案，需要同时操作多个数据源、消息队列等事务资源时，NESTED传播级别完全不支持这类场景，只能用REQUIRED将子操作加入全局分布式事务，保证跨资源的操作一致性。

补充说明：你提到的REQUIRED会阻断异常恢复的问题，本质是传播级别和业务场景不匹配导致的。如果你确实需要子方法失败可降级，除了NESTED之外，REQUIRES_NEW也是可选方案，具体选哪个取决于你是否需要子事务跟随父事务一起回滚。

内容的提问来源于stack exchange，提问作者Tiddo