感兴趣的可以查看上一篇过滤器的使用 【Springboot】Filter 过滤器的使用
一、什么是拦截器
拦截器(Interceptor)是一种特殊的组件,它可以在请求处理的过程中对请求和响应进行拦截和处理。拦截器可以在请求到达目标处理器之前、处理器处理请求之后以及视图渲染之前执行特定的操作。拦截器的主要目的是在不修改原有代码的情况下,实现对请求和响应的统一处理。
二、拦截器的作用
拦截器可以用于实现以下功能:
- 权限控制:拦截器可以在请求到达处理器之前进行权限验证,从而实现对不同用户的访问控制。
- 日志记录:拦截器可以在请求处理过程中记录请求和响应的详细信息,便于后期分析和调试。
- 接口幂等性校验:拦截器可以在请求到达处理器之前进行幂等性校验,防止重复提交。
- 数据校验:拦截器可以在请求到达处理器之前对请求数据进行校验,确保数据的合法性。
- 缓存处理:拦截器可以在请求处理之后对响应数据进行缓存,提高系统性能。
三、拦截器与过滤器的区别
拦截器和过滤器都可以实现对请求和响应的拦截和处理,但它们之间存在以下区别:
- 执行顺序:过滤器在拦截器之前执行,拦截器在处理器之前执行。
- 功能范围:过滤器可以对所有请求进行拦截,而拦截器只能对特定的请求进行拦截。
- 生命周期:过滤器由 Servlet 容器管理,拦截器由 Spring 容器管理。
- 使用场景:过滤器适用于对请求和响应的全局处理,拦截器适用于对特定请求的处理。
四、SpringBoot 中的拦截器实现
4.1 实现 HandlerInterceptor 接口
要在 SpringBoot 中实现拦截器,首先需要创建一个类并实现 HandlerInterceptor 接口。HandlerInterceptor 接口包含以下三个方法:
- preHandle:在请求(某个 URL)到达处理器(匹配到对应的 Controller )之前执行,可以用于权限验证、数据校验等操作。如果返回 true,则继续执行后续操作;如果返回 false,则中断请求处理。
- postHandle:在处理器处理请求之后执行,可以用于日志记录、缓存处理等操作。
- afterCompletion:顾名思义,该方法是在整个请求处理完成后(包括视图渲染)执行,这时做一些资源的清理工作,这个方法只有在 preHandle(……) 被成功执行后并且返回 true 才会被执行。
以下是一个简单的拦截器实现示例:
4.1.1 先自定义一个 MyInterceptor 拦截器类
@Slf4j
public class MyInterceptor implements HandlerInter {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
HandlerMethod handlerMethod = (HandlerMethod) handler;
Method method = handlerMethod.getMethod();
String methodName = method.getName();
log.info("====拦截到了方法:{},在该方法执行之前执行====", methodName);
// 返回 true 才会继续执行,返回 false 则取消当前请求
return true;
}
@Override
public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
log.info("执行完方法之后执行(Controller方法调用之后),但是此时还没进行视图渲染");
}
@Override
public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
log.info("整个请求都处理完咯,DispatcherServlet也渲染了对应的视图咯,此时我可以做一些清理的工作了");
}
}
OK,到此为止,拦截器已经定义完成,接下来就是对该拦截器进行拦截配置。
4.2.2 注册拦截器到 InterceptorRegistry
要让拦截器生效,需要将其注册到 InterceptorRegistry 中。这可以通过继承 WebMvcConfigurationSupport 类并重写 addInterceptors 方法来实现拦截器的配置。以下是一个简单的注册示例:
在 Spring Boot 2.0 之前,我们都是直接继承 WebMvcConfigurerAdapter 类,然后重写 addInterceptors 方法来实现拦截器的配置。但是在 Spring Boot 2.0 之后,该方法已经被废弃了(当然,也可以继续用),取而代之的是 WebMvcConfigurationSupport 方法
@Slf4j
@Configuration
public class WebInterceptorConfig extends WebMvcConfigurationSupport {
@Override
protected void addInterceptors(InterceptorRegistry registry) {
registry.addInterceptor(new MyInterceptor()).addPathPatterns("/**");
super.addInterceptors(registry);
}
}
在该配置中重写 addInterceptors 方法,将我们上面自定义的拦截器添加进去,addPathPatterns 方法用来添加要拦截的请求,这里我们拦截所有的请求。现在我们配置好了拦截器,接下来写一个 Controller 测试一下:
输出结果为:
====拦截到了方法:test,在该方法执行之前执行====
1111 // 这是方法打印的内容
执行完方法之后执行(Controller方法调用之后),但是此时还没进行视图渲染
整个请求都处理完咯,DispatcherServlet也渲染了对应的视图咯,此时我可以做一些清理的工
可以看出拦截器已经生效,并能看出其执行顺序。
如果加上过滤器,查看此时过滤器和拦截器的执行顺序,执行顺序打印如下:
------对 request 进行过滤 --------
====拦截到了方法:test,在该方法执行之前执行====
1111 // 这是方法打印的内容
执行完方法之后执行(Controller方法调用之后),但是此时还没进行视图渲染
整个请求都处理完咯,DispatcherServlet也渲染了对应的视图咯,此时我可以做一些清理的工作了
------对 response 进行过滤 --------
4.2.3 解决静态资源被拦截问题
上面已经介绍了拦截器的定义和配置,这样就没问题了吗?其实不然,如果使用上面这种配置的话,我们会发现一个缺陷,那就是静态资源被拦截了。可以在 resources/static/ 目录下放置一个图片资源或者 HTML 文件,之后启动项目直接访问,即可看到无法访问的现象。
也就是说,虽然 Spring Boot 2.0 废弃了 WebMvcConfigurerAdapter,但是 WebMvcConfigurationSupport 又会导致默认的静态资源被拦截,这就需要我们手动将静态资源放开。
如何放开呢?除了在 MyInterceptorConfig 配置类中重写 addInterceptors 方法,还需要再重写一个方法 addResourceHandlers,用来将静态资源放开:
/**
* 用来指定静态资源不被拦截,否则继承 WebMvcConfigurationSupport 这种方式会导致静态资源无法直接访问
* @param registry
*/
@Override
protected void addResourceHandlers(ResourceHandlerRegistry registry) {
//第一个方法设置访问路径前缀,第二个方法设置资源路径
registry.addResourceHandler("/resources/**","/public/**")
.addResourceLocations("classpath:/resources/","classpath:/public/");
super.addResourceHandlers(registry);
}
然后在添加自定义拦截器时忽略静态资源的路径前缀:
@Configuration
public class MyInterceptorConfig implements WebMvcConfigurer {
@Override
public void addInterceptors(InterceptorRegistry registry) {
// 实现 WebMvcConfigurer 不会导致静态资源被拦截
registry.addInterceptor(new MyInterceptor())
.addPathPatterns("/**")
.excludePathPatterns("/","user/login","/index.html","/error.html")
.excludePathPatterns("/public/**","/resources/**");
}
}
如上配置好之后,重启项目,静态资源也可以正常访问了。最后,在访问静态资源的时候,加上资源所处的完整路径,例如:localhost:8080/public/11.png
、localhost:8080/resources/11.png ,
上面这种方式的确能解决静态资源无法访问的问题,但是,还有更方便的配置方式。
我们不继承 WebMvcConfigurationSupport 类,直接实现 WebMvcConfigurer 接口,然后重写 addInterceptors 方法,将自定义的拦截器添加进去即可,如下:
@Configuration
public class MyInterceptorConfig implements WebMvcConfigurer {
@Override
public void addInterceptors(InterceptorRegistry registry) {
// 实现 WebMvcConfigurer 不会导致静态资源被拦截
registry.addInterceptor(new MyInterceptor()).addPathPatterns("/**");
}
}
这样就非常方便了,通过实现 WebMvcConfigure 接口,使 Spring Boot 默认的静态资源不会拦截。
这两种方式都可以,两者更多具体细节,感兴趣的读者可以进一步研究。由于这两种方式的不同,继承 WebMvcConfigurationSupport 类的方式可以用在前后端分离的项目中,后台不需要访问静态资源(就不需要放开静态资源了);实现 WebMvcConfigure 接口的方式可以用在非前后端分离的项目中,因为需要读取一些图片、CSS、JS 文件等等。
五、拦截器的使用实例
5.1 判断用户有没有登录
一般用户的登录功能,我们可以这么实现,要么在 Session 中写一个 user,要么针对每个 user 生成一个 Token,相比之下,第二种要更好。
第二种方式中,如果用户登录成功,每次请求时都会带上该用户的 Token,如果未登录,则没有该 Token,服务端可以检测这个 Token 参数的有无来判断用户有没有登录,从而实现拦截功能。我们改造一下 preHandle 方法,如下:
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
HandlerMethod handlerMethod = (HandlerMethod) handler;
Method method = handlerMethod.getMethod();
String methodName = method.getName();
log.info("====拦截到了方法:{},在该方法执行之前执行====", methodName);
// 判断用户有没有登陆,一般登陆之后的用户都有一个对应的 token
String token = request.getParameter("token");
if (null == token || "".equals(token)) {
log.info("用户未登录,没有权限执行……请登录");
return false;
}
// 返回 true 才会继续执行,返回 false 则取消当前请求
return true;
}
重启项目,在浏览器中输入:localhost:8080/hello, 之后查看控制台日志,发现被拦截,如果在浏览器中输入:localhost:8080/hello?token=123 即可正常往下访问。
5.2 取消拦截操作
根据上面讲解,如果我要拦截所有 /admin 开头的 URL 请求,需要在拦截器配置中添加该前缀。但在实际项目中,可能会有这种场景出现:某个请求也是 /admin 开头,但不能拦截,比如 /admin/login 等等,这样的话还需再去配置。这时,可不可以做成一个类似于开关的东西,哪里不需要拦截,我就在哪里放个开关,做成灵活的可插拔的效果呢?
可以的,我们可以定义一个注解,该注解专门用来取消拦截操作,如果某个 Controller 中的方法我们不需要拦截,即可在该方法上加上我们自定义的注解即可,下面先定义一个注解:
/**
* 该注解用来指定某个方法不用拦截
*/
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface UnInterception {
}
然后在 Controller 中的某个方法上添加该注解,在拦截器处理方法中添加该注解取消拦截的逻辑,如下:
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
HandlerMethod handlerMethod = (HandlerMethod) handler;
Method method = handlerMethod.getMethod();
String methodName = method.getName();
log.info("====拦截到了方法:{},在该方法执行之前执行====", methodName);
// 通过方法,可以获取该方法上的自定义注解,然后通过注解来判断该方法是否要被拦截
// @UnInterception 是我们自定义的注解
UnInterception unInterception = method.getAnnotation(UnInterception.class);
if (null != unInterception) {
return true;
}
// 判断用户有没有登陆,一般登陆之后的用户都有一个对应的 token
String token = request.getParameter("token");
if (null == token || "".equals(token)) {
log.info("用户未登录,没有权限执行……请登录");
return false;
}
// 返回true才会继续执行,返回false则取消当前请求
return true;
}
重启项目在浏览器中输入:hellohttp://localhost:8080/hello, 测试一下,可以看出,加了该注解的方法不会被拦截。
@UnInterception
@GetMapping("/hello")
public String hello() {
System.out.println("1111");
return "ok";
}
六、拦截器的其他应用
6.1 拦截器实现日志记录
拦截器可以在请求处理过程中记录请求和响应的详细信息,便于后期分析和调试。以下是一个简单的日志记录示例:
public class LogInterceptor implements HandlerInterceptor {
private static final Logger logger = LoggerFactory.getLogger(LogInterceptor.class);
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
logger.info("Request URI: {}", request.getRequestURI());
return true;
}
@Override
public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) {
logger.info("Response status: {}", response.getStatus());
}
}
6.2 拦截器实现接口幂等性校验
拦截器可以在请求到达处理器之前进行幂等性校验,防止重复提交。以下是一个简单的幂等性校验示例:
public class IdempotentInterceptor implements HandlerInterceptor {
private static final String IDEMPOTENT_TOKEN = "idempotentToken";
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
String token = request.getHeader(IDEMPOTENT_TOKEN);
if (StringUtils.isEmpty(token)) {
throw new RuntimeException("Idempotent token is missing");
}
if (!checkIdempotentToken(token)) {
throw new RuntimeException("Duplicate request");
}
return true;
}
private boolean checkIdempotentToken(String token) {
// Check the token in the cache or database
// Return true if the token is valid, false otherwise
}
}
七、拦截器的性能优化和常见问题
7.1 拦截器性能优化策略
拦截器在请求处理过程中可能会影响系统性能,以下是一些性能优化策略:
- 减少拦截器数量:尽量将相关功能集中到一个拦截器中,避免创建过多的拦截器。
- 精确配置拦截规则:通过 addPathPatterns 和 excludePathPatterns 方法精确配置拦截规则,避免不必要的拦截。
- 使用异步处理:在拦截器中使用异步处理,避免阻塞请求处理过程。
- 使用缓存:在拦截器中使用缓存,减少对数据库或其他资源的访问。
7.2 拦截器的常见问题和解决方案
拦截器是一种用于处理请求和响应的中间件,它可以在请求到达目标处理器之前或响应返回客户端之前执行一些操作。然而,在实际使用过程中,我们可能会遇到一些问题,如拦截器不生效、执行顺序错误或影响性能等。接下来,我们将逐一分析这些问题的原因及解决方法。
- 拦截器不生效:拦截器不生效的可能原因有很多,其中最常见的包括拦截器未注册到 InterceptorRegistry、拦截规则配置错误等。为了解决这个问题,我们需要首先检查拦截器是否已经正确注册到 InterceptorRegistry 中,然后再检查拦截规则是否配置正确。如果发现问题,需要及时进行调整和修复。
- 拦截器执行顺序错误:拦截器执行顺序错误的主要原因是拦截器的注册顺序错误。在实际应用中,拦截器的执行顺序是根据它们在 InterceptorRegistry 中的注册顺序来决定的。因此,为了解决这个问题,我们需要调整拦截器在 InterceptorRegistry 中的注册顺序,确保它们按照预期的顺序执行。
- 拦截器影响性能:拦截器影响性能的主要原因是拦截器中的处理逻辑过于复杂或资源消耗过大。为了解决这个问题,我们需要对拦截器的处理逻辑进行优化,尽量减少不必要的计算和资源消耗。同时,我们还可以考虑使用一些性能监控工具,如 JProfiler 等,来对拦截器的性能进行实时监控和分析,从而找到性能瓶颈并进行优化。
拦截器在实际应用中可能会遇到一些问题,但只要我们能够深入了解其原理和机制,就可以找到合适的解决方案。
八、参考文档
Spring Boot 中使用拦截器
全面了解SpringBoot拦截器