如何应用自定义异常传播阻断器在嵌套事务中控制非受检回滚边界

哈喽！今天心血来潮给大家带来了《如何应用自定义异常传播阻断器在嵌套事务中控制非受检回滚边界》，想必大家应该对文章都不陌生吧，那么阅读本文就都不会很困难，以下内容主要涉及到，若是你正在学习文章，千万别错过这篇文章~希望能帮助到你！

Spring声明式事务无内置“自定义异常传播阻断器”，但可通过Propagation.REQUIRES_NEW或NESTED配合Savepoint，精准控制非受检异常的回滚范围，避免污染外层事务状态。

Spring 声明式事务本身不提供“自定义异常传播阻断器”这一内置组件，但你可以通过组合 传播行为（Propagation）、异常分类策略 和 显式事务控制，实现等效效果：即在嵌套调用中精准划定非受检异常（RuntimeException）的回滚影响范围，防止其向上污染外层事务状态。

明确非受检异常的默认回滚边界

Spring 默认仅对 RuntimeException 及其子类、Error 触发自动回滚。这意味着：

• 抛出 IllegalArgumentException、NullPointerException 等，会触发回滚
• 抛出 IOException、SQLException（未声明为 rollbackFor）则不会回滚
• 关键点：回滚动作本身不“阻断”异常传播；真正决定是否影响外层事务的是 传播行为 + 异常是否逃逸出当前事务作用域

用 REQUIRES_NEW 隔离非受检异常影响

这是最直接、最可靠的方式——让内层逻辑拥有独立事务，天然切断与外层的 rollback-only 状态传递。

• 内层方法标注 @Transactional(propagation = Propagation.REQUIRES_NEW, rollbackFor = RuntimeException.class)
• 即使它抛出 ServiceException（继承自 RuntimeException），也只回滚自身事务，外层完全无感知
• 外层无需 try-catch，也不用担心 UnexpectedRollbackException
• 注意：必须跨 Bean 调用（不能 this.innerMethod()），否则代理失效，退化为普通方法调用

用 NESTED + 显式 Savepoint 控制局部回滚

适用于需共享数据库连接、且数据库支持 savepoint 的场景（如 MySQL InnoDB、PostgreSQL）。

• 外层用 REQUIRED，内层用 NESTED
• 在内层捕获非受检异常后，不重新抛出，而是调用 TransactionStatus.setRollbackOnly() 或手动回滚到保存点
• 这样外层事务仍可正常提交，仅内层修改被撤销
• 示例：批量导入时单条记录校验失败，跳过该条，其余继续处理并提交

避免“假阻断”：不要依赖 try-catch 清除 rollback-only 状态

这是高频误区。在 REQUIRED 嵌套下：

• 内层抛 CustomBizException extends RuntimeException
• 外层用 try-catch 捕获并吞掉 —— 无效
• 事务对象已被标记为 rollback-only，外层结束时仍会抛 UnexpectedRollbackException
• 真正解法不是“拦住异常”，而是“换事务边界”：改用 REQUIRES_NEW 或 NESTED

不复杂但容易忽略：所谓“阻断”，本质是事务边界的切换，而非异常流的拦截。选对传播行为，比设计复杂异常处理器更有效。

今天关于《如何应用自定义异常传播阻断器在嵌套事务中控制非受检回滚边界》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！