关于SpringBoot拦截器中Bean无法注入的问题

这两天遇到SpringBoot拦截器中Bean无法注入问题。下面介绍关于SpringBoot拦截器中Bean无法注入的问题，感兴趣的朋友一起看看吧

问题

这两天遇到SpringBoot拦截器中Bean无法注入问题。下面介绍我的思考过程和解决过程：

1.由于其他bean在service，controller层注入一点问题也没有，开始根本没意识到Bean无法注入是在拦截器中无效的问题，一直在查找注解指定的包在哪里配置的，然而却找不到配置，Springboot是用java类的形式加载配置的。在网络的某个角落看到这样的说法：

SpringBoot项目的Bean装配默认规则是根据Application类所在的包位置从上往下扫描！
“Application类”是指SpringBoot项目入口类。这个类的位置很关键：
如果Application类所在的包为：com.boot.app，则只会扫描com.boot.app包及其所有子包，如果service或dao所在包不在com.boot.app及其子包下，则不会被扫描！
即,把Application类放到dao、service所在包的上级，com.boot.Application
知道这一点非常关键，不知道spring文档里有没有给出说明，如果不知道还真是无从解决。

我出问题的类确实在Application类子包下面，看来不是这方面问题。

2.开始意识到只是拦截器上会有这样的问题，查询原因应该是：

拦截器执行在自动bean初始化之前导致这个问题的。

web里各个元素的执行顺序

在web.xml中各个元素的执行顺序是这样的，context-param-->listener-->filter-->servlet；而拦截器是在Spring MVC中配置的，如果从整个项目中看，一个servlet请求的执行过程就变成了这样context-param-->listener-->filter-->servlet-->interceptor(指的是拦截器)，为什么拦截器是在servlet执行之后，因为拦截器本身就是在servlet内部的。

各个元素具体概念

context-param：就是一些需要初始化的配置，放入context-param中，从而被监听器（这里特指org.springframework.web.context.ContextLoaderListener）监听，然后加载；

监听器(listener)：就是对项目起到监听的作用，它能感知到包括request(请求域)，session(会话域)和applicaiton(应用程序)的初始化和属性的变化；

过滤器(filter)：就是对请求起到过滤的作用，它在监听器之后，作用在servlet之前，对请求进行过滤；

servlet：就是对request和response进行处理的容器，它在filter之后执行，servlet其中的一部分就是controller层（标记为servlet_2），还包括渲染视图层(标记为servlet_3)和进入controller之前系统的一些处理部分(servlet_1)，另外我们把servlet开始的时刻标记为servlet_0，servlet结束的时刻标记为servlet_4。

拦截器(interceptor)：就是对请求和返回进行拦截，它作用在servlet的内部，具体来说有三个地方：

1）servlet_1和servlet_2之间，即请求还没有到controller层

2）servlet_2和servlet_3之间，即请求走出controller层次，还没有到渲染时图层

3）servlet_3和servlet_4之间，即结束视图渲染，但是还没有到servlet的结束

元素之间关系图

关于SpringBoot拦截器中Bean无法注入的问题