@ControllerAdvice是统一异常处理的主流选择，Filter仅适用于非Spring MVC流量或底层异常；业务异常应继承RuntimeException，系统异常继承Exception；ResponseBodyAdvice负责成功响应包装，@ControllerAdvice处理异常响应。
统一异常处理该用@ControllerAdvice还是Filter
Spring Boot项目里，@ControllerAdvice 是拦截 Controller 层异常的主流选择，它天然适配 Spring MVC 的异常传播链，能捕获 @ExceptionHandler 显式声明的异常类型，也能配合 @ResponseStatus 返回对应 HTTP 状态码。而 Filter 在 DispatcherServlet 前就介入，拿不到 Spring 的上下文和返回值封装能力，强行在 Filter 里做全局异常格式化会导致重复响应、状态码错乱，甚至 HttpMessageNotWritableException。
真正需要 Filter 的场景只有一种：非 Spring MVC 流量（比如直接访问静态资源、Actuator 端点出错）或必须在请求头解析前就拦截的底层异常（如非法字符导致的 IllegalStateException）。日常业务异常统一走 @ControllerAdvice 就够了。
自定义异常类要不要继承RuntimeException
要，但得按语义分层。业务异常（如参数校验失败、余额不足）应继承 RuntimeException，避免强制 try-catch 干扰主流程；系统异常（如数据库连接中断、Redis 超时）建议继承 Exception，并在调用处显式捕获后转为统一业务异常返回，防止底层错误暴露给前端。
关键点：
立即学习“Java免费学习笔记（深入）”；
- 所有自定义异常必须带
errorCode字段（String 或 int），用于前端分流或日志追踪 - 不要重写
getMessage()去拼接错误码——前端不需要看到“ERR_001: 用户不存在”，只要 “用户不存在” - 构造函数里把
errorCode存为 final 字段，避免子类篡改
ResponseBodyAdvice 与 @ControllerAdvice 怎么分工
@ControllerAdvice 负责“出错怎么报”，ResponseBodyAdvice 负责“没出错怎么包”。后者常被误用来做统一成功响应包装（如 {“code”:0, “data”:xxx}），但它不处理异常路径——异常发生时，ResponseBodyAdvice 根本不会执行。
所以：
- 成功响应统一包装用 ResponseBodyAdvice（注意排除异常类型，用 !ClassUtils.isAssignableValue(Exception.class, body) 判断）
- 异常响应统一格式用 @ControllerAdvice + @ExceptionHandler
- 两者共用同一套响应结构体（如 Result），避免前后端对“成功/失败”结构理解错位
日志记录和敏感信息过滤怎么做
在 @ExceptionHandler 方法里打日志，别在自定义异常的构造器里打——异常可能被吞掉（比如被更上层的 @ExceptionHandler 拦截），导致日志缺失。
实操要点：
- 记录
exception.getClass().getName()和exception.getMessage()，但绝不打印exception.printStackTrace()到业务日志（堆栈太长，干扰排查） - 对
SQLException、HttpClientErrorException这类带原始请求/响应的异常，提取关键字段（如 SQL 状态码、HTTP 状态码），过滤掉敏感 header（Authorization、Cookie） - 使用 MDC（Mapped Diagnostic Context）注入 traceId，确保异常日志能和正常请求日志串联
统一异常方案最难的部分不是代码怎么写，而是异常分类边界的定义——比如“库存扣减失败”该算业务异常还是系统异常？这直接影响重试策略、告警级别和前端提示方式。边界模糊时，宁可多建一个异常子类，也不要靠 if-else 分支硬扛。
