SpringBoot2.x入门教程：理解配置文件

前提

这篇文章是《SpringBoot2.x入门》专辑的第4篇文章，使用的SpringBoot版本为2.3.1.RELEASE，JDK版本为1.8。

主要介绍SpringBoot配置文件一些经常使用属性、配置文件的加载优先级以及一些和配置相关的注意事项。

关于SpringBoot的配置文件

一个基于标准的引入了SpringBoot组件的Maven项目的结构通常以下：

Root（项目根目录）
  - src
   - main
    - java
    - resources  # <-- 这个就是资源文件的存放目录
  - target   
  pom.xml

资源文件存放在src/main/resouces目录下，而配置文件本质上也是资源文件，因此项目内的配置文件就存放于该目录下。从SpringBoot的属性源加载器PropertySourceLoader的实现来看，目前支持Properties和Yaml两种配置文件类型。二者各有优点：Yaml的配置属性更灵活，而Properties的配置不容易出错（笔者前公司的技术规范中明确了SpringBoot应用必须使用Properties配置文件，由于运维或者开发同事曾由于生产配置使用了Yaml格式的文件，编辑期间由于空格问题致使了严重的生产故障）。下文会使用Properties配置文件做为示例。

SpringBoot的配置文件使用了profile（profile自己就有剖面、配置文件的含义，下面会把profile做为一个专有名词使用）的概念，能够类比为区分不一样环境的标识符，一个SpringBoot应用容许使用多个profile，因此配置文件的格式必须为application-${profile}.文件后缀，例如：

src/main/resources
   - application.properties
   - application-dev.properties  # <-- profile = dev，开发环境配置
   - application-test.properties # <-- profile = test，测试环境配置

其中不带profile标识的application.properties，能够理解为主配置文件，也就是SpringBoot的配置文件其实有继承关系，项目启动时，主配置文件不管如何都会优先加载，而后被激活的profile标识的配置文件才会加载，能够经过属性spring.profiles.active指定激活哪个profile配置文件，如：

# 指定加载application-dev.properties
spring.profiles.active=dev

# 或者同时加载application-dev.properties和application-test.properties
spring.profiles.active=dev,test

spring.profiles.active通常能够在主配置文件application.properties中指定，获取经过启动命令参数指定（java -jar -Dspring.profiles.active=prod app.jar或者java -jar app.jar --spring.profiles.active=prod）。

能够经过自动装配org.springframework.core.env.Environment，经过Environment#getActiveProfiles()获取当前激活的profile数组，例如：

import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.CommandLineRunner;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.core.env.Environment;
import java.util.Arrays;

@Slf4j
@SpringBootApplication
public class Ch2Application implements CommandLineRunner {

    @Autowired
    private Environment environment;

    public static void main(String[] args) {
        SpringApplication.run(Ch2Application.class, args);
    }

    @Override
    public void run(String... args) throws Exception {
        log.info("Active profiles:{}", Arrays.toString(environment.getActiveProfiles()));
    }
}

运行结果以下：

这里用到了CommandLineRunner接口做为展现，后面的文章会介绍该接口的使用方式。

经常使用的基本配置属性

通常状况下会引入spring-boot-starter-web开发web项目，有几个基本配置笔者认为是必须的。主配置文件application.properties中应该标识应用名和默认选用的profile，例如API网关的主配置文件以下：

spring.application.name=api-gateway
spring.profiles.active=dev

此外，主配置中间中应该配置一些不容易变更的属性，例如Mybatis的Mapper扫描路径、模板引擎Freemarker的配置属性等等。而profile标识的配置文件中，应该配置一些跟随环境变化的配置或者常常更变的属性，例如MySQL数据源的配置、Redis的链接配置等等，以便经过spring.profiles.active直接切换不一样环境的中间件链接属性或者第三方配置。在Hello World类型的项目中，通常添加server.port指定容器的启动端口，如application-dev.properties的内容以下：

server.port=8081

配置文件加载优先级与属性覆盖

除了主配置文件会优先profile标识的配置文件加载以外，SpringBoot还支持经过文件系统加载配置文件，这些配置文件不必定在项目内（准确来讲是项目编译以后打出来的包内），还能够存在于特定的磁盘路径中。这一点能够参考SpringBoot官方文档2.Externalized Configuration一节：

默认的配置文件加载优先级顺序是：

