Spring Boot统一功能处理（一）

翎歌☜

已于 2024-04-11 10:31:57 修改

阅读量1.2k

点赞数 12

于 2024-04-10 21:27:14 首次发布

本文链接：https://blog.csdn.net/qq_66292058/article/details/137562120

版权

本篇主要介绍Spring Boot的统一功能处理中的拦截器。

一、拦截器的基本使用

二、拦截器实操

三、浅尝源码

初始化DispatcherServerlet

处理请求（doDispatch)

四、适配器模式

一、拦截器的基本使用

在一般的学校或者社区门口，通常会安排几个保安大爷来进行身份验证，只有身份符合要求的人才会被放行，否则则会被大爷拦住，而拦截器就像我们程序的保安大爷，只有通过我们自己定义的拦截规则，请求才能被放行到目标接口上。

下面我们来看看如何在Spring Boot中使用拦截器

在项目中设置拦截，我们需要先自己定义一些拦截器，里面包含一些具体的拦截规则，定义拦截器的代码如下：

（1)首先创建一个拦截类，通常以“Interceptor”作为类名的后半部分，这里我们定义一个LoginInterceptor类，意为与登录相关的拦截器，然后让该类实现一个HandlerInterceptor接口，具体如下：

@Component
public class LoginInterceptor implements HandlerInterceptor {

}

(2)重写三个方法：

 @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
       
    }

    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
        
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
       
    }

其中preHandle为在目标方法执行前要执行的方法，其返回值如果为true，则会被放行去执行目标方法，为false则拦截，我们可以在这个方法里根据需求定义拦截规则。postHandle为目标方法执行后要执行的方法。afterCompletion为最后视图渲染完后最后执行的方法（由于现在都是前后端分离了，后端一般不处理视图，因此这个方法不需要过多了解）。

定义好拦截器后我们还需要配置拦截器，具体配置流程如下：

(1)创建配置类（一般以Config结尾，这里以为WebConfig），实现WebMvcConfigurer接口：

public class WebConfig implements WebMvcConfigurer {
}

(2)然后重写addInterceptor方法

@Override
    public void addInterceptors(InterceptorRegistry registry) {
        
    }

(3)然后我们在里面添加我们需要配置的拦截器，具体如下：

这里我们可以通过@Autowired注入一个LoginInterceptor对象，也可以直接在参数里new一个，只要是传入一个实现前面的HandlerInterceptor接口的类的对象即可。

(4)然后在配置我们需要拦截的路径（即请求url中ip地址端口号的后面的部分）：

