SpringBoot异常处理器失效怎么解决

本文深入解析了 Spring Boot 中全局异常处理器（特别是 `@RestControllerAdvice`）失效的典型场景——当多个异常处理器同时存在时，因执行优先级混乱导致 `MethodArgumentNotValidException` 等关键校验异常被错误拦截，返回不符合预期的 RFC 7807 格式响应；文章直击根源，强调通过显式添加 `@Order(Ordered.HIGHEST_PRECEDENCE)` 确保验证处理器优先执行，并辅以包扫描确认、避免重复捕获、标准化响应结构和实测验证等实用技巧，帮助开发者彻底解决异常处理“失灵”问题，真正实现统一、精准、可复用的全局异常治理。

当将 @ExceptionHandler 从控制器内移至 @RestControllerAdvice 类后响应格式异常，通常因多个全局异常处理器冲突导致优先级不足，需显式设置 @Order 保证执行顺序。

当将 `@ExceptionHandler` 从控制器内移至 `@RestControllerAdvice` 类后响应格式异常，通常因多个全局异常处理器冲突导致优先级不足，需显式设置 `@Order` 保证执行顺序。

在 Spring Boot 3 中，@RestControllerAdvice 是实现全局异常统一处理的标准方式。但若项目中存在多个 @RestControllerAdvice 类（如你结构中的 RestExceptionHandler、ValidationExceptionHandler 等），Spring 会按注册顺序或默认优先级调用它们——而 Spring Boot 内置的 DefaultErrorAttributes 或其他自定义异常处理器（例如处理 RuntimeException 的通用兜底类）可能抢先捕获了 MethodArgumentNotValidException，导致你的验证处理器未被触发，最终返回默认的 RFC 7807 格式错误响应（即含 type/title/detail 的 JSON）。

根本原因在于：MethodArgumentNotValidException 是一种预绑定校验异常，它由 Spring MVC 的 RequestResponseBodyMethodProcessor 在参数解析阶段抛出，且可被多个 @ExceptionHandler 方法匹配。若多个 @RestControllerAdvice 类均声明了对该异常的处理逻辑，Spring 会依据其Bean 的排序（Order） 决定执行优先级；未显式指定时，默认顺序不确定，高优先级的处理器（如更宽泛的 Exception 捕获器）可能“吞掉”该异常。

✅ 正确做法是为 ValidationExceptionHandler 显式声明最高优先级：

package com.example.my_app.exception;

import org.springframework.core.Ordered;
import org.springframework.core.annotation.Order;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.MethodArgumentNotValidException;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.RestControllerAdvice;

import java.util.HashMap;
import java.util.Map;

@Order(Ordered.HIGHEST_PRECEDENCE) // ← 关键：确保最先执行
@RestControllerAdvice
public class ValidationExceptionHandler {

    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity