UnexpectedRollbackException源于事务已被标记为rollback-only但仍尝试提交；根本原因是内层异常导致Spring标记回滚状态，外层catch后继续执行至commit阶段，触发状态校验失败。
UnexpectedRollbackException 不是“隐式回滚非受检异常”的结果，而是事务已被标记为仅回滚（rollback-only）但后续仍尝试提交所抛出的明确异常。它本身不表示回滚发生，而是揭示回滚状态与提交意图之间的冲突。
为什么会抛 UnexpectedRollbackException？
核心原因只有一个：当前事务已处于 rollback-only 状态，但代码仍走到 commit 流程。
- 内层方法抛出未捕获的 RuntimeException → Spring 代理将其标记为 rollback-only
- 外层方法用 try-catch 捕获了该异常，未重新抛出 → 表面“处理成功”，流程继续执行
- 外层事务结束时调用 commit() → 发现状态是 rollback-only → 抛 UnexpectedRollbackException
常见触发场景
最典型的是 REQUIRED 传播下的嵌套调用 + 异常吞没：
- @Transactional 方法 A 调用另一个 @Transactional 方法 B（同一类中 this.b() 属于无效调用，需跨 Bean）
- B 抛出 IllegalArgumentException（非受检异常），事务被标记 rollback-only
- A 中 catch 住 B 的异常，打印日志后继续执行后续逻辑
- A 方法末尾无异常，Spring 尝试提交 → 实际不可提交 → UnexpectedRollbackException
不是回滚失败，而是提交非法
这个异常不说明数据库回滚出错，而是 Spring 在 commit 前做了一次状态校验：发现事务早已被标记为“只许回滚”，就不允许再提交。它是一种保护机制，防止业务误以为操作成功。
立即学习“Java免费学习笔记（深入）”；
- rollback-only 状态一旦设置，无法清除（不能靠 catch 恢复）
- 即使你 catch 后什么也不做，事务上下文仍维持该状态
- 最终 commit 失败是必然结果，UnexpectedRollbackException 是必然提示
怎么避免？
关键不是拦截异常，而是管理事务边界：
- 需要隔离内层失败影响 → 改用 Propagation.REQUIRES_NEW，让 B 拥有独立事务
- 需要局部回滚（如批量处理单条失败）→ 外层 REQUIRED + 内层 NESTED + 手动 savepoint 回滚
- 必须吞异常 → 不要让事务覆盖整个方法，把可能出错的部分拆到无事务方法中
