Spring Boot 的 @ExceptionHandler 会按异常类型继承链从具体到宽泛逐级匹配，优先调用最精确（即最接近异常实际类型的）处理器，因此 @ExceptionHandler(DataIntegrityViolationException.class) 总是先于 @ExceptionHandler(Exception.class) 执行。
spring boot 的 `@exceptionhandler` 会按异常类型继承链从具体到宽泛逐级匹配，优先调用最精确（即最接近异常实际类型的）处理器，因此 `@exceptionhandler(dataintegrityviolationexception.class)` 总是先于 `@exceptionhandler(exception.class)` 执行。
在 Spring MVC 的异常处理机制中，@ControllerAdvice 类中的 @ExceptionHandler 方法并非按声明顺序执行，而是依据异常类型匹配的特异性（specificity） 进行智能调度。Spring 会将抛出的异常类型（如 DataIntegrityViolationException）与其所有父类（按 getClass().getSuperclass() 及接口递归向上）构成一个“候选类型链”，然后按该链从最具体到最宽泛的顺序扫描所有 @ExceptionHandler 方法的参数类型，首个匹配成功者即被调用。
以 DataIntegrityViolationException 为例，其继承链（精简后）如下：
DataIntegrityViolationException
└── NonTransientDataAccessException
└── DataAccessException
└── NestedRuntimeException
└── RuntimeException
└── Exception当该异常发生时，Spring 依次尝试匹配：
- @ExceptionHandler(DataIntegrityViolationException.class) → ✅ 匹配成功，立即执行；
- 后续的 NonTransientDataAccessException、DataAccessException 等均不再检查；
- @ExceptionHandler(Exception.class) 仅作为兜底，在无更具体处理器时才触发。
✅ 正确示例：清晰分层的异常处理
@ControllerAdvice
public class RestExceptionHandler extends ResponseEntityExceptionHandler {
// 最具体：捕获数据库约束冲突（如外键删除失败）
@ExceptionHandler(DataIntegrityViolationException.class)
public ResponseEntity<ApiExceptionDTO> handleDataIntegrityViolation(
DataIntegrityViolationException ex) {
String message = "请求的操作违反数据完整性约束，请检查关联资源是否仍被引用。";
return ResponseEntity.badRequest()
.body(new ApiExceptionDTO("INTEGRITY_VIOLATION", message));
}
// 次具体：通用数据访问异常（如连接超时、SQL语法错误）
@ExceptionHandler(DataAccessException.class)
public ResponseEntity<ApiExceptionDTO> handleDataAccess(
DataAccessException ex) {
return ResponseEntity.status(500)
.body(new ApiExceptionDTO("DATA_ACCESS_ERROR", "系统数据访问异常"));
}
// 兜底：捕获所有未明确处理的运行时异常（慎用！）
@ExceptionHandler(RuntimeException.class)
public ResponseEntity<ApiExceptionDTO> handleGenericRuntime(
RuntimeException ex) {
log.error("Uncaught runtime exception", ex);
return ResponseEntity.status(500)
.body(new ApiExceptionDTO("INTERNAL_ERROR", "服务内部错误"));
}
// ❌ 错误示范：避免使用 Exception.class 作为首选兜底
// @ExceptionHandler(Exception.class) // 不推荐放在具体处理器之前或并列声明
}⚠️ 关键注意事项：
- 不要依赖声明顺序：@ExceptionHandler 的执行完全由异常类型继承关系决定，与方法在类中的书写顺序无关；
- 避免过度使用 Exception.class：它应仅作为最终兜底，且建议置于所有具体处理器之后；若提前声明，虽不破坏匹配逻辑（因特异性优先），但易掩盖调试线索；
- 自定义异常优先于框架异常：若抛出自定义异常 UserNotFoundException，应为其单独声明 @ExceptionHandler(UserNotFoundException.class)，而非依赖 Exception.class；
- ResponseEntityExceptionHandler 的作用：它已预置了对 HttpRequestMethodNotSupportedException、HttpMessageNotReadableException 等 HTTP 相关异常的标准响应，可选择性重写，无需重复处理；
- 日志记录建议：在兜底处理器中务必记录完整异常堆栈（如 log.error("Unexpected error", ex)），便于问题追踪，而具体业务异常可只记录关键上下文。
总结而言，Spring 的异常处理器匹配本质是一场「类型精准度竞赛」——越贴近原始异常类的处理器胜出。合理利用这一机制，构建层次分明、职责清晰的全局异常处理体系，既能保障用户获得友好提示，又能为开发者提供精准的故障定位依据。
