作为 Java​ 程序员，相信大家都知道，我们日常的 SpringBoot​ 项目会有一个配置文件 application.properties 文件。

里面会配置很多参数，例如服务的端口等，这些都只是默认值，在不改变配置文件里面内容的情况下，我们可以通过在部署的时候，传递一个相应的参数来替换默认的参数。

那么问题来了，你有想过为什么可以这样吗？为什么 SpringBoot 部署时传递的启动配置会生效，而配置文件中的配置就不生效了呢？或者说这两者的优先级是什么样子的呢？

外部化配置

要解释上面的问题，我们就需要知道 SpringBoot 到底支持哪些配置形式，以及这些配置方式的优先级是什么样子的，只有搞清楚了这个，才能真正的解决配置的优先级问题。

在 SpringBoot 的官方文档中我们可以看到这么一段描述

用了不起我拙劣的英语翻译一下，大概的意思就是：Spring Boot​ 提供了将配置文件外部化的功能，这样您就可以在不同环境下使用相同的应用程序代码。您可以使用 properties​ 文件、YAML 文件、环境变量以及命令行参数来外部化配置文件。

通过 @Value​ 注解，属性值可以直接注入到 beans​ 中，通过 Environment abstraction​（环境映射）可以访问其他位置，或者使用 @ConfigurationProperties 绑定结构化对象。

有哪些外部配置

既然上面提到了 SpringBoot​ 提供了外部化配置，那么 SpringBoot 提供了哪些配置呢？依然是通过官方文档，我们可以看到有如下配置列表

从上图可以看到 SpringBoot 总共内置了 17 种外部化配置方法，而且这 17 种的优先级是从上到下依次优先的。这些方式中我们常用的有 4 命令行方法，9 Java 系统环境变量，10 操作系统环境变量，以及 12 到 15 到配置文件的形式。

通过上面的顺序我们就可以解释为什么我们通过命令行配置的参数会生效，而配置文件中的默认值就会忽略了，从而达到了覆盖配置的目的。

PropertySource

上面的文档中也提到了，SpringBoot​ 主要是通过 PropertySource​ 机制来实现多样属性源的，SpringBoot​ 的 PropertySource​ 是一种机制，用于加载和解析配置属性，可以从多种来源获取这些属性，例如文件、系统环境变量、JVM​ 系统属性和命令行参数等。PropertySource​ 是 Spring 框架中的一个抽象接口，它定义了如何读取属性源的方法。

通过 SpringBoot​ 的代码，我们可以看到，org.springframework.core.env.PropertySource​ 是一个抽象类，实现在子类有很多，我们上面提到的命令行 PropertySource​ 是 org.springframework.core.env.CommandLinePropertySource。整体的类图如下，涵盖的内容还是很多的，感兴趣的小伙伴可以好好研究一番。

另外在 SpringBoot​ 中，我们还可以使用 @PropertySource 注解来自定义指定要加载的属性文件。例如，可以在应用程序的主类上添加以下注解：

@SpringBootApplication
@PropertySource("classpath:customer.properties")
public class CustomerProperties {
// ...
}

这将告诉 SpringBoot​ 在 classpath​ 下查找名为 customer.properties​ 的文件，并将其加载为属性源。然后，可以使用 @Value​注解将属性值注入到 bean 中，如下所示：

@Service
public class MyService {
@Value("${my.property}")
private String myProperty;
// ...
}

这里的 ${my.property}​ 是从 customer.properties​ 文件中获取的属性值。如果找不到该属性，那么 SpringBoot 将使用默认值，这里因为是自定义的属性，是没有默认值的，就会报错，项目无法启动。

具体实现是，SpringBoot​ 在启动时会自动加载和解析所有的 PropertySource​，包括默认的 PropertySource​ 和自定义的PropertySource​。这些属性值被存储在 Spring​ 环境中，可以通过 Spring​ 的 Environment​ 对象访问。当属性被注入到 bean​ 中时， Spring​ 会查找 Environment 对象并尝试解析属性的值。

总之，SpringBoot​ 的 PropertySource​ 提供了一种简单的方法来加载和解析应用程序的配置属性，这些属性可以从多个来源获取。它通过将属性值存储在 Spring 环境中，使其易于在应用程序的不同部分中使用。

调试

为了验证上面说的命令行的参数配置要优先于配置文件，我们创建一个 SpringBoot 项目，并且在 application.properties​ 文件中配置一个参数 name=JavaGeekTech​，而在 IDEA 启动窗口中配置 name=JAVA_JIKEJUSHU，分别如下所示

在写一个简单的 HelloController​ 类，并且通过 @Value​ 注解注入 name​ 属性，接下来我们就需要调试看下，SpringBoot​是如何将 name​ 属性赋值的。通过验证 name​ 会被赋值成 JAVA_JIKEJISHU​ 而不是 JavaGeekTech。

package com.example.demo.controller;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class HelloController {

@Value("${name}")
private String name;

@GetMapping(value = "/hello")
public String hello() {
return helloService.sayHello(name);
}

}

接着我们启动 debug​，因为我们是基于 SpringBoot​ 的，属性的赋值是在创建 bean​ 的时候，从 createBean​，到 doCreateBean​，再到 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#populateBean​，因为每个 bean​ 都会经过很多 PostProcessor​ 的处理，属性赋值的 PostProcessor​ 是 org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor#postProcessProperties

里面的 metadata.inject​ 会调用到 org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.AutowiredFieldElement#inject​，再到 org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.AutowiredFieldElement#resolveFieldValue，

org.springframework.beans.factory.support.DefaultListableBeanFactory#resolveDependency，

org.springframework.beans.factory.support.DefaultListableBeanFactory#doResolveDependency，

org.springframework.beans.factory.support.AbstractBeanFactory#resolveEmbeddedValue，

org.springframework.core.env.AbstractPropertyResolver#resolveRequiredPlaceholders，

org.springframework.core.env.PropertySourcesPropertyResolver#getPropertyAsRawString，

org.springframework.core.env.PropertySourcesPropertyResolver#getProperty(java.lang.String, java.lang.Class<T>, boolean)

整体调用链还是挺长的，不过只要跟着思路，在配合断点，还是可以看看看出来的。

在 getProperty​ 方法中，我们可以看到如下的逻辑，根据 key​ 获取到的 value​ 值为JAVA_JIKEJISHU。

继续跟踪 getProperty​ 方法，我们可以看到这个方法 org.springframework.boot.context.properties.source.ConfigurationPropertySourcesPropertySource#findConfigurationProperty(org.springframework.boot.context.properties.source.ConfigurationPropertyName)，

其中的 getSource() 中就有我们配置的两个属性源的数据，如下所示

根据代码逻辑，我们也可以看到，在迭代的时候，如果找到了一个就直接返回了，所以得到的结果是JAVA_JIKEJISHU。

总结

今天了不起带大家研究了一个 SpringBoot​ 的外部化配置，并且通过实际的一个 case 跟踪代码的调用链来给大家测试了一下，虽然说这个知识点我们经常都在使用，但是没看到底层源码的时候我们并不知道这样的一个功能底层是怎样的复杂的。

这里还是要敬佩一下 SpringBoot 的开发者，同时也建议大家，在日常的开发中我们需要多看看底层的源码，通过不断的看源码，我们能更好的理解特性的实现原理，从而加强我们自身的能力。