Filter由Servlet容器管理，作用于所有请求；Interceptor由Spring管理，仅拦截DispatcherServlet处理的请求。Filter更底层通用，Interceptor可访问Spring Bean和Controller上下文。
Filter 是 Servlet 规范的一部分，Interceptor 属于 Spring 框架层
Filter 在容器启动时由 Servlet 容器（如 Tomcat）加载，作用于所有请求，包括静态资源；Interceptor 是 Spring MVC 的组件，仅对进入 DispatcherServlet 的请求生效，不拦截 .js、.css 等静态文件。
这意味着：如果你要统一处理跨域、字符编码、日志记录等底层 HTTP 请求/响应操作，Filter 更底层、更通用；若需访问 Spring 容器中的 Bean（比如 UserService）、或依赖 Controller 方法参数/返回值（如注解校验、权限判断），必须用 Interceptor。
-
Filter无法直接获取 Spring 管理的 Bean，除非手动从WebApplicationContextUtils.getRequiredWebApplicationContext()获取上下文 -
Interceptor的preHandle方法返回false会中断执行链，但不会阻止 Filt
er 的
doFilter后续调用 - 多个 Filter 按
web.xml或@WebFilter的order值顺序执行；多个 Interceptor 按addInterceptor()注册顺序执行
生命周期和执行时机差异明显
Filter 的生命周期由容器管理：init() → doFilter()（可多次）→ destroy()；Interceptor 实例由 Spring 创建，其三个方法对应请求处理的不同阶段：
-
preHandle()：Controller 方法执行前，可做权限检查、日志打点。返回false则后续不执行 -
postHandle()：Controller 方法已执行、视图渲染前，可修改ModelAndView -
afterCompletion()：整个请求完成（包括视图渲染），可用于资源清理、异常统计
注意：postHandle 不会在异常发生时调用，而 afterCompletion 会，并可通过第三个参数 Exception ex 判断是否出错。
Filter 的 doFilter 必须显式调用 chain.doFilter(request, response) 才能放行，漏写会导致请求卡死；Interceptor 没有“放行”动作，靠返回值控制流程。
如何在 Filter 中获取 Spring Bean？
Filter 初始化早于 Spring 上下文，不能直接注入 Bean。常用做法是通过 ServletContext 拿到根应用上下文：
public class AuthFilter implements Filter {
private UserService userService;
@Override
public void init(FilterConfig filterConfig) throws ServletException {
ServletContext context = filterConfig.getServletContext();
WebApplicationContext webAppCtx =
WebApplicationContextUtils.getWebApplicationContext(context);
this.userService = webAppCtx.getBean(UserService.class);
}
@Override
public void doFilter(ServletRequest req, ServletResponse res,
FilterChain chain) throws IOException, ServletException {
// 使用 this.userService...
chain.doFilter(req, res);
}
}
但要注意：这种方式要求 ContextLoaderListener 已注册（即 Spring 根上下文已启动），且该 Filter 不能声明为 @Component（否则 Spring 会尝试管理它，造成初始化冲突）。
- 推荐将需要 Bean 的逻辑下沉到 Service 层，Filter 只做轻量解析（如提取 token）后交由 Interceptor 或 Controller 处理
- 若坚持在 Filter 里用 Bean，务必确认
web.xml中ContextLoaderListener的
性能与调试常见陷阱
Filter 和 Interceptor 都可能成为性能瓶颈，尤其在日志记录或加密解密场景中。关键区别在于：Filter 对所有请求生效，Interceptor 只对 MVC 请求生效——所以一个未配置静态资源排除的 Filter，可能被千万次 CSS 请求反复触发。
- Filter 中避免耗时操作（如远程调用、DB 查询），因其运行在容器线程中，阻塞直接影响吞吐量
- Interceptor 的
postHandle无法修改响应体（HttpServletResponse.getWriter()已关闭），想改响应内容得用 Filter 或ResponseBodyAdvice - 使用 Spring Boot 时，
@Bean注册的 Filter 默认不生效，需加@ServletComponentScan或用FilterRegistrationBean显式注册 - Filter 和 Interceptor 都可能被重复注册（如自动扫描 + 手动注册），导致逻辑执行两次，建议在日志中加入唯一标识排查
最常被忽略的一点：Filter 的 doFilter 如果抛出异常，容器会直接返回 500，而 Interceptor 的异常会被 Spring 的异常处理器捕获——这意味着你可能在 Filter 里看到空指针却找不到堆栈，因为异常没走到 Spring 的 @ControllerAdvice 流程里。
