Spring Boot全局异常处理分三层：第一层默认兜底返回/error；第二层自定义error页面；第三层@ControllerAdvice+@ExceptionHandler统一处理API异常，需注意作用范围、捕获顺序、目标异常及返回设计，并配套Result封装、日志记录与避坑要点。
画 Spring Boot 全局异常处理的思维导图，关键不是堆砌所有类名和注解，而是理清“谁在什么时候、以什么方式、处理哪类异常”。下面按实际开发逻辑分层展开，方便你直接转化成清晰的导图结构。
核心分层：三层响应体系
全局异常处理本质是构建三层响应机制：
-
第一层：默认兜底（Spring Boot 自带）——未被拦截的异常自动跳转到
/error，返回 Whitelabel 页面或 JSON 错误体（取决于请求头 Accept） -
第二层：自定义错误页面（面向前端用户）——在
resources/templates/error/下放404.html、500.html等，Thymeleaf 可动态取${status}、${message}、${path} -
Third层：全局异常处理器（面向 API 调用方）——用
@ControllerAdvice + @ExceptionHandler捕获特定异常，统一返回Result格式
重点分支：@ControllerAdvice 实战要点
这是导图最需细化的部分，建议拆为四个子节点：
-
作用范围：默认对所有
@Controller生效；可加@RestControllerAdvice更精准匹配 REST 控制器 -
异常捕获顺序：按方法参数中异常类型的继承关系匹配，子类优先；多个
@ExceptionHandler方法时，越具体的异常类型越靠前写 -
常用捕获目标：
-
RuntimeException（兜底业务异常） -
BindException或MethodArgumentNotValidException（参数校验失败） -
HttpRequestMethodNotSupportedException（HTTP 方法不支持） - 自定义异常如
BusinessException
-
-
返回设计：推荐统一用
@ResponseBody返回 JSON；配合@ResponseStatus设置 HTTP 状态码（如@ResponseStatus(HttpStatus.BAD_REQUEST)）
配套支撑：统一响应体与日志联动
这部分容易被忽略，却是生产级导图的加分项：
-
Result 封装规范：包含
code（业务码，非仅 HTTP 状态码）、message、data、timestamp；避免暴露堆栈给前端 -
异常日志记录：在
@ExceptionHandler方法内，用log.error("业务异常", e)记录完整堆栈，便于排查 -
不建议混用：不要在同一个
@ExceptionHandler中既返回页面又返回 JSON；前后端分离项目应只走 JSON 响应路径
避坑提醒：高频失效场景
导图末尾可加一个「⚠️ 注意」分支，标出新手常踩的坑：
- 没加
@ResponseBody或没用@RestControllerAdvice→ 返回的是视图名而非 JSON - 自定义异常未继承
RuntimeException，且没显式声明捕获 → 被 Spring 默认错误页接管 - 拦截器中抛异常（如 token 校验失败 throw new AuthException）→ 若拦截器未被
@ControllerAdvice覆盖，会跳过全局处理器 - 异步方法（
@Async）中抛异常 → 不会被常规@ControllerAdvice捕获，需单独配置AsyncUncaughtExceptionHandler
