图文并茂，Spring Boot Starter 万字详解。还有谁不会？-阿里云开发者社区

一、SpringBoot的starter简介

1.1 什么是starter（场景启动器）

在SpringBoot出现之前，如果我们想使用SpringMVC来构建我们的web项目，必须要做的几件事情如下：

首先项目中需要引入SpringMVC的依赖

在web.xml中注册SpringMVC的DispatcherServlet，并配置url映射

编写springmcv-servlet.xml，在其中配置SpringMVC中几个重要的组件，处理映射器（HandlerMapping）、处理适配器（HandlerAdapter）、视图解析器（ViewResolver）

在applicationcontext.xml文件中引入springmvc-servlet.xml文件

…

以上这几步只是配置好了SpringMVC，如果我们还需要与数据库进行交互，就要在application.xml中配置数据库连接池DataSource，如果需要数据库事务，还需要配置TransactionManager…

这就是使用Spring框架开发项目带来的一些的问题：

依赖导入问题：每个项目都需要来单独维护自己所依赖的jar包，在项目中使用到什么功能就需要引入什么样的依赖。手动导入依赖容易出错，且无法统一集中管理

配置繁琐：在引入依赖之后需要做繁杂的配置，并且这些配置是每个项目来说都是必要的，例如web.xml配置（Listener配置、Filter配置、Servlet配置）、log4j配置、数据库连接池配置等等。这些配置重复且繁杂，在不同的项目中需要进行多次重复开发，这在很大程度上降低了我们的开发效率

而在SpringBoot出现之后，它为我们提供了一个强大的功能来解决上述的两个痛点，这就是SpringBoot的starters（场景启动器）。

Spring Boot通过将我们常用的功能场景抽取出来，做成的一系列场景启动器，这些启动器帮我们导入了实现各个功能所需要依赖的全部组件，我们只需要在项目中引入这些starters，相关场景的所有依赖就会全部被导入进来，并且我们可以抛弃繁杂的配置，仅需要通过配置文件来进行少量的配置就可以使用相应的功能。

二、SpringBoot场景启动器的原理

在导入的starter之后，SpringBoot主要帮我们完成了两件事情：

相关组件的自动配置

这两件事情统一称为SpringBoot的自动配置

2.1 自动配置原理

2.1.1 自动配置类的获取与注入

我们从主程序入口来探索一下整个过程的原理：

@SpringBootApplication //标注这个类是一个springboot的应用