1. file:./config/（项目部署包所在目录的同级config目录下的application-[profile].[properties,yaml]文件）
2. file:./config/*/（项目部署包所在目录的同级config目录下的任意子目录中的application-[profile].[properties,yaml]文件）
3. file:./（项目部署包所在目录的application-[profile].[properties,yaml]文件）
4. classpath:/config/（项目部署包内类路径下的config目录下的application-[profile].[properties,yaml]文件）
5. classpath:/（项目部署包内类路径下的application-[profile].[properties,yaml]文件）

眼尖的伙伴可能会发现，在项目中的resources目录下添加的配置文件的加载优先级是最低的（打包后至关于第5条）。能够经过spring.config.location属性覆盖上面的顺序，如spring.config.location=classpath:/,classpath:/config/，通常不建议改变默认的配置顺序，除非有特殊的使用场景。

另外，还能够经过spring.config.additional-location属性指定额外附加的搜索配置文件的路径，而且优先级比默认的配置顺序要高，假如只配置了spring.config.additional-location=classpath:/custom-config/,file:./custom-config/，那么配置文件加载优先级顺序是：

1. file:./custom-config/（项目部署包所在目录的同级custom-config目录下的application-[profile].[properties,yaml]文件）
2. classpath:custom-config/（项目部署包内类路径下的custom-config目录下的application-[profile].[properties,yaml]文件）
3. file:./config/（项目部署包所在目录的同级config目录下的application-[profile].[properties,yaml]文件）
4. file:./config/*/（项目部署包所在目录的同级config目录下的任意子目录中的application-[profile].[properties,yaml]文件）
5. file:./（项目部署包所在目录的application-[profile].[properties,yaml]文件）
6. classpath:/config/（项目部署包内类路径下的config目录下的application-[profile].[properties,yaml]文件）
7. classpath:/（项目部署包内类路径下的application-[profile].[properties,yaml]文件）

基于这个特性，在不对接配置中心的前提下，可让运维伙伴在生产服务器上先配置好服务所需的生产环境的配置文件：

# 假设这个是生产服务器的文件路径
/data/apps/api-gateway
     - api-gateway.jar
     - config
       - application-prod.properties

在编写启动脚本的时候只需指定profile为prod便可，应用会读取/data/apps/api-gateway/config/application-prod.properties的属性，这样就能避免生产配置或者敏感属性泄漏给开发人员。

这里还有一个比较重要的问题就是：若是在多种路径下的配置文件定义了同一个属性，那么属性会依照一个优先级顺序进行覆盖。由于SpringBoot除了配置文件，还支持命令行、JNDI属性、系统属性等等，若是所有列举会比较复杂，这里按照目前分析过的内容列举这个优先级顺序：

1. 命令行中的属性参数。
2. 项目部署包以外的application-profile.[properties,yaml]文件。
3. 项目部署包内的application-profile.[properties,yaml]文件。
4. 项目部署包以外的application.[properties,yaml]文件。
5. 项目部署包内的application.[properties,yaml]文件。

举个例子，假如启动参数中添加--app.author=throwable，配置文件application.properties中添加属性app.author=throwable-x，而配置文件application-dev.properties中添加属性app.author=throwable-y，那么使用profile=dev启动应用的时候，优先获取到的是属性app.author=throwable：

若是看过SpringBoot属性加载的源码可知，其实属性优先级的思路在设计属性加载模块的时候正好相反，全部的配置文件都会进行解析，构成一个复合的PropertySource，后解析的参数老是在顶层，而后获取属性的时候，老是先从顶层获取。

自定义配置属性与IDE亲和性

有时候须要配置自定义属性，会出如今IDE中会没法识别而"标黄"的场景。这个时候能够应用IDE亲和性。在主流的IDE如Eclipse和IntelliJ IDEA中，只须要引入SpringBoot的属性元数据描述文件（spring-configuration-metadata.json或者additional-spring-configuration-metadata.json），便可让IDE识别，提供目录引导跳转的功能，再也不"标黄"。具体的作法是在项目的resources/META-INF目录中引入属性元数据描述文件，而后编写属性描述便可：

// resources/META-INF/spring-configuration-metadata.json
{
  "properties": [
    {
      "name": "app.author",
      "type": "java.lang.String",
      "description": "The author of app."
    }
  ]
}

spring-configuration-metadata.json文件的格式能够参考SpringBoot多个starter中已经存在的文件，完成这一点，代码洁癖患者或者强迫症患者会感受良好。

小结

这篇文章简单总结了配置文件加载的优先级顺序和配置属性的覆盖优先级顺序，这两点须要彻底掌握，能够自行经过一些例子改变一下配置文件进行熟悉。配置属性覆盖的问题很容易致使生产故障，若是掌握了本节的内容，对于SpringBoot配置属性方面的问题应该能够快速定位和解决。代码仓库：

• Github：https://github.com/zjcscut/spring-boot-guide/tree/master/ch2-profile

（本文完 c-2-d e-a-20200705）

技术公众号《Throwable文摘》（id：throwable-doge），不按期推送笔者原创技术文章（毫不抄袭或者转载）：