1. 项目概述为什么我们需要“门卫”和“巡逻队”在Web应用开发的世界里尤其是基于Spring Boot这类主流框架构建系统时我们常常会听到“过滤器”和“拦截器”这两个词。很多开发者尤其是刚入行的朋友可能会觉得它们功能相似都是用来“拦”请求的用哪个好像都差不多。但在我十多年的项目实战中无数次踩坑和调优的经历告诉我这俩兄弟虽然目标一致——保卫你的应用但它们的职责、能力和工作时机有着本质的区别。用错了地方轻则功能失效、性能低下重则可能引入安全漏洞让整个系统的防线形同虚设。简单来说你可以把过滤器想象成小区门口的保安门卫。他的工作范围很广所有想进出小区的人HTTP请求和响应都必须经过他。他可以检查你的健康码验证请求头、测量体温校验参数、或者拒绝一个形迹可疑的人入内拦截非法请求。他的权力很大能在请求真正进入你家即Spring容器、你的Controller之前就进行处理甚至能直接“遣返”返回响应。而拦截器则更像是进入你家楼道后的巡逻队或智能管家。他已经知道你是小区的合法住户请求已经通过了Servlet容器的初步过滤他的工作更精细专注于你在“家”里的行为比如记录你什么时候出门记录日志、在你进门前自动开灯预处理、或者在你离家后检查电器是否关闭后处理。他深度集成在Spring MVC的流程中能方便地获取Spring容器中的各种“家具”Bean。理解这两者的奥秘不是为了应付面试而是为了在构建健壮、安全、高效的应用时能做出最合适的技术选型。当你的应用面临恶意爬虫刷接口、需要统一鉴权、或者要对所有业务操作进行审计日志记录时你知道该派“保安”还是“管家”上场这就是核心价值所在。2. 核心原理深度拆解从Servlet到Spring MVC的请求之旅要彻底搞懂过滤器和拦截器我们必须把一次HTTP请求在Java Web应用中的完整生命周期摊开来看。这就像跟踪一个快递包裹从发货到签收的全过程每个环节都有不同的“工作人员”在处理。2.1 过滤器的定位与能力边界过滤器是Java EE现在是Jakarta EE规范定义的标准组件它的工作层级在Servlet容器如Tomcat、Jetty级别。这意味着它完全不依赖于Spring框架即使是一个最原始的Servlet应用你也可以使用过滤器。它的工作时机非常早当一个HTTP请求到达服务器时Servlet容器会首先创建一个ServletRequest和ServletResponse对象。紧接着容器就会查找所有配置好的过滤器并按顺序将它们组织成一个“过滤器链”。请求会像穿过一道道水闸一样依次经过每个过滤器。客户端请求 - Tomcat容器 - 过滤器1 - 过滤器2 - ... - 过滤器N - Servlet (DispatcherServlet) - 你的应用在这个过程中每个过滤器都拥有对原始ServletRequest和ServletResponse的完全控制权检查请求可以读取、修改甚至包装请求对象例如使用HttpServletRequestWrapper来增加参数。拦截请求如果认为请求非法如Token无效、IP黑名单可以直接调用response.sendError()或response.getWriter().write()返回响应请求就此终止根本不会到达后续的过滤器和Servlet。放行请求调用chain.doFilter(request, response)将请求传递给链中的下一个过滤器或最终的Servlet。处理响应当请求被后续组件处理完生成响应后响应会沿着过滤器链反向穿回。每个过滤器还有机会对响应内容进行修改如统一添加响应头、压缩响应体。关键特性总结作用范围广能过滤所有请求包括静态资源如.js,.css, 图片。与框架无关是Servlet规范的一部分不感知Spring。控制力强可以终止请求-响应周期。无法直接使用Spring Bean因为此时Spring的上下文可能还未完全初始化或无法直接注入。2.2 拦截器的定位与Spring集成优势拦截器是Spring MVC框架特有的组件。它的工作层级在Spring Web MVC框架内部具体是在核心控制器DispatcherServlet处理请求的过程中。它的工作时机相对靠后请求已经通过了Servlet容器的所有过滤器并已经被DispatcherServlet接收。DispatcherServlet会根据请求的URL找到对应的处理器Handler通常是我们的Controller方法但在执行这个处理器前后就是拦截器发挥作用的舞台。Spring MVC定义了一个清晰的处理器执行链其中包含了拦截器DispatcherServlet 收到请求 - 预处理拦截器 - 执行Controller方法 - 后处理拦截器 - 渲染视图 - 完成处理拦截器拦截器的主要方法preHandle在Controller方法执行前调用。返回true则继续执行链返回false则中断流程类似过滤器的拦截。postHandle在Controller方法执行后但视图渲染前调用。此时可以修改模型数据ModelAndView。afterCompletion在整个请求完成后调用主要用于资源清理、日志记录等。关键特性总结作用范围精准通常只针对Controller的请求映射可以通过配置排除静态资源。深度Spring集成本身就是Spring Bean可以方便地使用Autowired注入其他Spring管理的服务如数据库服务、日志服务。能获取处理器信息可以拿到即将执行的HandlerMethod对象从而知道是哪个Controller的哪个方法便于做更精细化的控制如基于注解的权限检查。无法处理静态资源默认不拦截静态资源请求。2.3 核心差异对照表为了更直观地对比我将两者的核心差异整理成下表特性维度过滤器拦截器规范/框架Servlet 规范 (javax.servlet.Filter)Spring MVC 框架 (org.springframework.web.servlet.HandlerInterceptor)作用范围所有请求包括静态资源通常只针对Spring MVC映射的请求可通过配置调整依赖关系不依赖Spring是Web容器组件强依赖Spring MVC框架获取Spring Bean无法直接注入需通过特殊方式可以直接注入本身就是Spring Bean执行时机在Servlet之前响应返回客户端之前在DispatcherServlet之后Controller方法执行前后控制粒度较粗基于URL模式较细可基于HandlerMethod具体方法典型应用场景全局编码设置、CORS处理、XSS防御、基础身份验证、请求/响应日志记录原始、压缩业务权限校验、审计日志需业务上下文、执行时间计算、统一异常处理、模型数据加工实操心得一个快速记忆法——“滤前拦后”。过滤器工作在更“前”的容器层像一道外网防火墙拦截器工作在更“后”的业务框架层像一套内网安全策略。选择时先问自己这个逻辑是否需要处理静态资源是否需要用到Spring的Bean是否需要知道具体是哪个Controller方法3. 实战构建手把手打造你的应用安全防线理论讲透了我们来点实际的。我将通过一个典型的Web应用安全需求场景展示如何分别使用过滤器和拦截器并解释为什么这么选。场景假设我们有一个Spring Boot 2.7.x的RESTful API项目需要实现以下安全与管控功能全局请求日志记录所有进入应用的请求的IP、URL、方法、时间以及耗时。用于监控和问题排查。接口鉴权对于/api/private/**路径下的私有API需要验证请求头中的X-Auth-Token是否有效。防重复提交对于某些关键写操作如支付下单需要防止用户在短时间内重复提交。3.1 使用过滤器实现全局请求日志与基础安全对于全局请求日志我们希望记录每一个请求包括对前端静态页面、图标等资源的请求。这要求组件必须在最外层工作且不关心具体业务逻辑。过滤器是完美选择。Component Order(1) // 定义过滤器执行顺序数字越小优先级越高 Slf4j public class GlobalLoggingFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req (HttpServletRequest) request; HttpServletResponse res (HttpServletResponse) response; long startTime System.currentTimeMillis(); String requestId UUID.randomUUID().toString(); // 生成唯一请求ID // 将请求ID放入MDC方便日志链路追踪 MDC.put(requestId, requestId); // 也可以将请求ID设置到响应头方便前端排查 res.setHeader(X-Request-ID, requestId); // 记录请求开始日志 log.info( 请求开始 [ID:{}] IP:{} {} {}?{}, requestId, getClientIp(req), req.getMethod(), req.getRequestURI(), req.getQueryString()); try { // 继续执行过滤器链 chain.doFilter(request, response); } finally { // 无论成功失败最终都会执行这里 long duration System.currentTimeMillis() - startTime; int status res.getStatus(); log.info( 请求结束 [ID:{}] 状态:{} 耗时:{}ms, requestId, status, duration); // 清除MDC中的请求ID MDC.remove(requestId); } } private String getClientIp(HttpServletRequest request) { // 一个简单的获取真实IP的方法实际生产环境需要考虑代理 String ip request.getHeader(X-Forwarded-For); if (ip null || ip.isEmpty() || unknown.equalsIgnoreCase(ip)) { ip request.getHeader(Proxy-Client-IP); } if (ip null || ip.isEmpty() || unknown.equalsIgnoreCase(ip)) { ip request.getHeader(WL-Proxy-Client-IP); } if (ip null || ip.isEmpty() || unknown.equalsIgnoreCase(ip)) { ip request.getRemoteAddr(); } return ip; } Override public void init(FilterConfig filterConfig) throws ServletException { log.info(全局日志过滤器初始化...); } Override public void destroy() { log.info(全局日志过滤器销毁...); } }为什么用过滤器记录全面chain.doFilter()包裹在try-finally中确保无论后续处理是成功、抛出异常还是被其他过滤器拦截都能记录到结束日志和耗时。性能影响小仅记录基本信息不涉及IO操作如写入数据库对性能影响微乎其微。作用于所有资源即使是/favicon.ico或/static/js/app.js这样的请求也会被记录这对于分析异常访问模式很有帮助。注意事项在过滤器中直接调用response.getWriter()并写入内容后务必谨慎调用chain.doFilter()否则可能导致响应体被重复写入。通常如果你已经在过滤器中生成了完整的响应如返回错误JSON就应该直接return不再放行。3.2 使用拦截器实现精细化的接口鉴权对于接口鉴权我们需要验证Token。这个逻辑需要查询数据库或缓存来验证Token有效性因此必须用到Spring管理的AuthServiceBean。同时我们可能只需要对特定的API路径进行鉴权。拦截器是最佳选择。首先定义一个自定义注解用于更灵活地标记需要鉴权的方法Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequireAuth { // 可以扩展权限角色如 String[] roles() default {}; }然后实现我们的鉴权拦截器Component public class AuthenticationInterceptor implements HandlerInterceptor { Autowired private AuthService authService; // 依赖Spring Bean Autowired private ObjectMapper objectMapper; // Jackson用于生成JSON响应 Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 1. 检查是否为HandlerMethod排除资源处理器等 if (!(handler instanceof HandlerMethod)) { return true; } HandlerMethod handlerMethod (HandlerMethod) handler; Method method handlerMethod.getMethod(); // 2. 检查控制器类或方法上是否有RequireAuth注解 boolean requireAuthOnMethod method.isAnnotationPresent(RequireAuth.class); boolean requireAuthOnClass method.getDeclaringClass().isAnnotationPresent(RequireAuth.class); if (!requireAuthOnMethod !requireAuthOnClass) { // 不需要鉴权直接放行 return true; } // 3. 需要鉴权从请求头获取Token String token request.getHeader(X-Auth-Token); if (token null || token.isBlank()) { sendErrorResponse(response, 401, 未提供认证令牌); return false; // 中断执行链 } // 4. 验证Token调用Spring Bean服务 UserInfo userInfo authService.validateToken(token); if (userInfo null) { sendErrorResponse(response, 403, 令牌无效或已过期); return false; } // 5. 鉴权通过将用户信息存入请求属性供Controller使用 request.setAttribute(CURRENT_USER, userInfo); return true; } private void sendErrorResponse(HttpServletResponse response, int status, String message) throws IOException { response.setStatus(status); response.setContentType(application/json;charsetUTF-8); MapString, Object result new HashMap(); result.put(code, status); result.put(message, message); result.put(timestamp, System.currentTimeMillis()); response.getWriter().write(objectMapper.writeValueAsString(result)); } // postHandle和afterCompletion可以根据需要实现例如记录操作日志 }最后通过配置类注册拦截器并指定拦截路径Configuration public class WebMvcConfig implements WebMvcConfigurer { Autowired private AuthenticationInterceptor authenticationInterceptor; Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(authenticationInterceptor) .addPathPatterns(/api/**) // 拦截所有/api下的请求 .excludePathPatterns(/api/public/**, /error); // 排除公开API和错误端点 } }为什么用拦截器依赖注入可以方便地使用Autowired注入AuthService和ObjectMapper这是过滤器难以做到的需要额外 hack。精细控制通过判断HandlerMethod和自定义注解可以精确控制哪些方法需要鉴权哪些不需要避免了在过滤器中写一堆if-else判断URL。信息丰富能获取到即将执行的具体方法信息为后续的审计日志记录“谁”在“什么时候”调用了“哪个方法”提供了极大便利。3.3 混合使用防重复提交的进阶方案防重复提交是一个经典问题。一个健壮的方案往往需要过滤器和拦截器协作。思路过滤器负责生成唯一请求标识在请求最早进入时生成一个唯一键如userId:接口路径:请求参数摘要这个键需要能唯一标识“同一个用户的同一笔操作”。拦截器或AOP负责业务逻辑判断在请求进入业务方法前用这个唯一键去分布式缓存如Redis中尝试设置一个带有短暂过期时间的锁。如果设置成功表示第一次提交则放行如果设置失败表示重复提交则直接返回错误。过滤器部分生成标识Component Order(2) // 在日志过滤器之后执行 public class IdempotencyKeyFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req (HttpServletRequest) request; // 可以从Header中获取客户端生成的幂等键如果没有则自己生成一个 String idempotencyKey req.getHeader(X-Idempotency-Key); if (idempotencyKey null || idempotencyKey.isEmpty()) { // 简单示例使用UUID。生产环境可能需要更复杂的规则结合用户和请求特征 idempotencyKey gen_ UUID.randomUUID().toString(); } // 将幂等键存入请求属性供后续组件使用 req.setAttribute(IDEMPOTENCY_KEY, idempotencyKey); chain.doFilter(request, response); } }拦截器部分检查幂等性Component public class IdempotencyInterceptor implements HandlerInterceptor { Autowired private RedisTemplateString, String redisTemplate; // 使用Redis Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 只对标注了Idempotent的方法进行检查 if (handler instanceof HandlerMethod) { HandlerMethod hm (HandlerMethod) handler; if (!hm.hasMethodAnnotation(Idempotent.class)) { return true; } String idempotencyKey (String) request.getAttribute(IDEMPOTENCY_KEY); if (idempotencyKey null) { sendErrorResponse(response, 400, 缺少幂等键); return false; } // 尝试在Redis中设置键过期时间设为10秒 Boolean success redisTemplate.opsForValue().setIfAbsent(idempotent: idempotencyKey, processing, 10, TimeUnit.SECONDS); if (Boolean.FALSE.equals(success)) { // 键已存在说明是重复请求 sendErrorResponse(response, 409, 请求正在处理或请勿重复提交); return false; } } return true; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception { // 请求处理完成后可以根据业务成功与否决定是删除键还是更新状态 // 例如只有业务成功时才删除失败则保留键让客户端重试 if (handler instanceof HandlerMethod) { HandlerMethod hm (HandlerMethod) handler; if (hm.hasMethodAnnotation(Idempotent.class)) { String idempotencyKey (String) request.getAttribute(IDEMPOTENCY_KEY); if (idempotencyKey ! null response.getStatus() 200) { // 业务成功删除锁允许相同的幂等键发起新的业务请求非重试 redisTemplate.delete(idempotent: idempotencyKey); } } } } // ... sendErrorResponse 方法同上 }这种协作模式的优势职责分离过滤器做通用的、与业务无关的“标识生成”工作。拦截器做与业务注解相关的“逻辑判断”工作。灵活性强可以通过注解轻松控制哪些接口需要防重哪些不需要。性能与一致性利用Redis等外部存储可以很好地支持分布式环境下的防重提交。4. 进阶应用与性能调优实战掌握了基本用法我们来看看在复杂和高并发场景下如何用好过滤器和拦截器并规避其中的陷阱。4.1 过滤器链的优化与陷阱当配置了多个过滤器时它们的执行顺序由Order注解或web.xml中的配置顺序决定。顺序至关重要。一个常见的性能陷阱日志过滤器放在鉴权过滤器之后假设你有两个过滤器AuthFilter鉴权和LoggingFilter日志。如果LoggingFilter先执行它会记录所有请求的开始。但当请求被AuthFilter拦截并返回401错误时LoggingFilter的finally块仍然会记录“请求结束”。这看起来没问题。 但如果顺序反过来AuthFilter先执行它拦截了非法请求并直接返回响应请求根本不会到达LoggingFilter。这会导致你的访问日志缺失这部分非法请求记录对于安全审计来说是致命的。因此日志过滤器的顺序应尽可能靠前。最佳实践建议安全第一像CorsFilter处理跨域这种必须最早响应的过滤器应设为最高优先级Order(Ordered.HIGHEST_PRECEDENCE)。日志紧随其后全局日志过滤器应放在安全过滤器之后其他业务过滤器之前确保记录所有“到达”的请求。资源处理靠前如CharacterEncodingFilter设置编码应在请求体被读取之前生效。业务鉴权居中像AuthenticationFilter这类业务过滤器放在编码、日志之后。内容处理靠后如GzipFilter响应压缩应放在最后因为它需要处理最终的响应体。使用OncePerRequestFilter Spring提供了一个便利的抽象类OncePerRequestFilter。它确保在单个请求生命周期内doFilterInternal方法只被执行一次。这在转发RequestDispatcher.forward或包含include等场景下非常有用可以避免过滤器被重复执行。强烈建议继承它来实现自定义过滤器。Component public class MySafeFilter extends OncePerRequestFilter { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { // 你的过滤逻辑 // 这个方法保证只被调用一次 filterChain.doFilter(request, response); } }4.2 拦截器与Spring Boot Actuator的冲突处理Spring Boot Actuator提供了很多监控端点如/actuator/health,/actuator/metrics。如果你配置的拦截器路径是/**那么这些端点也会被拦截可能导致健康检查失败或监控数据异常。解决方案在注册拦截器时明确排除Actuator端点。Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(myInterceptor) .addPathPatterns(/**) .excludePathPatterns( /actuator/**, /error, /swagger-resources/**, /swagger-ui/**, /v3/api-docs/** ); }4.3 异步请求下的特殊考量在Spring MVC中当控制器方法返回DeferredResult、Callable或使用ResponseBody配合异步Servlet时请求的处理是异步的。这对拦截器的生命周期有影响。preHandle在异步线程开始时执行。postHandle对于异步请求postHandle会立即被调用此时异步处理还未完成并且传入的ModelAndView为null。这意味着你不能在postHandle中修改异步处理的结果。afterCompletion在异步请求处理完成后调用无论是超时、正常完成还是出错。因此资源清理和最终日志记录必须放在afterCompletion中。异步场景下的日志记录示例Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { long startTime (Long) request.getAttribute(startTime); long endTime System.currentTimeMillis(); log.info(异步请求最终完成总耗时{}ms, endTime - startTime); // 清理ThreadLocal等资源 MyThreadLocalContext.clear(); }你需要将startTime在preHandle中存入request属性。4.4 与Spring Security的协作与区分这是一个高频困惑点。Spring Security本身就是一个基于过滤器链的强大安全框架。当你同时使用自定义过滤器和Spring Security时你需要清楚它们的位置关系。Spring Security的过滤器链FilterChainProxy通常作为一个单独的过滤器插入到整个过滤器链中。你的自定义过滤器可能在它之前或之后执行这取决于你的配置Order。基本原则在Security之前的过滤器可以处理一些Security不关心的、更通用的逻辑如全局日志、编码。但无法获取Security认证信息因为此时用户尚未被认证。在Security之后的过滤器可以获取到SecurityContext中的认证信息如用户名、角色。但需注意如果请求被Security拦截如未登录则不会到达后面的过滤器。更常见的做法是使用Spring Security提供的扩展点而不是自己写过滤器去干涉安全流程。例如实现AuthenticationSuccessHandler认证成功处理或AccessDeniedHandler权限拒绝处理。对于需要在安全上下文中执行的逻辑使用拦截器是更自然的选择因为它肯定在Spring Security过滤器之后执行。5. 生产环境排坑指南与性能考量在实际项目中我遇到过不少由过滤器和拦截器引发的问题。这里分享几个典型案例和解决方案。5.1 问题一过滤器内读取了请求体导致Controller中RequestBody为空现象在过滤器中通过request.getInputStream()读取了请求体例如为了做签名验证然后调用chain.doFilter()。结果后面的Controller方法中RequestBody注解绑定的参数始终为null。根因Servlet的InputStream和Reader通常只能被读取一次。过滤器读取后流就到了末尾后续的Spring消息转换器如MappingJackson2HttpMessageConverter再读就是空。解决方案使用ContentCachingRequestWrapperSpring提供这个包装类可以将请求体缓存起来允许多次读取。但注意它需要先将整个请求体读入内存对大文件上传不友好。public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req (HttpServletRequest) request; ContentCachingRequestWrapper wrappedRequest new ContentCachingRequestWrapper(req); // 在wrappedRequest上读取body byte[] body wrappedRequest.getContentAsByteArray(); // 第一次读取会触发缓存 // ... 你的逻辑 chain.doFilter(wrappedRequest, response); // 传递包装后的请求 }自定义HttpServletRequestWrapper更灵活的方式是自己实现一个Wrapper将读取的请求体内容保存下来并重写getInputStream()和getReader()方法返回缓存内容的新流。这是很多开源库的做法。改变架构如果只是为了获取几个参数做验证考虑将签名信息放在Header中而不是Body里。或者使用拦截器在Spring MVC层面通过RequestBody的参数解析器处理后的对象进行操作。5.2 问题二拦截器preHandle中抛出的异常无法被ControllerAdvice统一异常处理器捕获现象在拦截器的preHandle方法中如果参数校验不通过直接抛出RuntimeException期望被全局的ControllerAdvice ExceptionHandler处理并返回统一的错误JSON但实际返回的是Tomcat默认的500错误页面。根因ControllerAdvice是Spring MVC的组件它只处理控制器方法执行过程中以及视图渲染过程中抛出的异常。拦截器的preHandle执行时尚未进入控制器方法执行流程因此其抛出的异常由Servlet容器Tomcat处理而非Spring MVC。解决方案在拦截器内部处理异常并生成响应推荐就像我们前面鉴权拦截器示例中的sendErrorResponse方法一样在preHandle里捕获异常或判断失败后直接操作HttpServletResponse返回JSON错误信息然后返回false。Override public boolean preHandle(...) { try { // 校验逻辑 if (!valid) { writeJsonResponse(response, 400, 参数无效); return false; } } catch (Exception e) { writeJsonResponse(response, 500, 系统内部错误); return false; } return true; }配置Servlet容器的错误页面在application.yml中配置将特定状态码或异常类型映射到某个Controller路径由Spring MVC来处理。但这相对繁琐且不够灵活。5.3 问题三过滤器和拦截器中的性能瓶颈潜在瓶颈同步阻塞操作在doFilter或preHandle中执行耗时的IO操作如远程调用、复杂数据库查询会阻塞整个请求线程。内存泄漏在过滤器或拦截器中使用了ThreadLocal但在请求结束后没有及时清理remove在线程池复用的环境下会导致内存泄漏和信息错乱。频繁的序列化/反序列化如为了日志或验证在过滤器中反复将请求/响应体转换成字符串。优化建议异步处理对于非关键性的、耗时的操作如发送审计日志到消息队列考虑使用异步方式。在过滤器中可以将任务提交给一个线程池避免阻塞主链。但要注意异步上下文传递如RequestContextHolder。资源及时清理在finally块或拦截器的afterCompletion方法中务必清理ThreadLocal、关闭临时流等资源。采样记录全量日志记录对性能有影响。在高并发场景下可以考虑采样记录例如只记录1%的请求或者只记录慢请求耗时超过阈值的。避免重复解析如果多个组件都需要请求体信息考虑使用ContentCachingRequestWrapper并只解析一次将解析结果如Map存入请求属性供后续使用。5.4 配置检查清单在将应用部署上线前建议对照此清单检查你的过滤器和拦截器配置[ ]执行顺序关键过滤器如CORS、日志、编码的顺序是否正确Order值是否合理[ ]路径匹配拦截器的addPathPatterns和excludePathPatterns是否准确覆盖了目标接口并排除了静态资源、Actuator端点、Swagger文档等[ ]异步支持如果项目使用异步Servlet拦截器中的资源清理是否放在了afterCompletion中ThreadLocal是否被正确清理[ ]异常处理拦截器preHandle中的失败场景是否已妥善处理并返回了友好的客户端响应[ ]性能影响是否在过滤/拦截链中引入了不必要的同步阻塞调用全量日志是否会对高并发接口造成压力[ ]安全审查用于鉴权的过滤器/拦截器其逻辑是否存在绕过漏洞Token验证是否防重放防重复提交的键生成算法是否足够唯一[ ]测试覆盖是否编写了单元测试和集成测试覆盖了正常流程、鉴权失败、重复提交、异常抛出等场景纸上得来终觉浅绝知此事要躬行。过滤器和拦截器是构建稳固Web应用的基石组件它们的正确使用直接关系到系统的安全性、可观测性和可维护性。我个人的经验是在项目初期就规划好它们的职责边界通过一个清晰的配置类来管理顺序和路径并为之编写充分的测试用例。当出现一个横切关注点时先问“这个逻辑需要看到Spring的世界吗”是则选拦截器再问“这个逻辑需要处理所有流量包括静态文件吗”是则选过滤器大多数时候你都能找到清晰的答案。记住没有最好的组件只有最合适的场景。
1. 项目概述为什么我们需要“门卫”和“巡逻队”在Web应用开发的世界里尤其是基于Spring Boot这类主流框架构建系统时我们常常会听到“过滤器”和“拦截器”这两个词。很多开发者尤其是刚入行的朋友可能会觉得它们功能相似都是用来“拦”请求的用哪个好像都差不多。但在我十多年的项目实战中无数次踩坑和调优的经历告诉我这俩兄弟虽然目标一致——保卫你的应用但它们的职责、能力和工作时机有着本质的区别。用错了地方轻则功能失效、性能低下重则可能引入安全漏洞让整个系统的防线形同虚设。简单来说你可以把过滤器想象成小区门口的保安门卫。他的工作范围很广所有想进出小区的人HTTP请求和响应都必须经过他。他可以检查你的健康码验证请求头、测量体温校验参数、或者拒绝一个形迹可疑的人入内拦截非法请求。他的权力很大能在请求真正进入你家即Spring容器、你的Controller之前就进行处理甚至能直接“遣返”返回响应。而拦截器则更像是进入你家楼道后的巡逻队或智能管家。他已经知道你是小区的合法住户请求已经通过了Servlet容器的初步过滤他的工作更精细专注于你在“家”里的行为比如记录你什么时候出门记录日志、在你进门前自动开灯预处理、或者在你离家后检查电器是否关闭后处理。他深度集成在Spring MVC的流程中能方便地获取Spring容器中的各种“家具”Bean。理解这两者的奥秘不是为了应付面试而是为了在构建健壮、安全、高效的应用时能做出最合适的技术选型。当你的应用面临恶意爬虫刷接口、需要统一鉴权、或者要对所有业务操作进行审计日志记录时你知道该派“保安”还是“管家”上场这就是核心价值所在。2. 核心原理深度拆解从Servlet到Spring MVC的请求之旅要彻底搞懂过滤器和拦截器我们必须把一次HTTP请求在Java Web应用中的完整生命周期摊开来看。这就像跟踪一个快递包裹从发货到签收的全过程每个环节都有不同的“工作人员”在处理。2.1 过滤器的定位与能力边界过滤器是Java EE现在是Jakarta EE规范定义的标准组件它的工作层级在Servlet容器如Tomcat、Jetty级别。这意味着它完全不依赖于Spring框架即使是一个最原始的Servlet应用你也可以使用过滤器。它的工作时机非常早当一个HTTP请求到达服务器时Servlet容器会首先创建一个ServletRequest和ServletResponse对象。紧接着容器就会查找所有配置好的过滤器并按顺序将它们组织成一个“过滤器链”。请求会像穿过一道道水闸一样依次经过每个过滤器。客户端请求 - Tomcat容器 - 过滤器1 - 过滤器2 - ... - 过滤器N - Servlet (DispatcherServlet) - 你的应用在这个过程中每个过滤器都拥有对原始ServletRequest和ServletResponse的完全控制权检查请求可以读取、修改甚至包装请求对象例如使用HttpServletRequestWrapper来增加参数。拦截请求如果认为请求非法如Token无效、IP黑名单可以直接调用response.sendError()或response.getWriter().write()返回响应请求就此终止根本不会到达后续的过滤器和Servlet。放行请求调用chain.doFilter(request, response)将请求传递给链中的下一个过滤器或最终的Servlet。处理响应当请求被后续组件处理完生成响应后响应会沿着过滤器链反向穿回。每个过滤器还有机会对响应内容进行修改如统一添加响应头、压缩响应体。关键特性总结作用范围广能过滤所有请求包括静态资源如.js,.css, 图片。与框架无关是Servlet规范的一部分不感知Spring。控制力强可以终止请求-响应周期。无法直接使用Spring Bean因为此时Spring的上下文可能还未完全初始化或无法直接注入。2.2 拦截器的定位与Spring集成优势拦截器是Spring MVC框架特有的组件。它的工作层级在Spring Web MVC框架内部具体是在核心控制器DispatcherServlet处理请求的过程中。它的工作时机相对靠后请求已经通过了Servlet容器的所有过滤器并已经被DispatcherServlet接收。DispatcherServlet会根据请求的URL找到对应的处理器Handler通常是我们的Controller方法但在执行这个处理器前后就是拦截器发挥作用的舞台。Spring MVC定义了一个清晰的处理器执行链其中包含了拦截器DispatcherServlet 收到请求 - 预处理拦截器 - 执行Controller方法 - 后处理拦截器 - 渲染视图 - 完成处理拦截器拦截器的主要方法preHandle在Controller方法执行前调用。返回true则继续执行链返回false则中断流程类似过滤器的拦截。postHandle在Controller方法执行后但视图渲染前调用。此时可以修改模型数据ModelAndView。afterCompletion在整个请求完成后调用主要用于资源清理、日志记录等。关键特性总结作用范围精准通常只针对Controller的请求映射可以通过配置排除静态资源。深度Spring集成本身就是Spring Bean可以方便地使用Autowired注入其他Spring管理的服务如数据库服务、日志服务。能获取处理器信息可以拿到即将执行的HandlerMethod对象从而知道是哪个Controller的哪个方法便于做更精细化的控制如基于注解的权限检查。无法处理静态资源默认不拦截静态资源请求。2.3 核心差异对照表为了更直观地对比我将两者的核心差异整理成下表特性维度过滤器拦截器规范/框架Servlet 规范 (javax.servlet.Filter)Spring MVC 框架 (org.springframework.web.servlet.HandlerInterceptor)作用范围所有请求包括静态资源通常只针对Spring MVC映射的请求可通过配置调整依赖关系不依赖Spring是Web容器组件强依赖Spring MVC框架获取Spring Bean无法直接注入需通过特殊方式可以直接注入本身就是Spring Bean执行时机在Servlet之前响应返回客户端之前在DispatcherServlet之后Controller方法执行前后控制粒度较粗基于URL模式较细可基于HandlerMethod具体方法典型应用场景全局编码设置、CORS处理、XSS防御、基础身份验证、请求/响应日志记录原始、压缩业务权限校验、审计日志需业务上下文、执行时间计算、统一异常处理、模型数据加工实操心得一个快速记忆法——“滤前拦后”。过滤器工作在更“前”的容器层像一道外网防火墙拦截器工作在更“后”的业务框架层像一套内网安全策略。选择时先问自己这个逻辑是否需要处理静态资源是否需要用到Spring的Bean是否需要知道具体是哪个Controller方法3. 实战构建手把手打造你的应用安全防线理论讲透了我们来点实际的。我将通过一个典型的Web应用安全需求场景展示如何分别使用过滤器和拦截器并解释为什么这么选。场景假设我们有一个Spring Boot 2.7.x的RESTful API项目需要实现以下安全与管控功能全局请求日志记录所有进入应用的请求的IP、URL、方法、时间以及耗时。用于监控和问题排查。接口鉴权对于/api/private/**路径下的私有API需要验证请求头中的X-Auth-Token是否有效。防重复提交对于某些关键写操作如支付下单需要防止用户在短时间内重复提交。3.1 使用过滤器实现全局请求日志与基础安全对于全局请求日志我们希望记录每一个请求包括对前端静态页面、图标等资源的请求。这要求组件必须在最外层工作且不关心具体业务逻辑。过滤器是完美选择。Component Order(1) // 定义过滤器执行顺序数字越小优先级越高 Slf4j public class GlobalLoggingFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req (HttpServletRequest) request; HttpServletResponse res (HttpServletResponse) response; long startTime System.currentTimeMillis(); String requestId UUID.randomUUID().toString(); // 生成唯一请求ID // 将请求ID放入MDC方便日志链路追踪 MDC.put(requestId, requestId); // 也可以将请求ID设置到响应头方便前端排查 res.setHeader(X-Request-ID, requestId); // 记录请求开始日志 log.info( 请求开始 [ID:{}] IP:{} {} {}?{}, requestId, getClientIp(req), req.getMethod(), req.getRequestURI(), req.getQueryString()); try { // 继续执行过滤器链 chain.doFilter(request, response); } finally { // 无论成功失败最终都会执行这里 long duration System.currentTimeMillis() - startTime; int status res.getStatus(); log.info( 请求结束 [ID:{}] 状态:{} 耗时:{}ms, requestId, status, duration); // 清除MDC中的请求ID MDC.remove(requestId); } } private String getClientIp(HttpServletRequest request) { // 一个简单的获取真实IP的方法实际生产环境需要考虑代理 String ip request.getHeader(X-Forwarded-For); if (ip null || ip.isEmpty() || unknown.equalsIgnoreCase(ip)) { ip request.getHeader(Proxy-Client-IP); } if (ip null || ip.isEmpty() || unknown.equalsIgnoreCase(ip)) { ip request.getHeader(WL-Proxy-Client-IP); } if (ip null || ip.isEmpty() || unknown.equalsIgnoreCase(ip)) { ip request.getRemoteAddr(); } return ip; } Override public void init(FilterConfig filterConfig) throws ServletException { log.info(全局日志过滤器初始化...); } Override public void destroy() { log.info(全局日志过滤器销毁...); } }为什么用过滤器记录全面chain.doFilter()包裹在try-finally中确保无论后续处理是成功、抛出异常还是被其他过滤器拦截都能记录到结束日志和耗时。性能影响小仅记录基本信息不涉及IO操作如写入数据库对性能影响微乎其微。作用于所有资源即使是/favicon.ico或/static/js/app.js这样的请求也会被记录这对于分析异常访问模式很有帮助。注意事项在过滤器中直接调用response.getWriter()并写入内容后务必谨慎调用chain.doFilter()否则可能导致响应体被重复写入。通常如果你已经在过滤器中生成了完整的响应如返回错误JSON就应该直接return不再放行。3.2 使用拦截器实现精细化的接口鉴权对于接口鉴权我们需要验证Token。这个逻辑需要查询数据库或缓存来验证Token有效性因此必须用到Spring管理的AuthServiceBean。同时我们可能只需要对特定的API路径进行鉴权。拦截器是最佳选择。首先定义一个自定义注解用于更灵活地标记需要鉴权的方法Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequireAuth { // 可以扩展权限角色如 String[] roles() default {}; }然后实现我们的鉴权拦截器Component public class AuthenticationInterceptor implements HandlerInterceptor { Autowired private AuthService authService; // 依赖Spring Bean Autowired private ObjectMapper objectMapper; // Jackson用于生成JSON响应 Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 1. 检查是否为HandlerMethod排除资源处理器等 if (!(handler instanceof HandlerMethod)) { return true; } HandlerMethod handlerMethod (HandlerMethod) handler; Method method handlerMethod.getMethod(); // 2. 检查控制器类或方法上是否有RequireAuth注解 boolean requireAuthOnMethod method.isAnnotationPresent(RequireAuth.class); boolean requireAuthOnClass method.getDeclaringClass().isAnnotationPresent(RequireAuth.class); if (!requireAuthOnMethod !requireAuthOnClass) { // 不需要鉴权直接放行 return true; } // 3. 需要鉴权从请求头获取Token String token request.getHeader(X-Auth-Token); if (token null || token.isBlank()) { sendErrorResponse(response, 401, 未提供认证令牌); return false; // 中断执行链 } // 4. 验证Token调用Spring Bean服务 UserInfo userInfo authService.validateToken(token); if (userInfo null) { sendErrorResponse(response, 403, 令牌无效或已过期); return false; } // 5. 鉴权通过将用户信息存入请求属性供Controller使用 request.setAttribute(CURRENT_USER, userInfo); return true; } private void sendErrorResponse(HttpServletResponse response, int status, String message) throws IOException { response.setStatus(status); response.setContentType(application/json;charsetUTF-8); MapString, Object result new HashMap(); result.put(code, status); result.put(message, message); result.put(timestamp, System.currentTimeMillis()); response.getWriter().write(objectMapper.writeValueAsString(result)); } // postHandle和afterCompletion可以根据需要实现例如记录操作日志 }最后通过配置类注册拦截器并指定拦截路径Configuration public class WebMvcConfig implements WebMvcConfigurer { Autowired private AuthenticationInterceptor authenticationInterceptor; Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(authenticationInterceptor) .addPathPatterns(/api/**) // 拦截所有/api下的请求 .excludePathPatterns(/api/public/**, /error); // 排除公开API和错误端点 } }为什么用拦截器依赖注入可以方便地使用Autowired注入AuthService和ObjectMapper这是过滤器难以做到的需要额外 hack。精细控制通过判断HandlerMethod和自定义注解可以精确控制哪些方法需要鉴权哪些不需要避免了在过滤器中写一堆if-else判断URL。信息丰富能获取到即将执行的具体方法信息为后续的审计日志记录“谁”在“什么时候”调用了“哪个方法”提供了极大便利。3.3 混合使用防重复提交的进阶方案防重复提交是一个经典问题。一个健壮的方案往往需要过滤器和拦截器协作。思路过滤器负责生成唯一请求标识在请求最早进入时生成一个唯一键如userId:接口路径:请求参数摘要这个键需要能唯一标识“同一个用户的同一笔操作”。拦截器或AOP负责业务逻辑判断在请求进入业务方法前用这个唯一键去分布式缓存如Redis中尝试设置一个带有短暂过期时间的锁。如果设置成功表示第一次提交则放行如果设置失败表示重复提交则直接返回错误。过滤器部分生成标识Component Order(2) // 在日志过滤器之后执行 public class IdempotencyKeyFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req (HttpServletRequest) request; // 可以从Header中获取客户端生成的幂等键如果没有则自己生成一个 String idempotencyKey req.getHeader(X-Idempotency-Key); if (idempotencyKey null || idempotencyKey.isEmpty()) { // 简单示例使用UUID。生产环境可能需要更复杂的规则结合用户和请求特征 idempotencyKey gen_ UUID.randomUUID().toString(); } // 将幂等键存入请求属性供后续组件使用 req.setAttribute(IDEMPOTENCY_KEY, idempotencyKey); chain.doFilter(request, response); } }拦截器部分检查幂等性Component public class IdempotencyInterceptor implements HandlerInterceptor { Autowired private RedisTemplateString, String redisTemplate; // 使用Redis Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 只对标注了Idempotent的方法进行检查 if (handler instanceof HandlerMethod) { HandlerMethod hm (HandlerMethod) handler; if (!hm.hasMethodAnnotation(Idempotent.class)) { return true; } String idempotencyKey (String) request.getAttribute(IDEMPOTENCY_KEY); if (idempotencyKey null) { sendErrorResponse(response, 400, 缺少幂等键); return false; } // 尝试在Redis中设置键过期时间设为10秒 Boolean success redisTemplate.opsForValue().setIfAbsent(idempotent: idempotencyKey, processing, 10, TimeUnit.SECONDS); if (Boolean.FALSE.equals(success)) { // 键已存在说明是重复请求 sendErrorResponse(response, 409, 请求正在处理或请勿重复提交); return false; } } return true; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception { // 请求处理完成后可以根据业务成功与否决定是删除键还是更新状态 // 例如只有业务成功时才删除失败则保留键让客户端重试 if (handler instanceof HandlerMethod) { HandlerMethod hm (HandlerMethod) handler; if (hm.hasMethodAnnotation(Idempotent.class)) { String idempotencyKey (String) request.getAttribute(IDEMPOTENCY_KEY); if (idempotencyKey ! null response.getStatus() 200) { // 业务成功删除锁允许相同的幂等键发起新的业务请求非重试 redisTemplate.delete(idempotent: idempotencyKey); } } } } // ... sendErrorResponse 方法同上 }这种协作模式的优势职责分离过滤器做通用的、与业务无关的“标识生成”工作。拦截器做与业务注解相关的“逻辑判断”工作。灵活性强可以通过注解轻松控制哪些接口需要防重哪些不需要。性能与一致性利用Redis等外部存储可以很好地支持分布式环境下的防重提交。4. 进阶应用与性能调优实战掌握了基本用法我们来看看在复杂和高并发场景下如何用好过滤器和拦截器并规避其中的陷阱。4.1 过滤器链的优化与陷阱当配置了多个过滤器时它们的执行顺序由Order注解或web.xml中的配置顺序决定。顺序至关重要。一个常见的性能陷阱日志过滤器放在鉴权过滤器之后假设你有两个过滤器AuthFilter鉴权和LoggingFilter日志。如果LoggingFilter先执行它会记录所有请求的开始。但当请求被AuthFilter拦截并返回401错误时LoggingFilter的finally块仍然会记录“请求结束”。这看起来没问题。 但如果顺序反过来AuthFilter先执行它拦截了非法请求并直接返回响应请求根本不会到达LoggingFilter。这会导致你的访问日志缺失这部分非法请求记录对于安全审计来说是致命的。因此日志过滤器的顺序应尽可能靠前。最佳实践建议安全第一像CorsFilter处理跨域这种必须最早响应的过滤器应设为最高优先级Order(Ordered.HIGHEST_PRECEDENCE)。日志紧随其后全局日志过滤器应放在安全过滤器之后其他业务过滤器之前确保记录所有“到达”的请求。资源处理靠前如CharacterEncodingFilter设置编码应在请求体被读取之前生效。业务鉴权居中像AuthenticationFilter这类业务过滤器放在编码、日志之后。内容处理靠后如GzipFilter响应压缩应放在最后因为它需要处理最终的响应体。使用OncePerRequestFilter Spring提供了一个便利的抽象类OncePerRequestFilter。它确保在单个请求生命周期内doFilterInternal方法只被执行一次。这在转发RequestDispatcher.forward或包含include等场景下非常有用可以避免过滤器被重复执行。强烈建议继承它来实现自定义过滤器。Component public class MySafeFilter extends OncePerRequestFilter { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { // 你的过滤逻辑 // 这个方法保证只被调用一次 filterChain.doFilter(request, response); } }4.2 拦截器与Spring Boot Actuator的冲突处理Spring Boot Actuator提供了很多监控端点如/actuator/health,/actuator/metrics。如果你配置的拦截器路径是/**那么这些端点也会被拦截可能导致健康检查失败或监控数据异常。解决方案在注册拦截器时明确排除Actuator端点。Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(myInterceptor) .addPathPatterns(/**) .excludePathPatterns( /actuator/**, /error, /swagger-resources/**, /swagger-ui/**, /v3/api-docs/** ); }4.3 异步请求下的特殊考量在Spring MVC中当控制器方法返回DeferredResult、Callable或使用ResponseBody配合异步Servlet时请求的处理是异步的。这对拦截器的生命周期有影响。preHandle在异步线程开始时执行。postHandle对于异步请求postHandle会立即被调用此时异步处理还未完成并且传入的ModelAndView为null。这意味着你不能在postHandle中修改异步处理的结果。afterCompletion在异步请求处理完成后调用无论是超时、正常完成还是出错。因此资源清理和最终日志记录必须放在afterCompletion中。异步场景下的日志记录示例Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { long startTime (Long) request.getAttribute(startTime); long endTime System.currentTimeMillis(); log.info(异步请求最终完成总耗时{}ms, endTime - startTime); // 清理ThreadLocal等资源 MyThreadLocalContext.clear(); }你需要将startTime在preHandle中存入request属性。4.4 与Spring Security的协作与区分这是一个高频困惑点。Spring Security本身就是一个基于过滤器链的强大安全框架。当你同时使用自定义过滤器和Spring Security时你需要清楚它们的位置关系。Spring Security的过滤器链FilterChainProxy通常作为一个单独的过滤器插入到整个过滤器链中。你的自定义过滤器可能在它之前或之后执行这取决于你的配置Order。基本原则在Security之前的过滤器可以处理一些Security不关心的、更通用的逻辑如全局日志、编码。但无法获取Security认证信息因为此时用户尚未被认证。在Security之后的过滤器可以获取到SecurityContext中的认证信息如用户名、角色。但需注意如果请求被Security拦截如未登录则不会到达后面的过滤器。更常见的做法是使用Spring Security提供的扩展点而不是自己写过滤器去干涉安全流程。例如实现AuthenticationSuccessHandler认证成功处理或AccessDeniedHandler权限拒绝处理。对于需要在安全上下文中执行的逻辑使用拦截器是更自然的选择因为它肯定在Spring Security过滤器之后执行。5. 生产环境排坑指南与性能考量在实际项目中我遇到过不少由过滤器和拦截器引发的问题。这里分享几个典型案例和解决方案。5.1 问题一过滤器内读取了请求体导致Controller中RequestBody为空现象在过滤器中通过request.getInputStream()读取了请求体例如为了做签名验证然后调用chain.doFilter()。结果后面的Controller方法中RequestBody注解绑定的参数始终为null。根因Servlet的InputStream和Reader通常只能被读取一次。过滤器读取后流就到了末尾后续的Spring消息转换器如MappingJackson2HttpMessageConverter再读就是空。解决方案使用ContentCachingRequestWrapperSpring提供这个包装类可以将请求体缓存起来允许多次读取。但注意它需要先将整个请求体读入内存对大文件上传不友好。public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req (HttpServletRequest) request; ContentCachingRequestWrapper wrappedRequest new ContentCachingRequestWrapper(req); // 在wrappedRequest上读取body byte[] body wrappedRequest.getContentAsByteArray(); // 第一次读取会触发缓存 // ... 你的逻辑 chain.doFilter(wrappedRequest, response); // 传递包装后的请求 }自定义HttpServletRequestWrapper更灵活的方式是自己实现一个Wrapper将读取的请求体内容保存下来并重写getInputStream()和getReader()方法返回缓存内容的新流。这是很多开源库的做法。改变架构如果只是为了获取几个参数做验证考虑将签名信息放在Header中而不是Body里。或者使用拦截器在Spring MVC层面通过RequestBody的参数解析器处理后的对象进行操作。5.2 问题二拦截器preHandle中抛出的异常无法被ControllerAdvice统一异常处理器捕获现象在拦截器的preHandle方法中如果参数校验不通过直接抛出RuntimeException期望被全局的ControllerAdvice ExceptionHandler处理并返回统一的错误JSON但实际返回的是Tomcat默认的500错误页面。根因ControllerAdvice是Spring MVC的组件它只处理控制器方法执行过程中以及视图渲染过程中抛出的异常。拦截器的preHandle执行时尚未进入控制器方法执行流程因此其抛出的异常由Servlet容器Tomcat处理而非Spring MVC。解决方案在拦截器内部处理异常并生成响应推荐就像我们前面鉴权拦截器示例中的sendErrorResponse方法一样在preHandle里捕获异常或判断失败后直接操作HttpServletResponse返回JSON错误信息然后返回false。Override public boolean preHandle(...) { try { // 校验逻辑 if (!valid) { writeJsonResponse(response, 400, 参数无效); return false; } } catch (Exception e) { writeJsonResponse(response, 500, 系统内部错误); return false; } return true; }配置Servlet容器的错误页面在application.yml中配置将特定状态码或异常类型映射到某个Controller路径由Spring MVC来处理。但这相对繁琐且不够灵活。5.3 问题三过滤器和拦截器中的性能瓶颈潜在瓶颈同步阻塞操作在doFilter或preHandle中执行耗时的IO操作如远程调用、复杂数据库查询会阻塞整个请求线程。内存泄漏在过滤器或拦截器中使用了ThreadLocal但在请求结束后没有及时清理remove在线程池复用的环境下会导致内存泄漏和信息错乱。频繁的序列化/反序列化如为了日志或验证在过滤器中反复将请求/响应体转换成字符串。优化建议异步处理对于非关键性的、耗时的操作如发送审计日志到消息队列考虑使用异步方式。在过滤器中可以将任务提交给一个线程池避免阻塞主链。但要注意异步上下文传递如RequestContextHolder。资源及时清理在finally块或拦截器的afterCompletion方法中务必清理ThreadLocal、关闭临时流等资源。采样记录全量日志记录对性能有影响。在高并发场景下可以考虑采样记录例如只记录1%的请求或者只记录慢请求耗时超过阈值的。避免重复解析如果多个组件都需要请求体信息考虑使用ContentCachingRequestWrapper并只解析一次将解析结果如Map存入请求属性供后续使用。5.4 配置检查清单在将应用部署上线前建议对照此清单检查你的过滤器和拦截器配置[ ]执行顺序关键过滤器如CORS、日志、编码的顺序是否正确Order值是否合理[ ]路径匹配拦截器的addPathPatterns和excludePathPatterns是否准确覆盖了目标接口并排除了静态资源、Actuator端点、Swagger文档等[ ]异步支持如果项目使用异步Servlet拦截器中的资源清理是否放在了afterCompletion中ThreadLocal是否被正确清理[ ]异常处理拦截器preHandle中的失败场景是否已妥善处理并返回了友好的客户端响应[ ]性能影响是否在过滤/拦截链中引入了不必要的同步阻塞调用全量日志是否会对高并发接口造成压力[ ]安全审查用于鉴权的过滤器/拦截器其逻辑是否存在绕过漏洞Token验证是否防重放防重复提交的键生成算法是否足够唯一[ ]测试覆盖是否编写了单元测试和集成测试覆盖了正常流程、鉴权失败、重复提交、异常抛出等场景纸上得来终觉浅绝知此事要躬行。过滤器和拦截器是构建稳固Web应用的基石组件它们的正确使用直接关系到系统的安全性、可观测性和可维护性。我个人的经验是在项目初期就规划好它们的职责边界通过一个清晰的配置类来管理顺序和路径并为之编写充分的测试用例。当出现一个横切关注点时先问“这个逻辑需要看到Spring的世界吗”是则选拦截器再问“这个逻辑需要处理所有流量包括静态文件吗”是则选过滤器大多数时候你都能找到清晰的答案。记住没有最好的组件只有最合适的场景。
)
