作为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 到配置文件的形式。

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

上面的文档中也提到了，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中，如下所示：

@Servicepublic 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;@RestControllerpublic 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, 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的开发者，同时也建议大家，在日常的开发中我们需要多看看底层的源码，通过不断的看源码，我们能更好的理解特性的实现原理，从而加强我们自身的能力。

关键词：