public class CommunityApplication {

public static void main(String[] args) {

//将springboot应用启动

SpringApplication.run(CommunityApplication.class, args);

}

Spring Boot 基础就不介绍了，推荐下这个实战教程： https://github.com/javastacks/spring-boot-best-practice

@SpringBootApplication注解内部结构如下图所示：

结论：

SpringBoot在启动的时候从类路径下的META-INF/spring.factories中获取EnableAutoConfiguration指定的所有自动配置类的全限定类名

将这些自动配置类导入容器，自动配置类就生效，帮我们进行自动配置工作；

整个J2EE的整体解决方案和自动配置都在spring-boot-autoconfigure的jar包中；

它会给容器中导入非常多的自动配置类（xxxAutoConfiguration）, 就是给容器中导入这个场景需要的所有组件，并配置好这些组件；

有了自动配置类，免去了我们手动编写配置注入功能组件等的工作；

2.1.2 自动配置的过程

自动配置类被注入到容器当中后，会帮我们进行组件的自动配置和自动注入的工作，我们以HttpEncodingAutoConfiguration（Http编码自动配置）为例解释这个过程：

首先我们先看下SpringBoot中配置文件与POJO类之间映射的方法，这是进行自动配置的基础。

配置集中化管理：SpringBoot中所有可配置项都集中在一个文件中（application.yml），这个文件中的配置通过@ConfigurationProperties注解来与我们程序内部定义的POJO类来产生关联，这些POJO类统一命名为xxxProperties，并且这些xxxProperties类中各个属性字段都有自己的默认值，这也是SpringBoot约定大于配置理念的体现，尽可能减少用户做选择的次数，但同时又不失灵活性。只要我们想，配置文件中的配置随时可以覆盖默认值。

之后，通过配合@EnableConfigurationProperties注解，就可以自动将与配置文件绑定好的这个类注入到容器中供我们使用。

自动配置类的工作流程：

根据限定的条件向容器中注入组件

使用xxxProperties对注入的组件的相关属性进行配置

//表示这是一个配置类，和以前编写的配置文件一样，也可以给容器中添加组件；
@Configuration
//将与配置文件绑定好的某个类注入到容器中，使其生效
//进入这个HttpProperties查看，将配置文件中对应的值和HttpProperties绑定起来；
//并把HttpProperties加入到ioc容器中
@EnableConfigurationProperties(HttpProperties.class)
//Spring底层@Conditional注解
//根据不同的条件判断，如果满足指定的条件，整个配置类里面的配置就会生效；
//这里的意思就是判断当前应用是否是web应用，如果是，当前配置类生效
@ConditionalOnWebApplication(type = ConditionalOnWebApplication.Type.SERVLET)
//判断系统中有没有CharacterEncodingFilter这个类，如果有配置类才生效
@ConditionalOnClass(CharacterEncodingFilter.class)
//判断配置文件中是否存在某个配置：spring.http.encoding.enabled；
//matchIfMissing = true表明即使我们配置文件中不配置pring.http.encoding.enabled=true，该配置类也是默认生效的；
@ConditionalOnProperty(prefix = "spring.http.encoding", value = "enabled", matchIfMissing = true)
public class HttpEncodingAutoConfiguration {
  //该类已经与配置文件绑定了
 private final HttpProperties.Encoding properties;
  //构建该自动配置类时将与配置文件绑定的配置类作为入参传递进去
 public HttpEncodingAutoConfiguration(HttpProperties properties) {
  this.properties = properties.getEncoding();
 }
 @Bean
 @ConditionalOnMissingBean
 public CharacterEncodingFilter characterEncodingFilter() {
  CharacterEncodingFilter filter = new OrderedCharacterEncodingFilter();
  filter.setEncoding(this.properties.getCharset().name()); //注入bean时使用配置类中属性的值进行初始化，相当于将配置文件中的值映射到了组件的某些属性上
  filter.setForceRequestEncoding(this.properties.shouldForce(Type.REQUEST));
  filter.setForceResponseEncoding(this.properties.shouldForce(Type.RESPONSE));
  return filter; //注入配置好的bean
 }
}

一句话总结下自动配置类的工作过程：

首先容器会根据当前不同的条件判断，决定这个配置类是否生效！

一但这个配置类生效；这个配置类就会给容器中添加相应组件；

这些组件的属性是从对应的properties类中获取的，这些类里面的每一个属性又是和配置文件绑定的；

所有在配置文件中能配置的属性都是在xxxxProperties类中封装着，配置文件可以配置什么内容，可以参照该前缀对应的属性类中的属性字段

//从配置文件中获取指定的值和bean的属性进行绑定

@ConfigurationProperties(prefix = "spring.http")

public class HttpProperties {

// .....

}

2.2 SpringBoot自动配置使用总结

SpringBoot启动会加载大量的自动配置类

我们首先可以看我们需要的功能有没有在SpringBoot默认写好的自动配置类当中；

我们再来看这个自动配置类中到底配置了哪些组件；（只要我们要用的组件存在在其中，我们就不需要再手动配置了）

给容器中自动配置类添加组件的时候，会从properties类中获取某些属性。我们只需要在配置文件中指定这些属性的值即可；

xxxxAutoConfigurartion：自动配置类；给容器中添加组件

xxxxProperties：封装配置文件中相关属性；

了解完自动装配的原理后，我们来关注一个细节问题，自动配置类必须在一定的条件下才能生效；@Conditional派生注解（Spring注解版原生的@Conditional作用）

作用：必须是@Conditional指定的条件成立，才给容器中添加组件，配置里面的所有内容才生效；

三、自定义场景启动器

现在我们已经了解了场景启动器的概念以及其隐藏在背后的自动配置的原理，我们就可以自己来对SpringBoot进行功能拓展，定义我们自己的场景启动器。

3.1 starter的命名规范

官方命名空间

前缀：spring-boot-starter-

模式：spring-boot-starter-模块名

举例：spring-boot-starter-web、spring-boot-starter-jdbc

自定义命名空间

后缀：-spring-boot-starter

模式：模块-spring-boot-starter

举例：mybatis-spring-boot-starter

推荐一个 Spring Boot 基础教程及实战示例： https://github.com/javastacks/spring-boot-best-practice

3.2 starter模块整体结构

通过上边的介绍，可以总结starter的整体实现逻辑主要由两个基本部分组成：

xxxAutoConfiguration：自动配置类，对某个场景下需要使用到的一些组件进行自动注入，并利用xxxProperties类来进行组件相关配置

xxxProperties：某个场景下所有可配置属性的集成，在配置文件中配置可以进行属性值的覆盖按照SpringBoot官方的定义，Starer的作用就是依赖聚合，因此直接在starter内部去进行代码实现是不符合规定的，starter应该只起到依赖导入的作用，而具体的代码实现应该去交给其他模块来实现，然后在starter中去引用该模块即可，因此整体的starter的构成应该如下图所示：

可见starter模块依赖了两部分，一部分是一些常用依赖，另一部分就是对自动配置模块的依赖，而xxxAutoConfiguration与xxxProperties的具体实现，都封装在自动配置模块中，starter实际是通过该模块来对外提供相应的功能。

3.3 autoconfigure模块开发

3.3.1 依赖引入

首先所有的自动配置模块都要引入两个jar包依赖：

<dependencies>
     <dependency>
         <groupId>org.springframework.boot</groupId>
         <artifactId>spring-boot-autoconfigure</artifactId>
        <!-- 包含很多与自动配置相关的注解的定义，必须要引入 -->
     </dependency>
     <dependency>
         <groupId>org.springframework.boot</groupId>
         <artifactId>spring-boot-configuration-processor</artifactId>
       <!-- 非必须的，引入后可以在配置文件中输入我们自定义配置的时候有相应的提示，也可以通过其他.properties文件为相关类进行属性映射（SpringBoot默认使用application.yml)-->
         <optional>true</optional>
     </dependency>
 <dependencies>