Filter中异常默认不被@ControllerAdvice捕获，需在Filter内捕获后转发至Controller；Interceptor中preHandle抛出的异常可被@ControllerAdvice捕获，afterCompletion则不可。
Filter 和 Interceptor 中抛出的异常默认不会被 @ControllerAdvice 拦截，因为它们不在 Spring MVC 的异常处理链路内——@ControllerAdvice 只捕获从 Controller → AOP → DispatcherServlet 这一路径上抛出的异常，而 Filter 在 Servlet 容器层、Interceptor 在 DispatcherServlet 内部但早于 Controller 执行，异常一旦在它们内部未被处理，就会直接跳出 Spring MVC 上下文，交由 Servlet 容器（如 Tomcat）处理，最终落到默认的 /error 或 ErrorController。
Filter 中异常如何让 ControllerAdvice 处理
Filter 属于 Servlet 规范，运行在 Spring MVC 之外。它抛出的异常（如自定义 UserException）若未被捕获，会跳过所有 Spring 异常处理器，直接触发容器级错误响应（如 500 + 默认 JSON 或白页）。
- ✅ 推荐做法：在 Filter 中捕获异常，转为请求转发（forward）到一个专用 Controller 接口（如
/internal/error），再由该 Controller 主动抛出异常，使异常进入 Spring MVC 链路 - ✅ 替代方案：注入
HandlerExceptionResolver，手动调用resolveException()，将异常交由 Spring 的异常解析机制处理（需确保 Bean 已初始化） - ❌ 不要直接 throw：不加干预地抛出异常，
@RestControllerAdvice无法捕获
Interceptor 中异常如何透传给 ControllerAdvice
Interceptor 的 preHandle() 方法若抛出异常，DispatcherServlet 会终止后续执行，但该异常仍属于 Spring MVC 调度范围内，只要不被拦截器自己 try-catch 吞掉，就能被 @ControllerAdvice 捕获。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- ✅ 正确写法：在
preHandle中校验失败时直接 throw 自定义异常（如AuthException），不 catch - ✅ 确保异常类型已被
@ExceptionHandler显式声明覆盖（例如@ExceptionHandler(AuthException.class)） - ⚠️ 注意：若在
afterCompletion()抛异常，则不会被 ControllerAdvice 捕获（此时请求已结束，Spring MVC 不再介入）
统一兜底：用 ErrorController 补齐 Filter 异常场景
当 Filter 异常必须走统一格式（如返回 JSON 错误体），又不想改 Filter 逻辑时，可实现 ErrorController 替换默认的 BasicErrorController，并在其中调用原有 @RestControllerAdvice 的处理逻辑复用已有错误转换能力。
立即学习“Java免费学习笔记（深入）”；
- 实现
ErrorController接口，重写getErrorPath()返回/error - 在
errorhandler 方法中，获取HttpServletRequest.getAttribute("javax.servlet.error.exception")提取原始异常 - 委托给已有的异常处理器（如注入
AppExceptionHandler实例）执行格式化，避免重复逻辑
关键区别与选型建议
不是所有校验都适合放 Filter。权限/登录类校验更推荐用 Interceptor 或 Spring Security，因其天然集成 Spring 异常体系；Filter 更适合字符编码、日志、跨域等无业务语义的预处理。
- 优先用 Interceptor：需要统一异常处理 + 业务相关校验 → 异常自动进
@ControllerAdvice - Filter 仅用于非业务通用逻辑：如 GZIP 压缩、请求体缓存、黑白名单等，异常应尽量避免或自行处理
- 若必须用 Filter 做鉴权，请用「转发到 Controller」方式，而非直抛异常
