在 Spring Boot 项目中，我们经常会遇到需要在请求处理前后执行一些通用逻辑的场景，比如记录日志、权限校验、全局异常处理等。此时，我们通常会面临两种选择：过滤器（Filter） 和 拦截器（Interceptor）。

虽然两者都能实现类似的功能，但它们在实现原理、使用场景、执行时机等方面有着本质的区别。本文将带你深入剖析这两者的差异，并通过实战案例，让你彻底搞懂何时该用过滤器，何时该用拦截器。

一、核心概念：从根上理解它们的区别

1.1 过滤器（Filter）

• 规范层级：属于 Java Servlet 规范 的一部分，由 Servlet 容器（如 Tomcat）直接管理。
• 作用范围：对整个 Web 应用生效，包括静态资源（如 HTML、CSS、JS 等）。
• 触发时机：在请求进入 DispatcherServlet 之前，以及响应返回客户端之后。
• 依赖关系：不依赖 Spring 容器，可以脱离 Spring 独立使用。

1.2 拦截器（Interceptor）

• 规范层级：Spring MVC 框架提供的机制，由 Spring 容器管理。
• 作用范围：仅对 Spring MVC 控制器（Controller） 的请求生效，默认不拦截静态资源。
• 触发时机：在请求进入 DispatcherServlet 之后，到达 Controller 之前，以及 Controller 处理完请求之后。
• 依赖关系：深度集成 Spring 容器，可以方便地使用 Spring 的依赖注入（DI）和 AOP 功能。

特性对比	过滤器（Filter）	拦截器（Interceptor）
规范层级	Java Servlet 规范	Spring MVC 框架
作用范围	所有请求（包括静态资源）	仅 Controller 请求
触发时机	DispatcherServlet 前后	Controller 前后
依赖容器	Servlet 容器	Spring 容器
能否修改请求/响应	可以直接修改	不能直接修改，但可操作 Model 和 View

二、执行流程：一个图看懂它们的调用顺序

为了更直观地理解两者的执行顺序，我们来看一张经典的流程图：

HTTP Request↓
Filter Chain（doFilter）↓
DispatcherServlet↓
Interceptor.preHandle↓
Controller Method↓
Interceptor.postHandle↓
View Rendering（如有）↓
Interceptor.afterCompletion↓
Filter Chain（返回响应）

从这个流程可以看出：

• 过滤器 是最外层的“大门”，所有请求都必须经过它。
• 拦截器 是内层的“小门”，只对进入 Spring MVC 的请求生效。

三、实战演练：代码说话最真实

3.1 过滤器（Filter）实战：记录请求耗时

@Component
public class LogFilter implements Filter {private static final Logger logger = LoggerFactory.getLogger(LogFilter.class);@Overridepublic void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)throws IOException, ServletException {long startTime = System.currentTimeMillis();HttpServletRequest httpRequest = (HttpServletRequest) request;logger.info("请求开始，URI: {}", httpRequest.getRequestURI());chain.doFilter(request, response); // 放行请求long duration = System.currentTimeMillis() - startTime;logger.info("请求结束，耗时: {}ms", duration);}
}

3.2 拦截器（Interceptor）实战：登录权限校验

@Component
public class AuthInterceptor implements HandlerInterceptor {@Autowiredprivate AuthService authService; // 可以注入Spring Bean@Overridepublic boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {String token = request.getHeader("Authorization");if (!authService.isValidToken(token)) {response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);return false; // 拦截请求}return true; // 放行请求}@Overridepublic void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {logger.info("Controller 方法执行完毕，准备渲染视图");}@Overridepublic void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {logger.info("请求处理完成，资源清理");}
}

3.3 配置拦截器到Spring容器

@Configuration
public class WebMvcConfig implements WebMvcConfigurer {@Autowiredprivate AuthInterceptor authInterceptor;@Overridepublic void addInterceptors(InterceptorRegistry registry) {registry.addInterceptor(authInterceptor).addPathPatterns("/api/**") // 拦截所有 /api 开头的请求.excludePathPatterns("/api/login"); // 排除登录接口}
}

四、选型指南：什么时候用过滤器，什么时候用拦截器？

场景需求	推荐方案
需要处理静态资源（如HTML、CSS、JS）	过滤器（Filter）
需要最早拦截请求（如全局跨域处理）	过滤器（Filter）
需要访问Spring Bean（如Service、Repository）	拦截器（Interceptor）
需要精确控制Controller方法的执行前后	拦截器（Interceptor）
需要修改请求和响应的内容（如压缩、编码）	过滤器（Filter）

五、常见误区与最佳实践

5.1 常见误区

• 误区1：拦截器可以处理静态资源
  实际上，拦截器默认不会拦截静态资源，除非你手动配置了 addResourceHandler。

• 误区2：过滤器可以直接使用Spring Bean
  过滤器由Servlet容器管理，默认无法使用Spring的依赖注入。可以通过 DelegatingFilterProxy 桥接，但配置较复杂。

• 误区3：拦截器可以修改请求参数
  拦截器无法直接修改请求参数，如需修改，需使用过滤器配合 HttpServletRequestWrapper。

5.2 最佳实践

• 优先使用拦截器：除非必须处理静态资源或需要最早拦截，否则优先使用拦截器，因为它更贴近业务逻辑，且易于测试。
• 避免复杂逻辑：无论是过滤器还是拦截器，都应避免复杂的业务逻辑，以免影响性能。
• 合理配置顺序：如果同时使用多个过滤器或拦截器，务必注意它们的执行顺序，避免逻辑冲突。

六、总结：一句话记住它们的区别

过滤器（Filter）是 Servlet 的“大门”，拦截器（Interceptor）是 Spring MVC 的“小门”。

• Filter：更早、更底层、更通用，但离业务逻辑较远。
• Interceptor：更晚、更上层、更灵活，更贴近业务逻辑。