1 前言

能自由选择真是太棒了。如果你订过比萨就会知道，你完全可以掌控薄饼上放哪些辅料。选定腊肠、意大利辣香肠、青辣椒和额外芝士的时候，你就是在按照自己的要求配置比萨。另一方面，大部分比萨店也提供某种形式的自动配置。你可以点荤比萨、素比萨、香辣意大利比萨，或者是自动配置比萨中的极品——至尊比萨。在下单时，你并没有指定具体的辅料，你所点的比萨种类决定了所用的辅料。但如果你想要至尊比萨上的全部辅料，还想要加墨西哥胡椒，又不想放蘑菇该怎么办？你偏爱辣食又不喜欢吃菌类，自动配置不适合你的口味，你就只能自己配置比萨了吗？当然不是，大部分比萨店会让你以菜单上已有的选项为基础进行定制。

2 自动配置

Spring Boot的自动配置是应用程序启动时的过程，考虑了众多因素，才决定Spring配置应该用哪个，不该用哪个。举几个例子，下面这些情况都是Spring Boot的自动配置要考虑的。

Spring的JdbcTemplate是不是在Classpath里？如果是，并且有DataSource的Bean，则自动配置一个JdbcTemplate的Bean。Spring Security是不是在Classpath里？如果是，则进行一个非常基本的Web安全设置。

每当应用程序启动的时候，Spring Boot的自动配置都要做将近200个这样的决定，涵盖安全、集成、持久化、Web开发等诸多方面。所有这些自动配置就是为了尽量不让你自己写配置。由此可见，Spring Boot自动配置承担起了配置Spring的重任，因此你能专注于编写自己的应用程序。

• 基于条件的自动配置基于条件的自动配置来源于Spring框架中“基于条件的配置”这一特性。在Spring框架中，我们可以使用@Conditional这个Annotation配合@Configuration或者@Bean等Annotation来干预一个配置或者bean定义是否能够生效。SpringBoot能够风靡，很大一部分功劳需要归功于它预先提供的一系列自动配置的依赖模块，而这些依赖模块都是基于以上@Conditional复合Annotation实现的，这也意味着所有的这些依赖模块都是按需加载的，只有符合某些特定条件，这些依赖模块才会生效，这也就是我们所谓的“智能”自动配置。
• 调整自动配置的顺序在实现自动配置的过程中，除了可以提供基于条件的配置，我们还可以对当前要提供的配置或者组件的加载顺序进行相应调整，从而让这些配置或者组件之间的依赖分析和组装可以顺利完成。我们可以使用@org.springframework.boot.autoconfigure.AutoConfigureBefore或者@org.springframework.boot.autoconfigure.AutoConfigureAfter让当前配置或者组件在某个其他组件之前或者之后进行。如下配置：
  @Configuration@AutoConfigureAfter(MyTestBefore.class)
  public class MyTestAfter {
  ...
  }

3 自定义配置

使用传统Spring配置的过程，就如同订比萨的时候自己指定全部的辅料。你可以完全掌控Spring配置的内容，可是显式声明应用程序里全部的Bean并不是明智之举。而Spring Boot自动配置就像是从菜单上选一份特色比萨，让Spring Boot处理各种细节比自己声明上下文里全部的Bean要容易很多。 幸运的是，Spring Boot自动配置非常灵活。就像比萨厨师可以不在你的比萨里放蘑菇，而是加墨西哥胡椒一样，Spring Boot能让你参与进来，影响自动配置的实施。

3.1 覆盖自动配置

大多数情况下，自动配置的Bean刚好能满足你的需要，不需要去覆盖它们。但某些情况下，Spring Boot在自动配置时还不能很好地进行推断。让我们看看如何写出Spring Secuirty配置，覆盖自动配置的安全设置吧。在编写显式配置时，我们会专注于Java形式的配置。在Spring Security的场景下，这意味着写一个扩展了WebSecurityConfigurerAdapter的配置类。示例代码如下：

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    //省略
    @Override
    public void configure(WebSecurity web) throws Exception {
        web.ignoring().antMatchers("/js/**");
        web.ignoring().antMatchers("/css/**");
        web.ignoring().antMatchers("/health");
        // 忽略登录界面
        web.ignoring().antMatchers("/login.html");
        web.ignoring().antMatchers("/index.html");
    }
    
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.csrf().disable();

        http.authorizeRequests()
                .anyRequest().authenticated();
        http.formLogin().loginPage("/login.html").loginProcessingUrl("/user/login")
                .successHandler(authenticationSuccessHandler).failureHandler(authenticationFailureHandler);
        
        // 解决不允许显示在iframe的问题
        http.headers().frameOptions().disable();
        http.headers().cacheControl();
    }
    //省略
}

