springBoot项目配置文件加载优先级及同配置覆盖问题

背景：

由于目前网上对于springboot配置文件的加载问题，存在着各种不同的说法。所以导致自己不敢确定到底何种结论才是真正正确的，故专门花费了一些时间进行亲自验证。

验证：

在经过自己对配置文件的加载问题进行验证后，发现所谓配置文件的优先级并不一定是固定不变的，而是会受一些前提条件的影响。下面将对bootstrap.properties、bootstrap.yml、application.properties、application.yml这四种我们可能使用到的配置文件的加载优先级问题进行详细的说明(此处以springCloud微服务项目为背景，不然单纯的springBoot项目是不会加载bootstrap配置文件的，且以下说明默认配置文件都是在同一目录)。

一．非活动的profile

首先，在默认的情况下也就是不存在活动的profile（即不指定spring.profiles.active=?）时，四种文件的加载优先级依次为bootstrap.properties -> bootstrap.yml -> application.properties -> application.yml。感兴趣可以在源码上打断点可以得知配置文件的加载分为两次，如图所示：
第一次是bootstrap(.properties/.yml)的加载：

以此得出加载优先级bootstrap.properties -> bootstrap.yml

第二次是application(.properties/yml)的加载：

以此得出application.properties -> application.yml。
总结：bootstrap的配置先于application的配置加载，同时.properties的加载又先于.yml的加载，即加载优先级bootstrap.properties -> bootstrap.yml -> application.properties -> application.yml。
需要注意的是：
1.当同一个配置属性在bootstrap.properties和bootstrap.yml文件中都存在时，那么properties中的配置会被加载，而忽略yml文件中的配置（即优先级高的配置覆盖优先级低的配置），不同配置相互互补。此处application(.properties/yml)同理。
2.但当同一配置在bootstrap.properties和application.properties中都存在时，那么虽然优先加载bootstrap.properties但是会被applicatioin.properties中的配置覆盖，此时则变成了低优先级覆盖高优先的配置，所以网上很多文章所说的高优先级覆盖低优先级其实是不严谨的。
3.不同的配置会进行互补操作，即SpringBoot会读取全部的配置文件，加载所有不同的配置项，汇成一个总的配置。

二、活动的profile

例如在指定了spring.profiles.active=dev/test/prod此类时，即有了活动的profile时，加载优先级便会发生变化此时活动的优先级最高，还是直接上图：

指定profile为dev

配置文件如上
看一下加载顺序变成怎么样的了，同样第一次先加载bootstrap:

第二次加载application:

综上此时的加载优先级变为了bootstrap-dev.yml -> bootstrap.properties -> application-dev.yml ->application.properties。且同属性配置的覆盖问题和之前一样，在同为bootstrap或同为application的情况下，优先级高的覆盖优先级低的。但当同时存在bootstrap和application时后者仍会覆盖前者中的配置。
举例1：假如此时只有bootstrap-dev.yml 和bootstrap.properties且存在相同配置，则使用bootstrap-dev.yml中的配置，此时遵循高优先级覆盖低优先级。
举例2：假如此时有bootstrap-dev.yml 、bootstrap.properties及application.properties且存在相同配置，则使用application.properties中的配置，遵循application覆盖bootstrap原则，同样此时变成了低优先级覆盖高优先级。

三、使用外部配置

如项目使用nacos做配置中心，则存在相同配置时以nacos中配置为主（在没有开启本地覆盖nacos远程配置的情况下），nacos中的配置将会覆盖一切本地相同的配置，不同配置可以和本地进行互补。

扩展nacos开启本地覆盖远程配置

如果需要启动参数或者本地配置覆盖远程配置，那么需要在远程配置里配置上允许重写：
spring.cloud.config.allowOverride=true
但这是不够的，尽管它开启了总开关，但是还有两个默认的小开关卡住了。
应同时添加如下配置：
spring.cloud.config.overrideNone=true
spring.cloud.config.overrideSystemProperties=false
第一个开关是远端不覆盖本地？true 是的不覆盖。
第二个开关是远端是否覆盖系统配置？false 不覆盖。 （默认为true 覆盖）
请注意,第一个小开关包括第二个。
overrideNone = true的话会开启所有包括本地配置和系统配置并忽略掉overrideSystemProperties配置。
如果只想开启overrideSystemProperties，那么就是overrideNone = false，overrideSystemProperties=false。