1. 项目概述为什么我们需要拦截器在Web开发中尤其是基于SpringMVC框架构建应用时我们经常会遇到一些横切关注点。比如用户登录状态的校验、接口访问权限的检查、请求日志的记录、全局异常的处理或者是对请求参数进行统一的预处理。这些功能往往需要在多个控制器方法执行前后被调用如果我们在每个方法里都写一遍校验逻辑代码会变得极其臃肿、难以维护并且违背了“不要重复自己”的原则。SpringMVC的拦截器Interceptor就是为了解决这类问题而生的。它提供了一种机制允许你在请求到达控制器Controller之前、控制器处理之后以及视图渲染之后这三个关键节点插入自定义的处理逻辑。你可以把它想象成一道关卡所有进入你应用核心区域的请求都必须先经过这道关卡的检查。这道关卡可以检查“通行证”权限记录“访客信息”日志甚至对“访客”进行简单的“安检”参数校验。与大家熟知的过滤器Filter不同拦截器是Spring框架的一部分它能深度融入Spring的上下文轻松获取Spring容器中管理的Bean例如Service或组件。而过滤器是Servlet规范的一部分更底层对请求和响应的处理更彻底但无法直接使用Spring的依赖注入等功能。简单来说过滤器像是小区大门保安拦截器则是你家门口的智能门锁后者更了解你家里的情况Spring上下文。接下来我将结合自己多年的项目经验从设计思路、核心实现到避坑指南为你彻底拆解SpringMVC拦截器让你不仅能理解其原理更能得心应手地应用到实际项目中。2. 拦截器核心设计与思路拆解2.1 拦截器的工作原理与生命周期要玩转拦截器首先得搞清楚它的工作流程。SpringMVC拦截器的核心接口是HandlerInterceptor它定义了三个关键方法对应了请求处理流程的三个拦截点preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)在控制器方法执行之前被调用。这是最常用、最强大的拦截点。返回值是布尔类型booleantrue放行请求会继续向下执行到达下一个拦截器或最终的控制器方法。false中断请求处理流程到此为止后续的拦截器和控制器方法都不会再执行。通常你需要在这里通过response对象返回错误信息如JSON或重定向到登录页。postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView)在控制器方法执行之后、视图渲染之前被调用。此时控制器方法已经执行完毕你可以对返回的ModelAndView对象进行操作比如向模型Model中添加一些所有视图都需要的公共数据如当前用户信息、站点配置等。注意如果控制器方法通过ResponseBody直接返回了数据如JSON没有走视图解析流程那么modelAndView参数可能为null这个方法也可能不会被执行取决于配置和异常情况。afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex)在整个请求处理完毕之后被调用也就是视图渲染结束之后或者发生异常导致流程结束之后。这个方法是进行资源清理、记录最终请求日志包括处理耗时、结果状态的理想场所。无论请求过程中是否发生异常这个方法都会被调用除非preHandle返回了false。ex参数包含了处理过程中抛出的异常如果无异常则为null。这三个方法构成了一个拦截器的完整生命周期。理解这个顺序至关重要它决定了你的逻辑应该写在哪个方法里。2.2 多拦截器执行链与配置策略在实际项目中我们很少只用一个拦截器。更常见的场景是配置一个拦截器链Interceptor Chain。例如一个典型的链可能包含日志记录拦截器 - 登录验证拦截器 - 权限校验拦截器 - 防重复提交拦截器。执行顺序遵循“先进后出”的栈式规则preHandle按配置顺序正序执行。即配置在前的拦截器的preHandle先执行。postHandle按配置顺序逆序执行。即配置在后的拦截器的postHandle先执行。afterCompletion按配置顺序逆序执行。同样配置在后的拦截器的afterCompletion先执行。这个规则保证了逻辑上的嵌套性。例如日志拦截器最先开始记录preHandle也最后结束记录afterCompletion这样它就能记录下整个链路的完整耗时。配置拦截器链时需要仔细规划每个拦截器的职责和顺序。一个基本原则是范围越广、越基础的拦截器应该放在越前面。比如日志拦截器应该最先执行因为它不依赖任何业务状态。而权限校验拦截器应该放在登录校验之后因为只有确认用户身份后才能判断其权限。3. 核心细节解析与实操要点3.1 自定义拦截器实现详解实现一个自定义拦截器非常简单只需要创建一个类并实现HandlerInterceptor接口或者更常见的是继承HandlerInterceptorAdapter类Spring 5.3之前或直接实现HandlerInterceptor接口并重写所需方法Spring 5.3后HandlerInterceptorAdapter已被标记为过时。下面我们以实现一个简单的“接口访问计时拦截器”为例展示完整代码和细节。package com.example.demo.interceptor; import lombok.extern.slf4j.Slf4j; import org.springframework.stereotype.Component; import org.springframework.web.servlet.HandlerInterceptor; import org.springframework.web.servlet.ModelAndView; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; /** * 接口性能监控拦截器 * 1. 记录请求进入和结束时间计算耗时。 * 2. 记录请求URL、方法、客户端IP等信息。 */ Component // 声明为Spring组件方便被扫描和管理 Slf4j // 使用Lombok注解简化日志声明 public class PerformanceInterceptor implements HandlerInterceptor { // 使用ThreadLocal来保存每个线程独有的开始时间避免多线程并发问题 private static final ThreadLocalLong startTimeThreadLocal new ThreadLocal(); Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 记录请求开始时间 long startTime System.currentTimeMillis(); startTimeThreadLocal.set(startTime); // 记录请求基本信息到DEBUG级别日志 if (log.isDebugEnabled()) { String requestURI request.getRequestURI(); String method request.getMethod(); String clientIp getClientIp(request); log.debug([PerformanceInterceptor] 请求开始 URI: {}, Method: {}, ClientIP: {}, requestURI, method, clientIp); } // 始终放行因为我们只是做监控 return true; } Override public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception { // 在这个例子中postHandle我们不需要做特殊处理。 // 如果需要在渲染视图前添加公共模型数据可以在这里操作modelAndView。 // 例如modelAndView.addObject(currentUser, userService.getCurrentUser()); } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception { // 获取并移除当前线程的开始时间 Long startTime startTimeThreadLocal.get(); startTimeThreadLocal.remove(); // 关键必须清理防止内存泄漏 if (startTime ! null) { long endTime System.currentTimeMillis(); long duration endTime - startTime; String requestURI request.getRequestURI(); int status response.getStatus(); // 根据耗时决定日志级别 if (duration 1000) { log.warn([PerformanceInterceptor] 慢接口警告耗时: {}ms, URI: {}, Status: {}, duration, requestURI, status); } else if (duration 300) { log.info([PerformanceInterceptor] 接口耗时: {}ms, URI: {}, Status: {}, duration, requestURI, status); } else { log.debug([PerformanceInterceptor] 接口耗时: {}ms, URI: {}, Status: {}, duration, requestURI, status); } // 如果请求处理过程中发生了异常在这里也能捕获到ex不为null if (ex ! null) { log.error([PerformanceInterceptor] 请求处理异常: URI{}, Error{}, requestURI, ex.getMessage(), ex); } } } /** * 获取客户端真实IP地址处理代理情况 * 这是一个常见的工具方法在拦截器中很有用。 */ private String getClientIp(HttpServletRequest request) { String ip request.getHeader(X-Forwarded-For); if (ip null || ip.length() 0 || unknown.equalsIgnoreCase(ip)) { ip request.getHeader(Proxy-Client-IP); } if (ip null || ip.length() 0 || unknown.equalsIgnoreCase(ip)) { ip request.getHeader(WL-Proxy-Client-IP); } if (ip null || ip.length() 0 || unknown.equalsIgnoreCase(ip)) { ip request.getHeader(HTTP_CLIENT_IP); } if (ip null || ip.length() 0 || unknown.equalsIgnoreCase(ip)) { ip request.getHeader(HTTP_X_FORWARDED_FOR); } if (ip null || ip.length() 0 || unknown.equalsIgnoreCase(ip)) { ip request.getRemoteAddr(); } // 对于通过多个代理的情况第一个IP为客户端真实IP if (ip ! null ip.contains(,)) { ip ip.substring(0, ip.indexOf(,)).trim(); } return ip; } }关键点解析与注意事项ThreadLocal的使用由于Web服务器如Tomcat使用线程池处理请求同一个线程可能会被多个请求复用。我们必须使用ThreadLocal来保存每个请求独有的开始时间否则数据会错乱。切记在afterCompletion中一定要调用ThreadLocal.remove()来清理数据这是防止内存泄漏的黄金法则。日志级别分级根据耗时动态调整日志级别WARN, INFO, DEBUG这样可以在生产环境中快速发现性能瓶颈而不会让日志文件被正常请求淹没。ex参数的处理afterCompletion中的ex是控制器或后续拦截器抛出的异常。即使全局异常处理器ControllerAdviceExceptionHandler已经处理了异常并返回了友好错误信息这个ex依然不为空。这里是记录未捕获异常原始堆栈的理想位置。postHandle的局限性对于返回JSON的REST APIpostHandle可能不会被执行或者modelAndView为null。因此不要将必须在请求结束后执行的逻辑如最终日志记录放在这里而应放在afterCompletion中。3.2 拦截器配置的两种方式XML vs Java Config定义了拦截器后需要将其注册到SpringMVC的拦截器链中。现代Spring Boot项目基本都采用基于Java的配置方式但了解XML配置有助于理解原理。方式一XML配置传统方式在springmvc-servlet.xml中配置mvc:interceptors !-- 配置一个全局拦截器拦截所有请求 -- bean classcom.example.demo.interceptor.PerformanceInterceptor/ !-- 配置更精细化的拦截器指定路径 -- mvc:interceptor mvc:mapping path/api/**/ !-- 拦截的路径 -- mvc:exclude-mapping path/api/public/**/ !-- 排除的路径 -- bean classcom.example.demo.interceptor.AuthInterceptor/ /mvc:interceptor /mvc:interceptors方式二Java Config配置推荐方式在Spring Boot项目中我们通常创建一个配置类来实现WebMvcConfigurer接口并重写addInterceptors方法。package com.example.demo.config; import com.example.demo.interceptor.AuthInterceptor; import com.example.demo.interceptor.PerformanceInterceptor; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.context.annotation.Configuration; import org.springframework.web.servlet.config.annotation.InterceptorRegistry; import org.springframework.web.servlet.config.annotation.WebMvcConfigurer; Configuration public class WebMvcConfig implements WebMvcConfigurer { // 自动注入我们定义的拦截器Bean Autowired private PerformanceInterceptor performanceInterceptor; Autowired private AuthInterceptor authInterceptor; Override public void addInterceptors(InterceptorRegistry registry) { // 1. 性能监控拦截器拦截所有请求但排除一些静态资源或特定端点 registry.addInterceptor(performanceInterceptor) .addPathPatterns(/**) // 拦截所有路径 .excludePathPatterns(/css/**, /js/**, /images/**, /webjars/**, /error); // 排除静态资源和错误页 // 2. 权限认证拦截器只拦截/api下的请求且排除登录/注册等公开接口 registry.addInterceptor(authInterceptor) .addPathPatterns(/api/**) .excludePathPatterns(/api/login, /api/register, /api/public/**); // 拦截器的添加顺序就是它们的执行顺序preHandle顺序 // 这里performanceInterceptor会先于authInterceptor执行 } }配置心得路径模式语法addPathPatterns和excludePathPatterns支持Ant风格路径模式如/**所有路径、/api/*一级路径、/api/**所有子路径。顺序即优先级在addInterceptors方法中调用registry.addInterceptor()的顺序决定了拦截器链的执行顺序。通常把最基础、最通用的拦截器如日志、性能监控放在前面添加。谨慎使用/**对全局拦截器一定要通过excludePathPatterns排除掉对静态资源、Swagger文档、健康检查端点如/actuator/health的拦截否则会影响前端资源加载或监控系统。4. 实操过程与核心环节实现4.1 实战构建一个登录状态校验拦截器让我们实现一个最常用的拦截器——登录校验。它检查Session或Token中是否存在有效的用户信息如果未登录则返回统一的JSON错误或重定向。步骤1定义拦截器package com.example.demo.interceptor; import com.example.demo.common.ApiResponse; import com.example.demo.common.Constant; import com.example.demo.util.JwtUtil; import com.fasterxml.jackson.databind.ObjectMapper; import lombok.extern.slf4j.Slf4j; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Component; import org.springframework.web.servlet.HandlerInterceptor; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import java.io.PrintWriter; Component Slf4j public class LoginInterceptor implements HandlerInterceptor { Autowired private JwtUtil jwtUtil; // 假设我们使用JWT进行无状态认证 Autowired private ObjectMapper objectMapper; // Jackson的ObjectMapper用于序列化JSON Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 1. 从请求头中获取Token常见做法Authorization: Bearer token String authHeader request.getHeader(Authorization); if (authHeader null || !authHeader.startsWith(Bearer )) { // 2. 如果没有Token检查Session传统有状态登录备用方案 Object user request.getSession().getAttribute(Constant.SESSION_USER_KEY); if (user null) { // 3. 两种方式都未通过判定为未登录 return sendUnauthorizedResponse(response, 请先登录); } // Session验证通过将用户信息放入请求属性供后续控制器使用 request.setAttribute(Constant.REQUEST_USER_KEY, user); return true; } // 4. 有Token进行JWT验证 String token authHeader.substring(7); // 去掉Bearer 前缀 try { String userId jwtUtil.validateTokenAndGetUserId(token); // 验证成功可以将用户ID或用户对象存入请求属性 request.setAttribute(Constant.REQUEST_USER_ID_KEY, userId); // 通常这里还会从数据库查询完整的用户信息这里简化为只存ID return true; } catch (Exception e) { log.warn(Token验证失败: {}, URI: {}, e.getMessage(), request.getRequestURI()); return sendUnauthorizedResponse(response, 登录已过期或无效请重新登录); } } /** * 统一返回未认证的JSON响应 */ private boolean sendUnauthorizedResponse(HttpServletResponse response, String message) throws Exception { response.setContentType(application/json;charsetutf-8); response.setStatus(HttpServletResponse.SC_UNAUTHORIZED); // 401状态码 ApiResponseString apiResponse ApiResponse.unauthorized(message); String json objectMapper.writeValueAsString(apiResponse); PrintWriter out response.getWriter(); out.write(json); out.flush(); // 返回false中断后续执行 return false; } }步骤2配置拦截器接上面的WebMvcConfigOverride public void addInterceptors(InterceptorRegistry registry) { // ... 其他拦截器配置 // 登录拦截器 registry.addInterceptor(loginInterceptor) .addPathPatterns(/api/**) .excludePathPatterns(/api/login, /api/register, /api/refresh-token); // 排除登录、注册、刷新Token接口 }步骤3在控制器中获取用户信息拦截器验证通过后将用户ID存入了请求属性request.setAttribute。在控制器中你可以通过RequestAttribute注解方便地获取。RestController RequestMapping(/api/user) public class UserController { GetMapping(/profile) public ApiResponseUserProfile getProfile(RequestAttribute(Constant.REQUEST_USER_ID_KEY) String userId) { // 直接使用拦截器注入的userId UserProfile profile userService.getProfileById(userId); return ApiResponse.success(profile); } }提示使用RequestAttribute比从HttpServletRequest对象中手动getAttribute更优雅也更容易进行单元测试。4.2 进阶实现一个防重复提交拦截器防止用户短时间内重复提交表单如订单提交是一个常见需求。我们可以利用拦截器配合Redis实现一个简单的防重机制。核心思路为每个需要防重的请求生成一个唯一标识如用户ID:接口路径:参数摘要在preHandle中检查Redis中该标识是否存在。如果存在说明正在处理或刚处理完返回“请勿重复提交”如果不存在则将该标识存入Redis并设置一个短暂的过期时间如3秒。在afterCompletion中可以选择删除或等待其自动过期。Component Slf4j public class IdempotentInterceptor implements HandlerInterceptor { Autowired private RedisTemplateString, String redisTemplate; Autowired private ObjectMapper objectMapper; private static final String KEY_PREFIX idempotent:; private static final long EXPIRE_SECONDS 3L; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 1. 只对POST、PUT、DELETE等写操作进行防重根据需求调整 String method request.getMethod(); if (!POST.equalsIgnoreCase(method) !PUT.equalsIgnoreCase(method) !DELETE.equalsIgnoreCase(method)) { return true; } // 2. 生成请求唯一标识 // 方案A使用前端传来的唯一Token如页面加载时生成 String clientToken request.getHeader(X-Idempotent-Token); // 方案B根据请求内容生成简单示例URI用户参数MD5 String userId (String) request.getAttribute(Constant.REQUEST_USER_ID_KEY); // 依赖登录拦截器 String requestURI request.getRequestURI(); String paramHash generateParamHash(request); // 需要实现的方法生成参数摘要 String cacheKey KEY_PREFIX userId : requestURI : paramHash; if (clientToken ! null) { cacheKey KEY_PREFIX clientToken; } // 3. 检查Redis Boolean isAbsent redisTemplate.opsForValue().setIfAbsent(cacheKey, processing, Duration.ofSeconds(EXPIRE_SECONDS)); if (isAbsent ! null !isAbsent) { // Key已存在说明是重复请求 log.warn(检测到重复提交: key{}, URI{}, cacheKey, requestURI); sendErrorResponse(response, 操作过于频繁请稍后再试); return false; } // 4. 将key存入请求属性以便在afterCompletion中处理 request.setAttribute(idempotentKey, cacheKey); return true; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception { // 请求处理完毕可以根据业务需求决定是否立即删除key // 例如只有成功处理状态码2xx时才删除让失败或异常的请求在key过期前无法重复提交 String cacheKey (String) request.getAttribute(idempotentKey); if (cacheKey ! null response.getStatus() 200 response.getStatus() 300) { // 成功处理可以立即删除key释放资源 redisTemplate.delete(cacheKey); log.debug(防重键已删除: {}, cacheKey); } // 如果处理失败key会等待自动过期在此期间阻止重复提交 } private String generateParamHash(HttpServletRequest request) throws Exception { // 简化示例将参数Map排序后转JSON字符串再取MD5 // 注意对于文件上传请求此方法不适用需要特殊处理 MapString, String[] paramMap request.getParameterMap(); SortedMapString, String[] sortedMap new TreeMap(paramMap); String paramString objectMapper.writeValueAsString(sortedMap); return DigestUtils.md5DigestAsHex(paramString.getBytes(StandardCharsets.UTF_8)); } private void sendErrorResponse(HttpServletResponse response, String message) throws Exception { response.setContentType(application/json;charsetutf-8); response.setStatus(HttpServletResponse.SC_TOO_MANY_REQUESTS); // 429状态码更贴切 ApiResponseString apiResponse ApiResponse.fail(message); String json objectMapper.writeValueAsString(apiResponse); PrintWriter out response.getWriter(); out.write(json); out.flush(); } }实操心得防重粒度这个示例的防重粒度较细用户接口参数。你也可以根据业务调整比如只针对“用户接口”进行防重这样同一用户对同一接口的连续调用会被阻止。Key的设计Key的设计至关重要要平衡唯一性和性能。太复杂如包含整个请求体的Key生成耗时太简单如只用户ID则防重效果不佳。过期时间过期时间EXPIRE_SECONDS需要根据接口的实际处理时间来设定通常略大于平均处理时间即可比如3-5秒。与业务结合对于创建订单等核心业务除了拦截器层面的防重业务层必须做幂等性保证如数据库唯一索引、状态机校验拦截器只是第一道防线。5. 常见问题与排查技巧实录即使理解了原理在实际使用拦截器时还是会踩到各种各样的坑。下面我整理了几个最常见的问题和排查思路。5.1 拦截器不生效检查这五点这是新手最常遇到的问题拦截器配置好了但请求好像直接“绕过”了它。检查配置类是否被扫描到确保你的WebMvcConfig配置类在Spring Boot的主应用类SpringBootApplication标注的类的包或其子包下。如果不在需要使用ComponentScan手动指定包路径。检查路径模式是否正确仔细核对addPathPatterns和excludePathPatterns。一个常见的错误是使用/api/*去匹配/api/v1/user这不会匹配应该用/api/**。使用/**时务必排除静态资源路径。检查拦截器Bean是否被Spring管理你的拦截器类上必须添加Component或Service等注解或者通过Bean方法在配置类中显式声明。否则在WebMvcConfig中Autowired注入会失败。检查是否有其他WebMvcConfigurer覆盖了配置如果你的项目中有多个类实现了WebMvcConfigurer并且都重写了addInterceptors方法只有最后一个被加载的配置会生效取决于Order注解或Bean定义顺序。建议将所有拦截器配置集中在一个WebMvcConfigurer中。检查是否使用了EnableWebMvc在Spring Boot项目中通常不需要自己添加EnableWebMvc注解。加上它会全面接管Spring Boot的默认MVC配置导致自动配置的静态资源处理、默认拦截器等失效。如果非加不可你需要自己完整配置所有MVC需要的组件。5.2 拦截器内Autowired注入为null在拦截器里使用Autowired注入Service或工具类有时会发现它是null。根本原因拦截器是在Spring MVC上下文初始化的早期就被实例化的有时会早于某些Bean的初始化。更关键的是如果你在配置类中通过new关键字创建拦截器实例如registry.addInterceptor(new MyInterceptor())那么这个拦截器对象完全是由你new出来的不是Spring容器管理的其内部的Autowired注解自然失效。解决方案确保拦截器本身是Spring Bean在拦截器类上添加Component。通过自动注入获取拦截器Bean在配置类中使用Autowired注入拦截器而不是new。// 正确做法 Autowired private MyInterceptor myInterceptor; Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(myInterceptor); // 注入的是Spring Bean }如果必须new实现WebMvcConfigurer的另一种方式让配置类实现WebMvcConfigurer接口Spring会自动将其识别为配置并注入依赖。5.3 拦截器与过滤器、ControllerAdvice的执行顺序理解这几个组件的执行顺序对调试问题非常重要。一个典型HTTP请求的处理流程如下过滤器 (Filter)- 2.拦截器 preHandle- 3.控制器 (Controller)- 4.拦截器 postHandle- 5.视图渲染- 6.拦截器 afterCompletion- 7.过滤器 (Filter)关于ControllerAdviceControllerAdviceExceptionHandler用于全局异常处理。如果控制器或拦截器preHandle返回true后抛异常会先被ControllerAdvice处理然后仍然会执行已通过preHandle的拦截器的afterCompletion方法。如果拦截器preHandle返回false请求直接被中断控制器和ControllerAdvice都不会执行但已通过preHandle的拦截器的afterCompletion仍会执行。顺序总结表组件执行时机备注Filter最先和最后Servlet规范最底层。Interceptor#preHandle控制器前按配置顺序正序执行。Controller业务逻辑核心抛出异常会进入ControllerAdvice。Interceptor#postHandle控制器后视图前按配置顺序逆序执行。对REST API可能不执行。View Rendering渲染HTML等Interceptor#afterCompletion视图渲染后按配置顺序逆序执行。总是执行对应拦截器preHandle返回true。Filter最后完成响应输出。5.4 性能陷阱拦截器中的耗时操作拦截器在每个请求中都会执行因此其中的代码必须高效。以下操作要特别小心频繁的数据库查询例如在登录拦截器中每次请求都根据Token查询完整的用户对象。优化方案使用缓存如Redis存储用户会话信息拦截器中只查缓存或者使用JWT等无状态方案拦截器只做Token解析和签名验证。复杂的日志记录全量记录请求体/响应体会极大消耗I/O和磁盘。生产环境应使用DEBUG级别或采样记录。同步阻塞调用避免在拦截器中进行网络IO等阻塞操作。一个优化案例将用户信息查询从数据库移到缓存。// 在登录拦截器的preHandle中 String token ...; // 不再直接查数据库 // User user userRepository.findByToken(token); // 改为查缓存 String cacheKey user:session: token; User user (User) redisTemplate.opsForValue().get(cacheKey); if (user null) { // 缓存未命中再查数据库次数很少 user userRepository.findByToken(token); if (user ! null) { redisTemplate.opsForValue().set(cacheKey, user, Duration.ofHours(2)); } }5.5 如何对拦截器进行单元测试测试拦截器可以确保其逻辑正确尤其是边界条件。使用Spring的MockMvc可以方便地模拟请求。SpringBootTest AutoConfigureMockMvc class LoginInterceptorTest { Autowired private MockMvc mockMvc; Test void testPreHandle_WithoutToken_ShouldReturnUnauthorized() throws Exception { mockMvc.perform(get(/api/protected/resource)) .andExpect(status().isUnauthorized()) // 期望401状态码 .andExpect(jsonPath($.code).value(401)) .andExpect(jsonPath($.message).value(请先登录)); } Test void testPreHandle_WithValidToken_ShouldPass() throws Exception { String validToken your.valid.jwt.token; mockMvc.perform(get(/api/protected/resource) .header(Authorization, Bearer validToken)) .andExpect(status().isOk()); // 可以进一步验证控制器是否收到了正确的用户属性 } Test void testPreHandle_WithInvalidToken_ShouldReturnUnauthorized() throws Exception { mockMvc.perform(get(/api/protected/resource) .header(Authorization, Bearer invalid.token.here)) .andExpect(status().isUnauthorized()) .andExpect(jsonPath($.message).value(登录已过期或无效请重新登录)); } }通过覆盖这些测试用例你可以对拦截器的各种分支逻辑充满信心。记住拦截器是你应用的门卫给它足够的测试是保证系统安全稳定的重要一环。