Java过滤器和拦截器的区别和使用场景_Filter与Interceptor功能对比及适用情况_技术教程

Filter是Servlet规范组件，作用于容器层，用于请求响应拦截；Interceptor是Spring MVC组件，作用于HandlerMapping后，依赖Spring上下文，用于Controller前后处理。

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 更方便