Filter与Interceptor区别及使用场景分析

本文深入剖析了Java Web开发中Filter与Interceptor的核心区别、执行时机、能力边界及典型使用场景：Filter作为Servlet规范组件，工作在容器层，不依赖Spring，适用于字符编码设置、跨域处理、静态资源过滤等底层需求；Interceptor则是Spring MVC专属，嵌入MVC调度流程，天然支持Bean注入和Controller上下文，适合登录校验、权限控制、耗时统计等业务逻辑增强。二者执行顺序严格固定（Filter→Interceptor→Controller→Interceptor→Filter），且各有所长——Filter能触达原始请求流但无法直接获取Spring Bean，Interceptor可深度集成业务上下文却对非MVC请求“视而不见”。实际项目中，它们常协同作战：Filter夯实基础设施，Interceptor专注业务横切，理解其本质差异与协作逻辑，是写出高内聚、低耦合Web架构的关键所在。

Filter 是 Servlet 规范的一部分，作用在容器层面

Filter 在请求进入 Servlet 容器（如 Tomcat）后、到达 Servlet 之前执行，也能在响应返回客户端前拦截。它不依赖 Spring，只要配置在 web.xml 或用 @WebFilter 注解就能生效。

常见使用场景包括：统一字符编码设置、日志记录、跨域头添加、静态资源过滤、敏感词过滤等。

容易踩的坑：

• Filter 对 HttpServletRequest 和 HttpServletResponse 的包装类（如 HttpServletRequestWrapper）需手动继承并重写方法才能修改请求/响应体，否则无法篡改 body 内容
• Filter 无法直接获取 Spring 管理的 Bean（除非通过 WebApplicationContextUtils 手动获取上下文）
• 多个 Filter 的执行顺序由 @Order 或 web.xml 中声明顺序决定，但不支持基于路径的细粒度控制

Interceptor 是 Spring MVC 的组件，作用在 HandlerMapping 之后、Controller 执行前后

Interceptor 运行在 Spring MVC 的调度流程中，本质是 HandlerInterceptor 接口的实现类，必须注册到 WebMvcConfigurer 的 addInterceptors() 方法中才生效。

典型用途有：登录状态校验、权限检查、接口耗时统计、参数预处理（如自动注入用户信息）、全局异常前的日志埋点。

关键限制与注意点：

• 只对进入 Spring MVC 流程的请求有效（即匹配到 Controller 的请求），静态资源、错误页（如 404）、Filter 已拦截返回的响应，都不会触发 Interceptor
• 可以轻松注入其他 Spring Bean（如 UserService、RedisTemplate），天然支持依赖注入
• 三个核心方法：preHandle()（返回 false 可中断流程）、postHandle()（Controller 执行完、视图渲染前）、afterCompletion()（整个请求结束，包括异常处理后）

Filter 和 Interceptor 同时存在时的执行顺序

一个 HTTP 请求的完整链路中，它们的调用顺序是固定的：

Filter#doFilter → Interceptor#preHandle → Controller → Interceptor#postHandle → View Render → Interceptor#afterCompletion → Filter#doFilter (response phase)

这意味着：

• 若某个 Filter 调用了 chain.doFilter() 后又修改了 response body，Interceptor 的 afterCompletion() 仍能感知到最终响应状态码，但看不到 body 修改过程
• 若 preHandle() 返回 false，Controller 不会执行，但已进入的 Filter 仍会走完自己的 doFilter() 后半段（即响应阶段）
• 异常发生时，Filter 的 doFilter() 会收到 ServletException 或 IOException；而 Interceptor 的 afterCompletion() 第三个参数 Throwable 才能捕获 Controller 层抛出的业务异常

该用哪个？看你的需求是否需要 Spring 上下文和 MVC 生命周期钩子

判断依据很简单：

• 要改请求/响应的原始字节流（如 GZIP 压缩、加解密）、或控制非 Spring MVC 资源（如 /favicon.ico、/actuator/health），选 Filter
• 要读取 @RequestBody 解析后的对象、调用 @Service 方法做权限判断、或依赖 ModelAndView 做视图增强，必须用 Interceptor
• 想做全链路 traceId 透传？Filter 更底层可靠；但若 traceId 存在 ThreadLocal 里且需在 Service 层复用，Interceptor + RequestContextHolder 更方便

二者不是互斥关系，生产环境常共存：Filter 做基础设施层拦截（如 CORS、UTF-8 强制设置），Interceptor 做业务层横切逻辑（如租户隔离、操作审计）。真正容易被忽略的是——Filter 拿不到 Controller 方法签名，Interceptor 拿不到原始 input stream，各自的能力边界比文档写的更硬。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。