有本书上总结了一下，大概有9种配置方式，当然还有其他方式，这里不再列举。并且这些配置方式是有优先级的，如果不同的配置方式都配置了同一个配置项，那么优先级高的胜出。下面我们来具体看。
一，Spring Boot支持的配置方式
Spring Boot配置的核心类是PropertySource
下面我们结合源码和测试验证，来具体分析。
1，命令行参数。
什么是命令行参数呢？就是我们启动Spring Boot时，SpringApplication#run方法的入参中的第二个参数args。举个例子：
SpringApplication.run(XxxApplication.class, "--spring.redis.timeout=60000");
这种方式就是命令行参数，但是我们一般不会这样来配置，我们通常是这样写的：
SpringApplication.run(XxxApplication.class, args);
Spring Boot给我们提供了这种方式来配置，实际生产上我们不会使用，平时测试的时候可以使用，可以协助我们定位问题。
对应的解析类：CommandLinePropertySource
2，通过System#getProperties方法获取的java系统参数。
这部分系统参数，本质上是通过System#initProperties这个native方法来获取的，这部分的优先级低于命令行参数配置方式。
举个例子：假如我想覆盖os.name这个配置项，那么我可以使用命令行参数配置方式，如下：
SpringApplication.run(XxxApplication.class, "--os.name=IOS");
从这里，我们也可以看出一个问题：命令行参数配置方式有很大的危险性，加入我通过命令行参数配置方式更改了系统参数，可能对系统来说，是灾难性的。还好，Spring Boot给我们提供了禁用命令行参数配置的功能。
代码如下：
// 创建springApplication实例
SpringApplication springApplication = new SpringApplication(XxxApplication.class);
// 禁用命令行参数
springApplication.setAddCommandLineProperties(false);
springApplication.run("--os.name=IOS");
3，操作系统环境变量。使用Docker启动时，经常会设置系统变量。
这部分系统环境变量，我理解就是通过SyetemEnvironmentProropertySource导入的。正常情况下，也是通过native方法来获取的，个人理解，只有通过命令行参数配置方式可以覆盖，没有其他修改入口。
4，从java:comp/env得到的JNDI属性。
对应的解析类：JndiPropertySource
这种方式比较老了，本质上是通过FactoryBean的方式注入bean到IOC容器。
举个例子：
Spring JNDI数据源配置信息：
关于JNDI的配置(tomcat)：
修改tomcat目录conf/context.xml文件：
maxActive="100" maxIdle="30" maxWait="10000" username="tysp" password="12345678" driverClassName="oracle.jdbc.driver.OracleDriver" url="jdbc:oracle:thin:@192.168.1.1:1521:OA"/> 通过JNDI获取DataSource: Context context = new InitialContext(); DataSource ds = (DataSource)context.lookup("java:comp/env/jcptDataSourceJNDI"); 目前在Spring Boot中，这种方式很少使用了，我们一般是通过配置spring.datasource.*的方式来配置数据源，直接在properties文件或者yml文件中进行配置即可。 5，通过RandomValuePropertySource生成的random.*属性。 对应的解析类：RandomValuePropertySource。 RandomValuePropertySource的使用也很少，Spring为什么要提供这个类呢？个人理解，是为了在应用启动阶段，提供生产随机数的功能，因为有些场景可能会用到，比如每次启动使用随机的参数。一旦进入程序运行阶段的话，我们就可以自己创建一个Random的实例了！ 举个例子： xxx.uuid=${random.uuid} xxx.intValue=${random.int} redis.key.expireTime=${random.int[60000,120000]} 要注意，这个值会在项目启动时生成并固定，每次重新启动项目都会重新生成。 因为RandomValuePropertySource的优先级高于我们的application.properties，所以我们可以在application.properties中使用random对象。 6，应用jar之外的属性文件，如通过spring.config.location参数指定的属性文件。 Spring boot 的Application.properties 配置文件可以是以下几个地方： classpath:/,classpath:/config/,file:./,file:./config/. 这4个路径是默认的搜索路径，我们还可以自定义配置文件存放路径，就是通过spring.config.location来指定。 7，应用jar内部的属性文件。 这一块就是我们最熟悉的application.properties/application.yml配置文件了。具体的实现类是ConfigFileApplicationListener$ConfigurationProropertySource。 8，应用配置类（包含@Configuration注解的java类）中通过@PropertySource注解申明的属性文件。 这种配置方式的优先级比较低，如果和我们系统默认的配置文件（application.properties）存在重复的配置项的话，将会被覆盖。 9，通过SpringApplication#setDefaultProperties方法申明的默认属性。 具体的实现类是MapProropertySource。 这部分配置最终会存放在Environment的defaultProperties这个属性中。 二，Spring Boot配置优先级 接下来我们重点看看不同配置方式的优先级问题。 首先要搞清楚一个问题：如果一个配置项，比如： spring.redis.timeout 我们既在bootstrap.properties中配置了，又在application.properties中配置了，那么这2个配置项都会保存到我们的StandardServletEnvironment中。 bootstrap.properties中的配置被保存在了applicationConfig属性中。 application.properties中的配置被保存在了applicationConfigurationProperties属性中。 关于配置的优先级，我们这里举个例子，假如我们在application.properties配置了： spring.redis.timeout=50000 然后我们在命令行也进行了如下配置： SpringApplication.run(XxxApplication.class, "--spring.redis.timeout=60000"); 因为命令行参数的优先级高，我们在代码中引用配置项spring.redis.timeout的话，取到的值是60000。 这就是Spring Boot各配置方式的优先级问题。 三，Spring Boot 项目中，环境Environment中包含的配置属性 在Spring Boot中，Environment的具体实现是StandardServletEnvironment，StandardServletEnvironment中包含有一个ProropertySource（MutablePropertySource），这个属性就是Spring Boot所有配置项的集合，里面包含了所有的配置项。不管是通过哪种方式进行的配置，最终都会放到这个ProropertySource中。 源码重点关注SpringApplication#prepareEnvironment方法，这个方法就是Spring Boot配置的核心处理方法。这里有一部分的配置方式是通过监听器来实现的，在Spring Boot启动过程中，会触发ApplicationEnvironmentPreparedEvent事件，然后通过多播器SimpleApplicationEventMulticaster通知监听器，触发监听器的具体逻辑。 ProropertySource中包含以下属性，这些属性都是ProropertySource的具体实现。 1，bootstrapProperties bootstrapProperties：这个属性包含了配置中心配置的某个微服务下的xxx_sale.properties配置文件中的所有配置项。 bootstrapProperties的具体实现是：CompositeProropertySource servletConfigInitParams：具体实现是StubProropertySource。这个属性加入到MutablePropertySource是在StandardServletEnvironment#customizePropertySources方法中。 servletContextInitParams：具体实现是StubProropertySource。这个属性加入到MutablePropertySource是在StandardServletEnvironment#customizePropertySources方法中。 jndiProperties：这个属性加入到MutablePropertySource是在StandardServletEnvironment#customizePropertySources方法中。 jndiProperties的数据结构是JndiPropertySource。 systemProperties：这个属性包含了jvm的系统信息，比如操作系统相关信息，线程id等。这个属性加入到MutablePropertySource是在StandardEnvironment#customizePropertySources方法中。感兴趣的朋友可以看看源码，最终是通过System#getProperties这个native方法获取到系统参数的。systemProperties的数据结构是MapPropertySource。 systemEnvironment：这个属性包含了jvm运行环境的信息，比如系统环境变量，ant路径等。这个属性加入到MutablePropertySource是在StandardEnvironment#customizePropertySources方法中。感兴趣的朋友可以看看源码，最终是通过System#getenv这个native方法获取到系统参数的。 systemEnvironment的数据结构是SyetemEnvironmentProropertySource。 bootstrap：bootstrap是通过监听器来实现的，在Spring Boot启动过程中，会触发ApplicationEnvironmentPreparedEvent事件，然后通过多播器SimpleApplicationEventMulticaster通知监听器，触发监听器的具体逻辑。 bootstrap的监听器实现是BootstrapApplicationListener#onApplicationEvent，实现逻辑还是挺复杂的，感兴趣的朋友可以深入研究。 bootstrap的数据结构是MapProropertySource。 commandLineArgs：对应命令行参数配置方式，具体实现就在SpringApplication#run方法中，其中解析命令行参数配置的代码是： ApplicationArguments applicationArguments = new DefaultApplicationArguments(args); 把commandLineArgs添加到MutablePropertySource的代码是： SpringApplication#configurePropertySources commandLineArgs的数据结构是SimpleCommandLineProropertySource。 random：具体实现是RandomValueProropertySource。 applicationConfigurationProperties：这个属性包含了application.properties配置文件中的所有配置项。 具体实现是ConfigFileApplicationListener$ConfigurationProropertySource。 applicationConfig：属性包含了bootstrap.properties配置文件中的所有配置项。 具体实现是PropertiesProropertySource。 defaultProperties：这个属性在SpringApplication#configurePropertySources方法中进行设置，最终是应用程序调用SpringApplication#setDefaultProperties进行设置的，优先级较低。defaultProperties的数据结构是MapProropertySource。 springCloudClientHostInfo：具体实现是MapProropertySource。