Spring事务回滚不依赖NestedException本身，而是依据异常类型（如RuntimeException）和配置规则，NestedException仅用于封装异常链以保留原始错误信息供追溯与诊断。
Spring 中事务回滚不依赖 NestedException 本身，而是依靠异常的“嵌套结构”（即 getCause() 链）和 Spring 的 异常回滚规则 协同工作。真正起作用的是 RuntimeException 及其子类默认触发回滚、检查型异常默认不回滚的机制，而 NestedException（如 NestedRuntimeException、NestedCheckedException）只是 Spring 提供的一组**支持异常链封装与追溯**的基类，让底层数据访问异常（如 JDBC SQLException）能被包装后保留原始原因，供事务管理器判断和日志追踪。
为什么需要 NestedException？——解决异常信息丢失问题
数据库操作出错时，JDBC 层抛出 SQLException，但 DAO 层常会将其包装为自定义业务异常（如 UserOperationException）。若直接 throw 新异常且未设置 cause，原始 SQL 错误码、SQL 状态码、具体失败语句等关键诊断信息就丢失了。Spring 的 NestedRuntimeException 允许你在构造时传入原始异常：
throw new DataAccessException("Failed to update user balance", sqlEx);
这样异常栈里既保留业务语义，又可通过 getRootCause() 或 getCause() 逐层拿到最底层的 SQLException，事务管理器和日志系统都能据此做决策。
事务回滚如何利用嵌套异常链？
Spring 的 TransactionInterceptor 在捕获到方法抛出的异常后，会调用 rollbackOn(Throwable ex) 判断是否回滚。这个判断逻辑默认只看异常类型（是否是 RuntimeException 或 Error），不直接解析嵌套原因。但你可以通过以下方式让嵌套异常影响回滚行为：
-
自定义回滚规则：在
@Transactional(rollbackFor = ...)中指定你包装后的异常类（如MyBusinessException.class），即使它是 checked 异常； -
重写
rollbackOn：继承RuleBasedTransactionAttribute或实现TransactionAttribute，在判断逻辑中调用ex instanceof NestedException ? ((NestedException) ex).getRootCause() : ex，再根据 root cause 类型决定是否回滚（例如：只要 root cause 是SQLException就回滚）； -
统一异常处理器 + 手动回滚：用
@ExceptionHandler捕获异常，检查getRootCause()是否属于应触发回滚的数据库异常类型，然后调用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。
实际开发中的推荐做法
不建议为了回滚去深度定制嵌套异常判断逻辑。更简洁可靠的方式是：
- DAO 层使用 Spring JDBC 或 JPA 时，让底层模板类（如
JdbcTemplate、JpaTransactionManager）自动将SQLException转换为 Spring 的DataAccessException子类（它们都继承自NestedRuntimeException）； - Service 层直接抛出这些运行时异常，或包装为新的
NestedRuntimeException子类（保持 cause 链完整）； - 事务方法上标注
@Transactional，默认即可对所有RuntimeException回滚； - 如需对特定 checked 异常回滚，显式写
@Transactional(rollbackFor = MyCheckedException.class)，无需关心它是否嵌套。
小结：NestedException 的真实价值
它不是回滚的“开关”，而是异常的“信封”——确保错误上下文不被丢弃。Spring 事务回滚的核心依据是异常类型与配置规则，嵌套机制只是让这个判断过程有据可查、便于调试。真正要关注的是：异常是否被正确分类（runtime vs checked）、cause 链是否完整、回滚规则是否匹配业务语义。
