unexpectedrollbackexception的根本原因是事务本该提交却意外回滚，即内层标记回滚但外层无事务或传播行为不支持提交；需检查传播行为一致性、避免手动setrollbackonly、确保异常类型触发回滚、防止自调用导致代理失效。
Java里出现UnexpectedRollbackException，根本原因不是事务“被回滚了”，而是事务“本该提交却意外回滚了”——Spring发现事务执行过程中发生了不可恢复的回滚标记（比如内部抛了RuntimeException或显式调用了setRollbackOnly()），但当前方法又没声明支持回滚（比如没加@Transactional(propagation = Propagation.REQUIRED)，或传播行为不匹配），导致外层事务无法继续正常提交，最终抛出这个异常。
检查事务传播行为是否嵌套冲突
最常见场景是：内层方法抛了运行时异常，触发了回滚；外层方法没加@Transactional，或用了PROPAGATION_SUPPORTS/PROPAGATION_NOT_SUPPORTED这类不支持事务提交的传播行为。Spring发现“我本来没打算管事务，结果你偷偷回滚了”，就报UnexpectedRollbackException。
- 确认所有参与事务的方法都明确标注
@Transactional，且传播行为一致（默认REQUIRED即可） - 避免在
SUPPORTS或NOT_SUPPORTED事务中调用可能抛异常的事务方法 - 如果确实需要只读支持，确保被调用方法不会改变状态、也不抛非受检异常
排查是否有隐藏的setRollbackOnly()或强制回滚
有些代码会手动控制事务状态，比如在Service里注入TransactionStatus并调用setRollbackOnly()，或者使用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。一旦这么做了，后续即使没抛异常，事务也会被标记为回滚，而外层若没适配，就会触发此异常。
- 全局搜索
setRollbackOnly、currentTransactionStatus等关键词 - 检查是否有自定义AOP、拦截器或模板类悄悄干预了事务状态
- 慎用手动回滚，优先用抛异常方式（如
throw new RuntimeException()）让Spring自动处理
留意异常类型是否被@Transactional忽略
@Transactional默认只对RuntimeException和Error回滚，对Checked Exception（如IOException）不回滚。但如果代码里捕获了运行时异常又吞掉，再抛出一个受检异常，Spring就不会触发回滚，但业务逻辑实际已失败——此时若外层依赖事务一致性，也可能间接引发异常链中的意外回滚信号。
- 确认抛出的异常属于Spring默认回滚的类型，或显式配置
rollbackFor = {YourException.class} - 不要在事务方法里“静默吞掉”异常后继续执行，尤其不能在catch块里return或继续写DB操作
- 日志里重点看
Caused by:部分，往上追溯真正触发回滚的原始异常
验证事务代理是否生效（特别是自调用问题）
同一个类内，非@Transactional方法直接调用本类另一个@Transactional方法，事务不会生效（代理失效）。此时看似进了事务方法，实际没开启事务上下文，异常发生后Spring无法协调回滚状态，容易误报UnexpectedRollbackException。
- 把跨方法的事务调用移到不同Bean中，或通过
ApplicationContext或self-injection获取代理对象调用 - 启用
@EnableAspectJAutoProxy(exposeProxy = true)，并在方法内用AopContext.currentProxy()调用 - 用DEBUG日志确认
TransactionInterceptor是否真的拦截到了目标方法
不复杂但容易忽略，核心就是盯住“谁启的事务、谁标了回滚、谁试图提交”这三步是否闭环。定位时打开org.springframework.transaction的DEBUG日志，比猜快得多。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