在SecurityConfig里，第一个configure()方法重写了默认READER角色的用户的访问权限规则。第二个configure()方法重写了对特定的http请求基于安全考虑进行配置。

想要覆盖Spring Boot的自动配置，你所要做的仅仅是编写一个显式的配置。想弄明白这是如何实现的，让我们揭开Spring Boot自动配置的神秘面纱，看看它是如何运作的，以及它是怎么允许自己被覆盖的。

3.2 自动配置的神秘面纱

Spring Boot自动配置自带了很多配置类，每一个都能运用在你的应用程序里。它们都使用了Spring 4.0的条件化配置，可以在运行时判断这个配置是该被运用，还是该被忽略。大部分情况下@ConditionalOnMissingBean注解是覆盖自动配置的关键。Spring Boot的DataSourceAutoConfiguration中定义的JdbcTemplate Bean就是一个非常简单的例子：

@Bean
@ConditionalOnMissingBean(JdbcOperations.class)
public JdbcTemplate jdbcTemplate() {  
    return new JdbcTemplate(this.dataSource);
}

jdbcTemplate()方法上添加了@Bean注解，在需要时可以配置出一个JdbcTemplate Bean。但它上面还加了@ConditionalOnMissingBean注解，要求当前不存在JdbcOperations类型（JdbcTemplate实现了该接口）的Bean时才生效。如果当前已经有一个JdbcOperations Bean了，条件即不满足，不会执行jdbcTemplate()方法。

什么情况下会存在一个JdbcOperations Bean呢？Spring Boot的设计是加载应用级配置，随后再考虑自动配置类。因此，如果你已经配置了一个JdbcTemplate Bean，那么在执行自动配置时就已经存在一个JdbcOperations类型的Bean了，于是忽略自动配置的JdbcTemplate Bean。

虽然Spring Boot的自动配置和@ConditionalOnMissingBean让你能显式地覆盖那些可以自动配置的Bean，但并不是每次都要做到这种程度。让我们来看看怎么通过设置几个简单的配置属性调整自动配置组件吧。

3.3 通过属性文件外置配置

在处理应用安全时，你当然会希望完全掌控所有配置。不过，为了微调一些细节，比如改改端口号和日志级别，便放弃自动配置，这是一件让人羞愧的事。为了设置数据库URL，是配置一个属性简单，还是完整地声明一个数据源的Bean简单？答案不言自明，不是吗？ 事实上，Spring Boot自动配置的Bean提供了300多个用于微调的属性。当你调整设置时，只要在环境变量、Java系统属性、JNDI（Java Namingand Directory Interface）、命令行参数或者属性文件里进行指定就好了。

Spring Boot有一个ascii-artBanner。如果你想禁用这个Banner，可以将spring.main.show-banner属性设置为false。有几种实现方式：

• 运行应用程序的命令行参数里指定

$ java -jar fs-base-service-1.0-SNAPSHOT.jar --spring.main.show-banner=fals

• 在application.properties的文件配置

spring.main.show-banner=fals

• 在application.yml的文件配置

spring:
  main:
    show-banner: false

实际上，Spring Boot应用程序有多种设置途径。Spring Boot能从多种属性源获得属性，包括如下几处。 （1）命令行参数 （2）操作系统环境变量 （3）应用程序以外的application.properties或者appliaction.yml文件 （4）打包在应用程序内的application.properties或者appliaction.yml文件 （5）通过@PropertySource标注的属性源 （6）默认属性 这个列表按照优先级排序，也就是说，任何在高优先级属性源里设置的属性都会覆盖低优先级的相同属性。例如，命令行参数会覆盖其他属性源里的属性。application.properties和application.yml文件能放在以下四个位置。 （1）外置，在相对于应用程序运行目录的/config子目录里。 （2）外置，在应用程序运行的目录里。 （3）内置，在config包内。 （4）内置，在Classpath根目录。 同样，这个列表按照优先级排序。也就是说，/config子目录里的application.properties会覆盖应用程序Classpath里的application.properties中的相同属性。 此外，如果你在同一优先级位置同时有application.properties和application.yml，那么application.yml里的属性会覆盖application.properties里的属性。

