springboot中，实现Filter接口后，接口请求的执行流程解析

今天没事就熟悉一下项目中业务之外的代码，发现了鉴权相关的代码还不太了解，于是开始研究起来，比较乱，想到哪就写到哪

鉴权的话，一般是通过拦截器Filter来实现拦截请求，进行相应的逻辑判断，判断用户是否拥有该资源的访问权限，或者进行其他一些权限拦截，编码拦截等。

如下，是我现在项目中的鉴权入口：

看图中：
第一点：任意一个类，实现Filter接口，都可以实现拦截器的功能

第二点：@SneakyThrows注解是lombok对异常的封装注解，在方法上面加上该注解，对于必须要try{} catch{}的代码（比如涉及到IO操作的代码就强制要求try catch），就不再需要了，或者throws抛出的异常也不需要了，大家可以看到doFilter方法后面的throws IOException，ServletException都是灰色的，代表并没有用到，可以删除。如果没有加@SneaKyThrows注解，这抛出异常就必不可免了。

第三点：doFilter方法是所有实现了Filter接口的类都必须重写的方法，这个方法就是写拦截器的主要逻辑的方法。

第四点：这一个是我们项目自己写的类，实现了ApplicationContextAware接口，并实现了ApplicationContext的getBean方法。

这里重点就是getBean方法，初看到这个方法，我脑子里就有一个疑惑，这不就是从Spring的IOC容器池获取bean吗？ 我为啥不用@Autowired或者@Resource注入，为什么还要用这种不友好的代码（一般人看不懂）？
针对这点，我是百思不得其解，遂百度之。

百度的结果也是千奇百怪，就是没人能够解释清楚，所有的回答都是，我想…,我觉得…,有可能…,这让人怎么信服。

我这里写的也是我百度后的感悟：
ApplicationContext.getBean比较适合没有单例注解（比如@Controller, @Service, @Bean，这些都是默认的单例注解）的类中使用，比如某个工具类要使用spring托管的某个类的方法，就可以通过这个来获取，两者没有本质上的特殊性，只是两种获取bean的不同方式。

第五点：可以看到filterChain.doFilter()方法，这个方法的作用就是代表着此拦截器的拦截作用已经完毕，如果还有其他实现了Filter接口的类，就会去执行其他的拦截器，至于JVM执行拦截器的顺序，就由一个注解来手动规定，如下：

@Order中的数值越小，越优先执行。

如果只有这么一个拦截器，@Order就可以省略，并且在执行filterChain.doFilter()后会直接去请求对应的接口，拦截器就执行完毕了。

ps:在第四点中，我目前的项目是自己写一个类实现ApplicationContextAware接口，重写getBean方法，然而，如果在项目中使用了hutool-all的依赖，直接使用其封装的SpringUtil.getBean()就行，其内部就是封装的SpringUtil类实现了ApplicationContextAware接口，然后重写getBean方法。

ps2：还是推荐项目中加入hutool的依赖，这个依赖的主要作用就是对一些常见功能进行了封装，包括类型转换封装，时间类封装，字符串类封装，各种工具都有，直接用，不需要再手动造轮子。

–我是“道祖且长”,一个在互联网"苟且偷生"的Java程序员
“有任何问题，可评论，我看到就会回复”