业务异常误继承error会导致spring事务拒绝回滚——因error语义表jvm级故障，虽默认回滚但破坏分层、掩盖问题；应统一继承runtimeexception或显式配置rollbackfor。
业务异常被误继承为 Error 或其子类，会导致 Spring 事务**拒绝回滚**——这不是配置错误，而是类型语义冲突引发的隐性失效。Spring 的事务回滚判定逻辑非常明确：只对 RuntimeException 及其子类、Error 类型触发默认回滚；但关键在于：Error 在语义上代表“JVM 级严重故障”，Spring 虽会回滚，但绝大多数业务异常绝不能是 Error 的子类。一旦误设，不仅破坏分层设计，更可能掩盖真实问题，甚至干扰监控告警体系。
确认异常是否错误继承了 Error
检查自定义异常类的继承链，重点识别是否直接或间接继承自 Error（而非 Exception）。例如：
- ❌ 错误写法：
public class BusinessException extends Error - ❌ 隐式错误：
public class ValidationFailedError extends RuntimeException—— 类名含 “Error” 易误导，但实际可回滚；真正危险的是继承Error - ✅ 正确写法：
public class BusinessException extends RuntimeException或public class BusinessException extends Exception（后者需配合rollbackFor）
验证事务行为是否受异常类型影响
运行时观察事务决策日志，确认 Spring 是否因类型判断跳过回滚：
- 启用调试日志：
logging.level.org.springframework.transaction=DEBUG - 触发异常后，搜索日志中类似
Completing transaction for [xxx] after exception和Does not roll back transaction because it is not a runtime exception的提示 - 若日志显示
ex instanceof Error为true，但业务逻辑本不该走此路径，则说明异常类型设计失当
检查事务代理能否捕获该异常
即使异常是 Error 子类，Spring 理论上仍会回滚，但实践中存在风险：
- JVM 对
Error的处理策略可能导致线程提前终止，使 AOP 代理无法完成回滚流程 - 某些容器或监控 SDK 会主动拦截
Error并吞掉，导致事务切面根本收不到异常信号 - 若该异常出现在异步线程、定时任务或 Filter 中，事务上下文已丢失，回滚必然失效
修正异常设计并回归验证
重构异常体系，确保业务异常严格属于应用层语义：
- 所有业务异常统一继承
RuntimeException（推荐），如InsufficientBalanceException、OrderAlreadyPaidException - 若必须使用受检异常，务必在
@Transactional中显式声明：@Transactional(rollbackFor = BusinessException.class) - 编写单元测试，模拟抛出该异常，断言数据库状态是否还原（如查主键是否存在、字段值是否未变更）
- 避免在异常类名中混用
Error/Exception术语，保持命名与继承一致