3.3.1 在一个类里收集属性

虽然我们可以在service或controller层加上ConfigurationProperties注解，这样运行起来也没问题，但这不是一个理想的方案。与其在ReadingListController里加载配置属性，还不如创建一个单独的Bean，为它加上@ConfigurationProperties注解，让这个Bean收集所有配置属性。如下所示：

@Component
@ConfigurationProperties("fs")  //注入带fs前缀的属性
public class DBConfig {
      private String ip;
    
        public String getIp() {
        return ip;
    }

    public void setIp(String ip) {
        this.ip = ip;
    }
}

3.3.2 使用Profile进行配置

当应用程序需要部署到不同的运行环境时，一些配置细节通常会有所不同。比如，数据库连接的细节在开发环境下和测试环境下就会不一样，在生产环境下又不一样。Spring Framework从Spring 3.1开始支持基于Profile的配置。Profile是一种条件化配置，基于运行时激活的Profile，会使用或者忽略不同的Bean或配置类。设置spring.profiles.active属性就能激活Profile，任意设置配置属性的方式都能用于设置这个值。例如，在命令行里运行应用程序时，可以这样激活production Profile：

$ java -jar fs-base-service-1.0-SNAPSHOT.jar -- spring.profiles.active=dev

也可以向application.yml里添加spring.profiles.active属性：

spring:
  profiles:    
    active: dev

• 使用特定于Profile的属性文件

如果你正在使用application.properties，可以创建额外的属性文件，遵循application-{profile}.properties这种命名格式，这样就能提供特定于Profile的属性了。在日志这个例子里，开发环境的配置可以放在名为application-dev.properties的文件里，配置包含日志级别和输出到控制台：logging.level.root=DEBUG。对于生产环境，application-prod.properties会将日志级别设置为WARN或更高级别。

• 使用多Profile YAML文件进行配置

如果使用YAML来配置属性，则可以遵循与配置文件相同的命名规范，即创建application{profile}.yml这样的YAML文件，并将与Profile无关的属性继续放在application.yml里。 但既然用了YAML，你就可以把所有Profile的配置属性都放在一个application.yml文件里。举例来说，我们可以像下面这样声明日志配置：

logging:
  level:
    root: INFO
---
spring:  
    profiles: dev
logging:
  level:
    root: DEBUG
---spring:  
    profiles: prod
logging:
   level:
     root: WARN

如你所见，这个application.yml文件分为三个部分，使用一组三个连字符（---）作为分隔符。第二段和第三段分别为spring.profiles 指定了一个值，这个值表示该部分配置应该应用在哪个Profile里。第二段中定义的属性应用于开发环境，因为spring.profiles 设置为dev。与之类似，最后一段的spring.profile设置为prod，在prodProfile被激活时生效。 另一方面，第一段并未指定spring.profiles，因此这里的属性对全部Profile都生效，或者对那些未设置该属性的激活Profile生效。

4 总结

Spring Boot消除了Spring应用程序中经常要用到的很多样板式配置。让Spring Boot处理全部配置，你可以仰仗它来配置那些适合你的应用程序的组件。当自动配置无法满足需求时，Spring Boot允许你覆盖并微调它提供的配置。

覆盖自动配置其实很简单，就是显式地编写那些没有Spring Boot是你要做的Spring配置。Spring Boot的自动配置被设计为优先使用应用程序提供的配置，然后才轮到自己的自动配置。 即使自动配置合适，你仍然需要调整一些细节。Spring Boot会开启多个属性解析器，让你通过环境变量、属性文件、YAML文件等多种方式来设置属性，以此微调配置。这套基于属性的配置模型也能用于应用程序自己定义的组件，可以从外部配置源加载属性并注入到Bean里。

Spring Boot中参数的传递过程和配置文件的加载，特别是基于profile的加载机制。而关于加载、默认配置、配置优先级等操作，都位于ConfigFileApplicationListener类中，该类还是值得读者朋友花时间研究一下的。