Spring @Transactional传播默认值为何是REQUIRED而非NESTED

以下是问题对应的典型复现代码：

@Service
class A {
    @Autowired
    private B b;

    @Transactional
    public void a() {
        // ...
        try {
            b.b();
        } catch (Exception e) {
            // 捕获异常不向外抛出
        }
        // ...
    }
}

@Service
class B {
    @Transactional
    public void b() {
        // 执行业务数据库操作
    }
}

不少开发者测试上述代码时会发现：即使手动catch了b()抛出的异常，外层a()的事务依然会触发回滚；如果给b()设置NESTED传播级别就不会出现这个问题，加上官方文档描述NESTED「存在事务则在嵌套事务执行，否则行为和REQUIRED一致」，很容易觉得两者差异很小，疑惑为什么不把NESTED设为默认。
核心原因可以从三个维度解释：

• 语义匹配通用业务诉求
  REQUIRED的核心语义是「操作必须运行在事务上下文中：存在外层事务就直接加入，不存在就新建独立事务」，覆盖了80%以上的常规业务场景：同一个业务链路的多个数据库操作默认属于同一个原子工作单元，要么全部成功要么全部回滚，不存在中间状态。提问中补充提到的「如果a()抛出异常，两个方法的数据库操作全部回滚」，本身就是REQUIRED的默认行为，也是绝大多数业务的基础一致性要求。
• NESTED存在底层依赖和一致性风险
  NESTED的实现完全依赖数据库的保存点（Savepoint）机制，不是所有数据库引擎、JDBC驱动、事务管理器都能完美支持该特性，比如MyISAM等不支持事务的引擎、部分分布式事务场景下保存点行为会出现不一致，默认选用有底层兼容限制的特性不符合Spring的通用设计原则。
  同时NESTED的「子事务独立回滚到保存点、不影响外层事务继续执行」的语义，很容易被不熟悉机制的开发滥用：比如子方法执行扣减库存逻辑抛错回滚到保存点，外层catch异常后继续执行生成订单逻辑，就会出现未扣库存却生成订单的脏数据，这种一致性风险对于框架默认配置来说是不可接受的。
• 示例中的回滚现象是REQUIRED的刻意设计，不是缺陷
  REQUIRED级别下b()和a()属于同一个物理事务，b()抛出异常时，Spring的事务拦截器会直接将整个事务标记为rollback-only，即使外层catch了异常，最终事务提交时Spring检测到回滚标记，依然会抛出UnexpectedRollbackException触发全事务回滚。这个设计是为了强一致性兜底：同一个事务里只要有一个操作抛出异常，就意味着事务上下文已经可能出现不一致状态，不允许开发人员吞掉异常假装无事发生继续提交。

针对示例中的场景，如果确实需要「子方法执行失败不中断外层主流程，但是外层主流程失败时所有操作全部回滚」，手动给b()指定NESTED传播级别并不是冗余代码，反而是明确的语义声明：告诉后续维护代码的开发人员，这个子操作有独立的回滚边界，和外层事务不是强原子绑定关系，能有效提升代码可读性。
最后澄清一个常见认知偏差：NESTED和REQUIRED的语义差异非常大，不存在「表现十分相似」的情况：

• REQUIRED下加入外层事务的子方法没有独立回滚边界，子方法异常会直接标记整个事务回滚，是强同生共死的原子性。
• NESTED下子方法会在执行前创建保存点，子方法异常仅回滚到保存点位置，不会标记整个事务回滚；外层事务提交时子操作才会真正持久化，外层回滚时子操作也会级联回滚。

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