这里的”/**"表示任意路径，例如“/user/book、/user”等，另外还有“/*"他只能表示一级路径，例如：

”/user，/book"等。

(4)由于通常我们并不需要所有路径都进行拦截（例如登录请求），因此我们还需要排除一些路径，让这些路径不被拦截，具体如下：

（5）最后我们还需要把这个类放到Spring容器里，由于这里与配置相关，所有使用@Configuration。

二、拦截器实操

接下来我们来实操一下。首先我们创建一个Controller类，在里面定义一个login方法（这里只是简单测试一下，不进行密码校验，只是给用户设置一个登录状态而已）：

然后再添加几个测试方法：

然后我们再来定义一下拦截器，再preHandle方法中设置一下拦截规则，只有处于登录状态才能放行，并在另外两个方法中打印日志来进行观察：

然后在注册（配置）一下拦截器（不拦截login方法，其他全部拦截）：

最后我们通过postMan构造请求来访问一下这些方法.

先访问一下test01

可以发现返回的响应为空，也就是说请求被拦截器拦截到了。

然后我们再来访问一下login

可以发现响应有数据了，但由于我们请求中没有传值，导致接口中的两个参数为空，所以返回了false。接下来我们补上这两个值再访问一下

可以发现响应中返回true了，同时这也意味着我们现在已经给用户设置成登录状态了，此时我们再来访问test01

可以发现响应已经有数据了。这也就意味着这个请求已经被拦截器放行了。

最后我们再来看一下控制台的日志：

可以发现，拦截器是严格按照顺序执行相关方法的，如果请求被拦截了，则只会执行postHandle方法就返回了，如果请求被放行则会按顺序执行完拦截器中的三个方法。并且对于配置中没有涉及到的路径，和被排除的路径，则根本不会进入到拦截器。

三、浅尝源码

接下来，我们来浅浅阅读一下与拦截器相关的部分源码。

初始化DispatcherServerlet

仔细观察日志可以发现，当我们的服务器接收到第一个来自前端的请求时，会初始化一个dispatcherServerlet类。

它的初始化方法为init(),具体实现是在其父类HttpServerletBean中实现的

init方法首先创建了一个PropertyValues类，这个类我并不知道是干嘛的，但根据其名称可以大体猜出来应该是去读一些配置，并且下面的if语句判断这个对象是否为空，不为空才去执行相关逻辑，因此可以推测出if语句里应该是去根据读到的配置去进行一些设置。在init方法最后执行了一个initServerletBean方法，，我们来具体看一下这个方法，

转到定义可以发现HttpServerletBean中并未实现这个方法，接下来我们去其子类看一下

可以发现其子类FrameworkServerlet重写了这个方法，并具体进行了实现。仔细观察可以发现这个方法主要是在打印日志，日志的内容就是我们在前面控制台所看到的

并且这里还进行了计时，并打印在了日志里。除去日志的部分可以发现这个方法就只剩下try-catch中的内容了：

接下来我们继续进入到其中的initWebAppliactionContext ()来看一下，

根据名字可以发现这个方法应该是用来初始化WebApplicationContext的，并且通过代码大致可以发现这个方法会先去从类的成员属性中获取WebAppliactionContext，如果成员属性不为空，则会直接用成员属性的，如果为空，则调用findWebApplication去寻找一个并使用，如果没找到，则去创建一个。执行完上面第一个红框里的内容后，wac应该是已经不再为空了的，接下来调用onRefresh方法，可以发现这里加了锁来防止线程安全问题。接下来我们进到onRefresh方法来看一下：

可以发现FrameWorkServerlet中并未进行实现，我们再进到其子类看一下：

可以发现子类进行了实现，并且此时这个子类就是我们要初始化的DispatchServerlet。然后我们再看看这个方法里使用的initStrategies（）方法:

通过方法名称可以发现这个方法是在进行一些初始化，然后再通过具体代码可以发现这个方法初始化了九个组件，这些组件就是Spring的九大组件，其名称如下：

MultipartResolver：文件上传解析器
LocaleResolver：区域解析器
ThemeResolver:主题解析器
HandlerMappings:处理器映射器
HandlerAdapters：处理器适配器
HandlerExceptionResolvers:异常处理器解析器
RequestToviewNameTranslator：视图名称转换器
ViewResolvers：视图解析器
FlashMapManager：FlashMap管理器

初始化这些组件后，DispatchServerlet就初始化完了。

处理请求（doDispatch)

初始化完成后，DispatchServerlet就能进行请求的处理了，处理请求，主要通过DispatchServerlet类的doDispatch方法来对请求调度给Controller来执行，下面我们来详细看一下这个方法：

首先它会去获取一个与请求对应的处理器，然后再根据处理器去获取一个能够使用的适配器

然后再根据适配器来顺序执行拦截器的相关方法以及目标方法然后处理视图，并执行最后的afterCompletion方法

四、适配器模式

在前面浅尝源码时，提到了适配器这个概念，适配器使用到了一种设计模式 --- 适配器模式。适配器模式能将一个类的接口，转换成符合客户期待的接口，从而使原本并不能兼容使用的接口也能使用了。简单来说，就是有一个接口，由于兼容问题并不能直接使用，需要在中间加上一个适配器才能够使用这个接口。例如我们生活中的转接头，当我们的手机是Type_c的充电口，而我们却只有苹果的数据线时，这根苹果的数据线自然是冲不了我们的手机的，此时就需要一个转接头了，通过转接头，我们就可以给手机充电了。此处转接头就相当于我们的的适配器，而转接头的设计就相当于是是适配器模式这种设计思想

可能有人会说为什么不在一开始就设计成兼容的接口呢，这样就没必要大费周章弄一个适配器了，这样固然好，但人并不是万能的，总会有我们意想不到的情况出现，面面俱到几乎是不可能的，就像使用Type-c接口的手机厂商肯定不会想到有人会用苹果的数据线来充电，但既然这个需求是存在的，也就不能不去实现了，重新设计的话，成本又太高，因此，就只能使用适配器这一无奈之举了。