马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。
您需要 登录 才可以下载或查看，没有账号？立即注册
x
目录
一、 配置优先级
编辑
二、Bean管理
2.1：获取Bean
编辑
2.2：Bean作用域
2.3：第三方Bean
三、Springboot底层原理
3.1：起步依赖
3.1.1：maven的依赖通报：
3.2：自动配置（重点）：
3.2.1 概述：
3.2.2：常见方案
3.2.2.1：概述
3.2.2.2:方案一
3.2.2.3：方案二
3.2.3：原理分析
3.2.4：自动配置源码小结
媒介：
在当今快节奏的开辟时代，Spring Boot 作为一款极具影响力的框架，彻底改变了 Java 应用的构建方式。它依附简洁的配置、强盛的功能，为开辟者节省大量精神。然而，多数人忙于利用，对其底层原理却一孔之见。此刻，让我们停下匆忙的脚步，一同深入这篇博客，去探究 Spring Boot 是如何施展魔法，从启动初始化到运行时的精妙管控，层层剖析，发掘那些隐蔽在便捷背后的技术奥秘。
1. 配置优先级：Springboot项目当中属性配置的常见方式以及配置的优先级
2. Bean的管理
3. 剖析Springboot的底层原理
一、 配置优先级
在我们前面的课程当中，我们已经讲解了SpringBoot项目当中支持的三类配置文件：
application.properties
application.yml
application.yaml
在SpringBoot项目当中，我们要想配置一个属性，可以通过这三种方式当中的任意一种来配置都可以，那么假如项目中同时存在这三种配置文件，且都配置了同一个属性，如：Tomcat端口号，到底哪一份配置文件生效呢？
aplication.propertiesp application.yml application.yaml 我们启动SpringBoot步伐，测试下三个配置文件中哪个Tomcat端口号生效：
properties、yaml、yml三种配置文件，优先级最高的是properties yaml 、 yml 两种配置文件同时存在的情况
配置文件优先级排名（从高到低）：
1. properties配置文件
2. yml配置文件
3. yaml配置文件
注意事项：固然springboot支持多种格式配置文件，但是在项目开辟时，保举同一利用一种格式的配置。（yml是主流）
在SpringBoot项目当中除了以上3种配置文件外，SpringBoot为了增强步伐的扩展性，除了支持配置
文件的配置方式以外，还支持另外两种常见的配置方式：
1. Java体系属性配置 （格式： -Dkey=value）
2. 命令行参数 （格式：--key=value）
那在idea当中运行步伐时，如何来指定Java体系属性和命令行参数呢？
编辑启动步伐的配置信息
重启服务，同时配置 Tomcat 端口 ( 三种配置文件、体系属性、命令行参数 ) ，测试哪个 Tomcat 端口号生效： 优先级： 命令行参数 > 体系属性参数 > properties参数 > yml参数 > yaml参数 思索：假如项目已经打包上线了，这个时候我们又如何来设置Java体系属性和命令行参数呢？
- 1 java -Dserver.port=9000 -jar XXXXX.jar --server.port=10010
下面我们来演示下打包步伐运行时指定Java体系属性和命令行参数：
- 执行maven打包指令package，把项目打成jar文件
- 利用命令：java -jar 方式运行jar文件步伐
运行jar步伐：
同时设置Java体系属性和命令行参数
仅设置Java体系属性
Springboot项目进行打包时，须要引入插件 spring-boot-maven-plugin (基于官网骨架创建项目，会自动添加该插件)
在SpringBoot项目当中，常见的属性配置方式有5种， 3种配置文件，加上2种外部属性的配置(Java
体系属性、命令行参数)。通过以上的测试，我们也得出了优先级(从低到高)：
application.yaml（忽略）
application.yml
application.properties
java体系属性（-Dxxx=xxx）
命令行参数（--xxx=xxx）
二、Bean管理
在前面的课程当中，我们已经讲过了我们可以通过Spring当中提供的注解@Component以及它的三个衍生注解（@Controller、@Service、@Repository）来声明IOC容器中的bean对象，同时我们也学习了如何为应用步伐注入运行时所须要依赖的bean对象，也就是依赖注入DI。
我们今天重要学习IOC容器中Bean的其他利用细节，重要学习以下三方面：
- 如何从IOC容器中手动的获取到bean对象
- bean的作用域配置
- 管理第三方的bean对象
接下来我们先来学习第一方面，从IOC容器中获取bean对象。
2.1：获取Bean
默认情况下，SpringBoot项目在启动的时候会自动的创建IOC容器(也称为Spring容器)，而且在启动的过程当中会自动的将bean对象都创建好，存放在IOC容器当中。应用步伐在运行时须要依赖什么bean对象，就直接进行依赖注入就可以了。
而在Spring容器中提供了一些方法，可以主动从IOC容器中获取到bean对象，下面介绍3种常用方式：
1、根据name获取bean
- 1 Object getBean(String name)
- 1 <T> T getBean(Class<T> requiredType)
根据name获取bean（带类型转换）
- 1 <T> T getBean(String name, Class<T> requiredType)
思索：要从IOC容器当中来获取到bean对象，须要先拿到IOC容器对象，怎么样才气拿到IOC容器呢？
想获取到IOC容器，直接将IOC容器对象注入进来就可以了
控制器：DeptController
业务实现类：DeptServiceImpl
Mapper接口：
测试类
2.2：Bean作用域
在前面我们提到的IOC容器当中，默认bean对象是单例模式(只有一个实例对象)。那么如何设置bean对象为非单例呢？须要设置bean的作用域。
在Spring中支持五种作用域，后三种在web情况才生效：
2.3：第三方Bean
学习完bean的获取、bean的作用域之后，接下来我们再来学习第三方bean的配置。
之前我们所配置的bean，像controller、service，dao三层体系下编写的类，这些类都是我们在项目当中自己定义的类(自定义类)。当我们要声明这些bean，也非常简单，我们只须要在类上加上 @Component以及它的这三个衍生注解（@Controller、@Service、@Repository），就可以来声明这个bean对象了。
但是在我们项目开辟当中，另有一种情况就是这个类它不是我们自己编写的，而是我们引入的第三方依赖当中提供的。
在pom.xml文件中，引入dom4j：
三、Springboot底层原理
3.1：起步依赖
假如我们没有利用 SpringBoot ，用的是 Spring 框架进行 web 步伐的开辟，此时我们就须要引入 web 步伐开辟所须要的一些依赖。 spring-webmvc依赖：这是Spring框架进行web步伐开辟所须要的依赖
servlet-api依赖：Servlet基础依赖
jackson-databind依赖：JSON处理工具包
假如要利用AOP，还须要引入aop依赖、aspect依赖
项目中所引入的这些依赖，还须要包管版本匹配，否则就可能会出现版本冲突问题。
假如我们利用了SpringBoot，就不须要像上面这么繁琐的引入依赖了。我们只须要引入一个依赖就可以了，那就是web开辟的起步依赖：springboot-starter-web。
3.1.1：maven的依赖通报：
假设a依赖了b，b依赖了c，c依赖了d，只须要引入a依赖，b,c,d依赖就都引入进来了
为什么我们只须要引入一个web开辟的起步依赖，web开辟所须要的所有的依赖都有了呢？
因为Maven的依赖通报。
在SpringBoot给我们提供的这些起步依赖当中，已提供了当前步伐开辟所须要的所有的常
见依赖(官网地址：https://docs.spring.io/spring-boot/docs/2.7.7/referen
ce/htmlsingle/#using.build-systems.starters )。
好比：springboot-starter-web，这是web开辟的起步依赖，在web开辟的起步依赖当
中，就集成了web开辟中常见的依赖：json、web、webmvc、tomcat等。我们只须要引入
这一个起步依赖，其他的依赖都会自动的通过Maven的依赖通报进来。
结论：起步依赖的原理就是Maven的依赖通报。
3.2：自动配置（重点）：
springboot原理就是自动配置的原理
3.2.1 概述：
SpringBoot的自动配置就是当Spring容器启动后，一些配置类、bean对象就自动存入到了IOC容器
中，不须要我们手动去声明，从而简化了开辟，省去了繁琐的配置操作。
好比：我们要进行事件管理、要进行AOP 步伐的开辟，此时就不须要我们再去手动的声明这些bean对象了，我们直接利用就可以从而大大的简化步伐的开辟，省去了繁琐的配置操作。 下面我们打开idea，一起来看下自动配置的结果：
运行SpringBoot启动类:
我们会发现，出现了许多没有见过的bean对象，也被加载进来了，这些就是springboot的自动配置的bean对象。
各人会看到有两个CommonConfig，在第一个CommonConfig类中定义了一个bean对象，bean对象的名字叫reader。
在第二个CommonConfig中它的bean名字叫commonConfig，为什么还会有这样一个bean对象呢？原因是在CommonConfig配置类上添加了一个注解@Configuration，而@Configuration底层就是@Component
以是配置类终极也是SpringIOC容器当中的一个bean对象
在IOC容器中除了我们自己定义的bean以外，另有许多配置类，这些配置类都是SpringBoot在启动的时候加载进来的配置类。这些配置类加载进来之后，它也会生成许多的bean对象。
好比：配置类GsonAutoConfiguration里面有一个bean，bean的名字叫gson，它的类型是
Gson。
com.google.gson.Gson是谷歌包中提供的用来处理JSON格式数据的
3.2.2：常见方案
3.2.2.1：概述
我们知道了什么是自动配置之后，接下来我们就要来剖析自动配置的原理。剖析自动配置的原理就是分析在 SpringBoot项目当中，我们引入对应的依赖之后，是如何将依赖jar包当中所提供的bean以及配置类直接加载到当前项目标SpringIOC容器当中的。
接下来，我们就直接通过代码来分析自动配置原理。
预备工作：在Idea中导入"资料\03. 自动配置原理"下的itheima-utils工程
1、在SpringBoot项目 spring-boot-web-config2 工程中，通过坐标引入itheima-utils依赖
2、在测试类中，添加测试方法
3、执行测试方法
异常信息描述： 没有com.example.TokenParse类型的bean
阐明：在Spring容器中没有找到com.example.TokenParse类型的bean对象
思索：引入进来的第三方依赖当中的bean以及配置类为什么没有生效？
原因在我们之前讲解IOC的时候有提到过，在类上添加@Component注解来声明bean对象时，还须要包管@Component注解能被Spring的组件扫描到。
SpringBoot项目中的@SpringBootApplication注解，具有包扫描的作用，但是它只会扫描启动类所在的当前包以及子包。
当前包：com.itheima， 第三方依赖中提供的包：com.example（扫描不到）
那么如何解决以上问题的呢？
方案1：@ComponentScan 组件扫描
方案2：@Import 导入（利用@Import导入的类会被Spring加载到IOC容器中）
3.2.2.2:方案一
@ComponentScan组件扫描
重新执行测试方法，控制台日志输出：
3.2.2.3：方案二
@Import导入
导入情势重要有以下几种：
- 导入普通类
- 导入ImportSelector接口实现类
- 导入配置类
1、导入普通类
2、利用@Import导入配置类：
配置类
3、利用@Import导入ImportSelector接口实现类：
ImportSelector接口实现类
我们利用@Import注解通过这三种方式都可以导入第三方依赖中所提供的bean大概是配置类。
思索：假如基于以上方式完成自动配置，当要引入一个第三方依赖时，是不是还要知道第三方依赖中有哪些配置类和哪些Bean对象？
答案：是的。 （对步伐员来讲，很不友爱，而且比较繁琐）
思索：当我们要利用第三方依赖，依赖中到底有哪些bean和配置类，谁最清楚？
答案：第三方依赖自身最清楚。
怎么让第三方依赖自己指定bean对象和配置类？
比较常见的方案就是第三方依赖给我们提供一个注解，这个注解一般都以@EnableXxxx开头的注解，注解中封装的就是@Import注解
利用第三方依赖提供的 @EnableXxxxx注解
第三方依赖中提供的注解
在利用时只需在启动类上加上@EnableXxxxx注解即可
以上四种方式都可以完成导入操作，但是第4种方式会更方便更优雅，而这种方式也是SpringBoot当中所采用的方式。
3.2.3：原理分析
源码跟踪
前面我们讲解了在项目当中引入第三方依赖之后，如何加载第三方依赖中定义好的bean对象以及配置类，从而完成自动配置操作。那下面我们通过源码跟踪的情势来剖析下SpringBoot底层到底是如何完成自动配置的。
源码跟踪技巧：
在跟踪框架源码的时候，一定要抓住关键点，找到核心流程。一定不要重新到尾一行代码去看，一个方法的去研究，一定要找到关键流程，抓住关键点，先在宏观上对整个流程大概整个原理有一个认识，有精神再去研究其中的细节。
要搞清楚SpringBoot的自动配置原理，要从SpringBoot启动类上利用的核心注解
@SpringBootApplication开始分析：
ConpoentScan 翻译：组件扫描
Configuration：配置
在@SpringBootApplication注解中包含了：
元注解（不再解释）
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan
我们先来看第一个注解：@SpringBootConfiguration
@SpringBootConfiguration注解上利用了@Configuration，表明SpringBoot启动类就是一个配置类。
@Indexed注解，是用来加速应用启动的（不用关心）。
接下来再先看@ComponentScan注解：
@ComponentScan注解是用来进行组件扫描的，扫描启动类所在的包及其子包下所有被 @Component及其衍生注解声明的类。
SpringBoot启动类，之以是具备扫描包功能，就是因为包含了@ComponentScan注解。
最后我们来看看@EnableAutoConfiguration注解（自动配置核心注解）：
利用@Import注解，导入了实现ImportSelector接口的实现类。
AutoConfigurationImportSelector类是ImportSelector接口的实现类。
AutoConfigurationImportSelector类中重写了ImportSelector接口的selectImports()方法：
selectImports()方法底层调用getAutoConfigurationEntry()方法，获取可自动配置的配置类信息集合
getAutoConfigurationEntry()方法通过调用 getCandidateConfigurations(annotationMetadata, attributes)方法获取在配置文件中配置的所有自动配置类的集合
getCandidateConfigurations方法的功能：
获取所有基于META- INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imp orts文件、META-INF/spring.factories文件中配置类的集合
META-
INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports
文件和META-INF/spring.factories文件这两个文件在哪里呢？
通常在引入的起步依赖中，都有包含以上两个文件
在前面在给各人演示自动配置的时候，我们直接在测试类当中注入了一个叫gson的bean对象，进行 JSON格式转换。固然我们没有配置bean对象，但是我们是可以直接注入利用的。原因就是因为在自动配置类当中做了自动配置。到底是在哪个自动配置类当中做的自动配置呢？我们通过搜索来查询一下。
在META-
INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports
配置文件中指定了第三方依赖Gson的配置类：GsonAutoConfiguration
第三方依赖中提供的GsonAutoConfiguration类：
在GsonAutoConfiguration类上，添加了注解@AutoConfiguration，通过检察源码，可以明确：GsonAutoConfiguration类是一个配置。
看到这里，各人就应该明白为什么可以完成自动配置了，原理就是在配置类中定义一个@Bean标识的方法，而Spring会自动调用配置类中利用@Bean标识的方法，并把方法的返回值注册到IOC容器中。
3.2.4：自动配置源码小结
自动配置原理源码入口就是@SpringBootApplication注解，在这个注解中封装了3个注解，分别是：
| @SpringBootConfiguration | 声明当前类是一个配置类 | | @ComponentScan | 进行组件扫描（SpringBoot中默认扫描的是启动类所在的当前 | | @EnableAutoConfiguration | 封装了@Import注解（Import注解中指定了一个ImportSelector接口的实现类） |
在实现类重写的selectImports()方法，读取当前项目下所有依赖jar包中META- INF/spring.factories、META-
INF/spring/org.springframework.boot.autoconfigure.AutoConfigurat ion.imports两个文件里面定义的配置类（配置类中定义了@Bean注解标识的方法）。
当SpringBoot步伐启动时，就会加载配置文件当中所定义的配置类，并将这些配置类信息(类的全限定名)封装到String类型的数组中，终极通过@Import注解将这些配置类全部加载到Spring的IOC容器中，交给IOC容器管理。
最后呢给各人抛出一个问题：在META- INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imp orts文件中定义的配置类非常多，而且每个配置类中又可以定义许多的bean，那这些bean都会注册到Spring的IOC容器中吗？
答案：并不是。 在声明bean对象时，上面有加一个以@Conditional开头的注解，这种注解的作用就是按照条件进行装配，只有满足条件之后，才会将bean注册到Spring的IOC容器中（下面会具体来讲解）
@Conditional
我们在跟踪SpringBoot自动配置的源码的时候，在自动配置类声明bean的时候，除了在方法上加了一个@Bean注解以外，还会经常用到一个注解，就是以Conditional开头的这一类的注解。以 Conditional开头的这些注解都是条件装配的注解。下面我们就来介绍下条件装配注解。
@Conditional注解：
作用：按照一定的条件进行判断，在满足给定条件后才会注册对应的bean对象到Spring的IOC容器中。
位置：方法、类
@Conditional自己是一个父注解，派生出大量的子注解：
@ConditionalOnClass：判断情况中有对应字节码文件，才注册bean到IOC容器。
@ConditionalOnMissingBean：判断情况中没有对应的bean(类型或名称)，才注册 bean到 IOC容器。
@ConditionalOnProperty：判断配置文件中有对应属性和值，才注册bean到IOC容器。
下面我们通过代码来演示下Conditional注解的利用：
@ConditionalOnClass注解
测试类：
@ConditionalOnMissingBean注解
再次修改@ConditionalOnMissingBean注解：
再次修改@ConditionalOnMissingBean注解：
@ConditionalOnProperty注解（这个注解和配置文件当中配置的属性有关系）
先在application.yml配置文件中添加如下的键值对：
修改@ConditionalOnProperty注解： havingValue的值修改为"itheima2"
我们再回头看看之前讲解SpringBoot源码时提到的一个配置类：GsonAutoConfiguration
最后再给各人梳理一下自动配置原理：
自动配置的核心就在@SpringBootApplication注解上，SpringBootApplication这个注解底层包含了3个注解，分别是：
@SpringBootConfiguration
@ComponentScan
@EnableAutoConfiguration
@EnableAutoConfiguration这个注解才是自动配置的核心。
它封装了一个@Import注解，Import注解里面指定了一个ImportSelector接口的实现类。
在这个实现类中，重写了ImportSelector接口中的selectImports()方法。
而selectImports()方法中会去读取两份配置文件，并将配置文件中定义的配置类做为 selectImports()方法的返回值返回，返回值代表的就是须要将哪些类交给Spring的IOC容器进行管理。
那么所有自动配置类的中声明的bean都会加载到Spring的IOC容器中吗? 其实并不会，因为这些配置类中在声明bean时，通常都会添加@Conditional开头的注解，这个注解就是进行条件装配。而Spring会根据Conditional注解有选择性的进行bean的创建。
@Enable 开头的注解底层，它就封装了一个注解 import 注解，它里面指定了一个类，是 ImportSelector 接口的实现类。在实现类当中，我们须要去实现 ImportSelector 接口当中的一个方法 selectImports 这个方法。这个方法的返回值代表的就是我须要将哪些类交给 spring 的 IOC容器进行管理。
此时它会去读取两份配置文件，一份儿是 spring.factories，另外一份儿是 autoConfiguration.imports。而在 autoConfiguration.imports 这份儿文件当中，它就会去配置大量的自动配置的类。
而前面我们也提到过这些所有的自动配置类当中，所有的 bean都会加载到 spring 的 IOC 容器当中吗？其实并不会，因为这些配置类当中，在声明 bean 的时候，通常会加上这么一类@Conditional 开头的注解。这个注解就是进行条件装配。以是SpringBoot非常的智能，它会根据 @Conditional 注解来进行条件装配。只有条件成立，它才会声明这个bean，才会将这个 bean 交给 IOC 容器管理。
3.2.4：案例
3.2.4.1：自定义starter分析
前面我们剖析了SpringBoot中自动配置的原理，下面我们就通过一个自定义starter案例来加深各人对于自动配置原理的明白。起首介绍一下自定义starter的业务场景，再来分析一下具体的操作步骤。
所谓starter指的就是SpringBoot当中的起步依赖。在SpringBoot当中已经给我们提供了许多的起步依赖了，我们为什么还须要自定义 starter 起步依赖？这是因为在实际的项目开辟当中，我们可能会用到许多第三方的技术，并不是所有的第三方的技术官方都给我们提供了与SpringBoot整合的 starter起步依赖，但是这些技术又非常的通用，在许多项目组当中都在利用。
业务场景：
我们前面案例当中所利用的阿里云OSS对象存储服务，如今阿里云的官方是没有给我们提供对应的起步依赖的，这个时候利用起来就会比较繁琐，我们须要引入对应的依赖。我们还须要在配置文件当中进行配置，还须要基于官方SDK示例来改造对应的工具类，我们在项目当中才可以进行利用。
各人想在我们当前项目当中利用了阿里云OSS，我们须要进行这么多步的操作。在别的项目组当中要想利用阿里云OSS，是不是也须要进行这么多步的操作，以是这个时候我们就可以自定义一些公共组件，在这些公共组件当中，我就可以提前把须要配置的bean都提前配置好。将来在项目当
中，我要想利用这个技术，我直接将组件对应的坐标直接引入进来，就已经自动配置好了，就可以直接利用了。我们也可以把公共组件提供给别的项目组进行利用，这样就可以大大的简化我们的开辟。
在SpringBoot项目中，一般都会将这些公共组件封装为SpringBoot当中的starter，也就是我们所说的起步依赖。
SpringBoot官方starter定名： spring-boot-starter-xxxx
第三构造提供的starter定名： xxxx-spring-boot-starter
Mybatis提供了配置类，而且也提供了springboot会自动读取的配置文件。当SpringBoot项目启动时，会读取到spring.factories配置文件中的配置类并加载配置类，生成相关bean对象注册到IOC容器中。
结果：我们可以直接在SpringBoot步伐中利用Mybatis自动配置的bean对象。
在自定义一个起步依赖starter的时候，按照规范须要定义两个模块：
starter模块（进行依赖管理[把步伐开辟所须要的依赖都定义在starter起步依赖中）
autoconfigure模块（自动配置）
将来在项目当中进行相关功能开辟时，只须要引入一个起步依赖就可以了，因为它会将
autoconfigure自动配置的依赖给通报下来。
上面我们简单介绍了自定义starter的场景，以及自定义starter时涉及到的模块之后，接下来我们就来完成一个自定义starter的案例。
需求：自定义aliyun-oss-spring-boot-starter，完成阿里云OSS操作工具类AliyunOSSUtils的自动配置。
目标：引入起步依赖引入之后，要想利用阿里云OSS，注入AliyunOSSUtils直接利用即可。
之前阿里云OSS的利用：
配置文件
当我们在项目当中要利用阿里云OSS，就可以注入AliOSSUtils工具类来进行文件上传。但这种方式其实是比较繁琐的。
各人再思索，如今我们利用阿里云OSS，须要做这么几步，将来各人在开辟其他的项目标时候，你利用阿里云OSS，这几步你要不要做？当团队中其他小同伴也在利用阿里云OSS的时候，步骤 不也是一样的。
以是这个时候我们就可以制作一个公共组件(自定义starter)。starter定义好之后，将来要利用阿里云OSS进行文件上传，只须要将起步依赖引入进来之后，就可以直接注入AliOSSUtils利用了。
需求明确了，接下来我们再来分析一下具体的实现步骤：
第1步：创建自定义starter模块（进行依赖管理）
把阿里云OSS所有的依赖同一管理起来
第2步：创建autoconfigure模块
在starter中引入autoconfigure （我们利用时只须要引入starter起步依赖即可）
第3步：在autoconfigure中完成自动配置
- 定义一个自动配置类，在自动配置类中将所要配置的bean都提前配置好
- 定义配置文件，把自动配置类的全类名定义在配置文件中
我们分析完自定义阿里云OSS自动配置的操作步骤了，下面我们就按照分析的步骤来实现自定义
starter。
自定义starter的步骤我们刚才已经分析了，接下来我们就按照分析的步骤来完成自定义starter的开辟。
起首我们先来创建两个Maven模块：
- aliyun-oss-spring-boot-starter模块
创建完starter模块后，删除多余的文件，终极保存内容如下：
删除pom.xml文件中多余的内容后：
- aliyun-oss-spring-boot-autoconfigure模块
创建完starter模块后，删除多余的文件，终极保存内容如下：
删除pom.xml文件中多余的内容后：
按照我们之前的分析，是须要在starter模块中来引入autoconfigure这个模块的。打开starter模块中的pom文件：
在autoconfigure模块当中来完成自动配置操作。
我们将之前案例中所利用的阿里云OSS部分的代码直接拷贝到autoconfigure模块下，然后进行改造就行了。
拷贝过来后，还缺失一些相关的依赖，须要把相关依赖也拷贝过来：
如今各人思索下，在类上添加的@Component注解另有效吗？
答案：没用了。 在SpringBoot项目中，并不会去扫描com.aliyun.oss这个包，不扫描这个包那类上的注解也就失去了作用。
下面我们就要定义一个自动配置类了，在自动配置类当中来声明AliOSSUtils的bean对象。
AliOSSAutoConfiguration类：
AliOSSProperties类：
AliOSSUtils类：
在aliyun-oss-spring-boot-autoconfigure模块中的resources下，新建自动配置文件：
META-
INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.impo rts
1 com.aliyun.oss.AliOSSAutoConfiguration
阿里云OSS的starter我们刚才已经定义好了，接下来我们就来做一个测试。
今天的课程资料当中，提供了一个自定义starter的测试工程。我们直接打开文件夹，里面有一个测试工程。测试工程就是springboot-autoconfiguration-test，我们只须要将测试工程直接导入到Idea当中即可。
测试前预备：
在test工程中引入阿里云starter依赖
通过依赖通报，会把autoconfigure依赖也引入了
在test工程中的application.yml文件中，配置阿里云OSS配置参数信息（从以前的工程中拷贝即可）
- 在test工程中的UploadController类编写代码
编写完代码后，我们启动当前的SpringBoot测试工程：
随着SpringBoot项目启动，自动配置会把AliOSSUtils的bean对象装配到IOC容器中
用postman工具进行文件上传：
通过断点可以看到自动注入AliOSSUtils的bean对象：
4.Web后端开辟总结
到此基于SpringBoot进行web后端开辟的相关知识我们已经学习完毕了。下面我们一起针对这段web课程做一个总结。
我们来回首一下关于web后端开辟，我们都学习了哪些内容，以及每一块知识，具体是属于哪个框架的。
web后端开辟如今基本上都是基于标准的三层架构进行开辟的，在三层架构当中，Controller控制器层负责接收哀求相应数据，Service业务层负责具体的业务逻辑处理，而Dao数据访问层也叫持久层，就是用来处理数据访问操作的，来完成数据库当中数据的增删改查操作。
在三层架构当中，前端发起哀求起首会到达Controller(不进行逻辑处理)，然后Controller会直接调用Service 进行逻辑处理， Service再调用Dao完成数据访问操作。
假如我们在执行具体的业务处理之前，须要去做一些通用的业务处理，好比：我们要进行同一的登录校验，我们要进行同一的字符编码等这些操作时，我们就可以借助于Javaweb当中三大组件之一的过滤器 Filter大概是Spring当中提供的拦截器Interceptor来实现。
而为了实现三层架构层与层之间的解耦，我们学习了Spring框架当中的第一大核心：IOC控制反转与DI依赖注入。
所谓控制反转，指的是将对象创建的控制权由应用步伐自身交给外部容器，这个容器就是我们常说的IOC容器或Spring容器。
而DI依赖注入指的是容器为步伐提供运行时所须要的资源。
除了IOC与DI我们还讲到了AOP面向切面编程，另有Spring中的事件管理、全局异常处理器，以及通报会话技术Cookie、Session以及新的会话跟踪解决方案JWT令牌，阿里云OSS对象存储服务，以及通过 Mybatis持久层架构操作数据库等技术。
我们在学习这些web后端开辟技术的时候，我们都是基于主流的SpringBoot进行整合利用的。而 SpringBoot又是用来简化开辟，进步开辟效率的。像过滤器、拦截器、IOC、DI、AOP、事件管理等这些技术到底是哪个框架提供的核心功能？
Filter过滤器、Cookie、 Session这些都是传统的JavaWeb提供的技术。 JWT令牌、阿里云OSS对象存储服务，是如今企业项目中常见的一些解决方案。
IOC控制反转、DI依赖注入、AOP面向切面编程、事件管理、全局异常处理、拦截器等，这些技术
都是 Spring Framework框架当中提供的核心功能。 Mybatis就是一个持久层的框架，是用来操作数据库的。
在Spring框架的生态中，对web步伐开辟提供了很好的支持，如：全局异常处理器、拦截器这些都是Spring框架中web开辟模块所提供的功能，而Spring框架的web开辟模块，我们也称为：SpringMVC
SpringMVC不是一个单独的框架，它是Spring框架的一部分，是Spring框架中的web开辟模块，是用来简化原始的Servlet步伐开辟的。
外界俗称的SSM，就是由：SpringMVC、Spring Framework、Mybatis三块构成。
基于传统的SSM框架进行整合开辟项目会比较繁琐，而且效率也比较低，以是在如今的企业项目开辟当中，基本上都是直接基于SpringBoot整合SSM进行项目开辟的。
结尾：
至此，我们已沿着 Spring Boot 的原理脉络游历一番，从依赖注入的巧思，到自动化配置的便捷，再到内嵌服务器的高效整合，无一不让人折服。渴望这篇博客不仅为你答疑解惑，更犹如一束光，照亮你后续深入学习、优化项目以致自主创新的技术之路，愿你在编程的浩繁星空中持续闪灼。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 | 
