Web开发中拦截器与过滤器的核心区别与应用场景

1. 拦截器与过滤器的本质区别

在Web开发中，拦截器（Interceptor）和过滤器（Filter）这两个概念经常被混淆使用。很多开发者只是机械地套用框架提供的API，却对它们的设计哲学和适用场景缺乏深入理解。我在实际项目架构中，曾因为错误地选择技术方案导致系统性能下降40%，这个教训让我深刻认识到区分二者的重要性。

过滤器是Servlet规范定义的标准组件，它的工作层级在Web容器层面。当请求到达Servlet容器（如Tomcat）时，过滤器链会最先接触到这个请求。你可以把它想象成海关的安检通道——所有出入境人员（HTTP请求）都必须经过这个关卡的检查。过滤器通过web.xml配置或@WebFilter注解声明，能够对Request和Response进行预处理和后处理。

拦截器则是Spring等框架提供的组件，它的工作层级在应用层面。以Spring MVC为例，拦截器在DispatcherServlet处理请求时介入流程。这就像公司内部的审批流程——只有通过前台接待（过滤器）的访客，才会进入各部门的审批环节（拦截器）。拦截器需要实现HandlerInterceptor接口，通常用于处理业务相关的横切关注点。

关键区别：过滤器基于函数回调机制，而拦截器基于反射和动态代理。这意味着过滤器效率更高但功能单一，拦截器更灵活但性能开销略大。

2. 核心工作机制对比

2.1 过滤器的工作原理

过滤器的核心是javax.servlet.Filter接口，包含三个关键方法：

java复制public interface Filter {
    default void init(FilterConfig filterConfig) {}
    void doFilter(ServletRequest request, ServletResponse response, 
                 FilterChain chain) throws IOException, ServletException;
    default void destroy() {}
}

典型的工作流程如下：

1. 容器启动时调用init()方法初始化
2. 每次请求触发doFilter()方法
3. 必须调用chain.doFilter()才能传递请求
4. 容器关闭时调用destroy()清理资源

我曾在日志过滤器中忘记调用chain.doFilter()，导致所有请求阻塞，这个错误让生产环境瘫痪了15分钟。正确的做法应该是：

java复制public void doFilter(...) {
    long start = System.currentTimeMillis();
    chain.doFilter(request, response); // 必须放行
    long cost = System.currentTimeMillis() - start;
    log.info("Request cost: {}ms", cost);
}

2.2 拦截器的执行流程

Spring拦截器的工作流程更为复杂：

java复制public interface HandlerInterceptor {
    default boolean preHandle(...) throws Exception { return true; }
    default void postHandle(...) throws Exception {}
    default void afterCompletion(...) throws Exception {}
}

三个阶段的特点：

• preHandle：控制器方法执行前调用，返回false则中断流程
• postHandle：控制器方法执行后，视图渲染前调用
• afterCompletion：整个请求完成后调用（适合资源清理）

在电商项目中，我们用拦截器实现权限校验：

java复制public boolean preHandle(...) {
    String token = request.getHeader("Authorization");
    if(!jwtService.validate(token)) {
        response.sendError(401, "Invalid token");
        return false; // 中断请求
    }
    return true;
}

3. 应用场景深度解析

3.1 过滤器的典型使用场景

1. 跨域处理（CORS Filter）

java复制response.setHeader("Access-Control-Allow-Origin", "*");
response.setHeader("Access-Control-Allow-Methods", "GET,POST");

2. 请求编码设置

java复制request.setCharacterEncoding("UTF-8");
response.setCharacterEncoding("UTF-8");

3. XSS防护（使用HttpServletRequestWrapper）
4. 敏感词过滤（修改请求参数）
5. 响应压缩（GZIP）

经验：过滤器修改请求/响应时，一定要使用Wrapper类而不是直接操作，否则可能引发线程安全问题。

3.2 拦截器的优势场景

1. 权限验证（结合注解使用）

java复制@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface AuthRequired {
    String[] roles() default {};
}

2. 日志记录（记录业务参数）
3. 参数预处理（自动转换日期格式）
4. 接口限流（Redis计数器）
5. 数据绑定（ThreadLocal保存用户信息）

在微服务架构中，我们使用拦截器实现灰度发布：

java复制public boolean preHandle(...) {
    String version = request.getHeader("Api-Version");
    VersionContextHolder.setVersion(version);
    return true;
}

4. 性能对比与选型建议

4.1 基准测试数据

通过JMeter压测（100并发，Spring Boot 2.7）：

4.2 选型决策树

1. 是否需要修改请求/响应内容？
   • 是 → 选择过滤器
   • 否 → 进入下一问题
2. 是否需要访问Spring上下文？
   • 是 → 选择拦截器
   • 否 → 进入下一问题
3. 是否涉及业务逻辑？
   • 是 → 拦截器
   • 否 → 过滤器

在物联网项目中，我们混合使用两者：

• 过滤器：处理设备上报数据的解码和校验
• 拦截器：实现设备权限管理和指令分发

5. 高级应用与常见陷阱

5.1 过滤器链的坑

1. 顺序问题：web.xml中filter-mapping的顺序决定执行顺序

xml复制<!-- 先执行LogFilter -->
<filter-mapping>
    <filter-name>LogFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

<!-- 后执行AuthFilter -->
<filter-mapping>
    <filter-name>AuthFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

2. 多次读取请求体：需要缓存InputStream
3. 异步请求处理：必须声明ASYNC支持

5.2 拦截器进阶技巧

1. 多拦截器顺序控制：通过Order接口或@Order注解

java复制@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LogInterceptor()).order(1);
        registry.addInterceptor(new AuthInterceptor()).order(2);
    }
}

2. 排除特定路径：

java复制registry.addInterceptor(intc)
       .addPathPatterns("/api/**")
       .excludePathPatterns("/api/public/**");

3. 参数注入技巧：

java复制public boolean preHandle(...) {
    Method method = ((HandlerMethod)handler).getMethod();
    AuthRequired auth = method.getAnnotation(AuthRequired.class);
    // ...
}

6. 实战中的血泪教训

1. 过滤器中的异常处理：

java复制try {
    chain.doFilter(request, response);
} catch (Exception e) {
    // 必须处理异常，否则Tomcat会返回500页面
    response.setStatus(500);
    response.getWriter().write("{\"code\":500}");
}

2. 拦截器preHandle的返回值陷阱：

java复制public boolean preHandle(...) {
    if(condition) {
        response.sendRedirect("/login"); // 需要返回false！
        return false;
    }
    return true;
}

3. 静态资源拦截问题：

java复制// 错误配置：会拦截CSS/JS文件
registry.addInterceptor(intc).addPathPatterns("/**");

// 正确做法
registry.addInterceptor(intc)
       .addPathPatterns("/api/**")
       .excludePathPatterns("/static/**");

4. 内存泄漏预防：

java复制public void afterCompletion(...) {
    // 必须清理ThreadLocal
    UserContextHolder.remove(); 
}

在大型金融项目中，我们曾因为未清理ThreadLocal导致内存堆积了300MB的用户数据。这个故障告诉我们：拦截器的afterCompletion不是可选项，而是必须实现的保障机制。