在開發過程中，不知道有沒有這樣的經歷，項目實際讀取的配置信息有時候總是與預期不符，今天就來研究下 SpringBoot 讀取配置文件順序。 一、SpringBoot 配置文件載入優先順序 SpringBoot官方文檔說明瞭載入的順序如下，越靠前優先順序越高。 Spring Boot uses a ver ...
在開發過程中，不知道有沒有這樣的經歷，項目實際讀取的配置信息有時候總是與預期不符，今天就來研究下 SpringBoot 讀取配置文件順序。
一、SpringBoot 配置文件載入優先順序
SpringBoot官方文檔說明瞭載入的順序如下，越靠前優先順序越高。
Spring Boot uses a very particular
PropertySourceorder that is designed to allow sensible overriding of values. Properties are considered in the following order
1. 開發者工具 Devtools 全局配置參數；
2. 單元測試上的 [@TestPropertySource](mailto:@TestPropertySource)` 註解指定的參數;
3. 單元測試上的 [@SpringBootTest](mailto:@SpringBootTest)` 註解指定的參數；
4. 命令行指定的參數，如 java -jar springboot.jar --name="xxx"；
5. 命令行中的 SPRING_APPLICATION_JSON 指定參數, 如 java -Dspring.application.json='{"name":"xxx"}' -jar springboot.jar
6. ServletConfig初始化參數；
7. ServletContext初始化參數；
8. JNDI參數（如 java:comp/env/spring.application.json）；
9. Java系統參數（來源：System.getProperties()）；
10. 操作系統環境變數參數；
11. RandomValuePropertySource 隨機數，僅匹配：ramdom.*；
12. JAR包外面的配置文件參數（application-{profile}.properties（YAML））
13. JAR包裡面的配置文件參數（application-{profile}.properties（YAML））
14. JAR包外面的配置文件參數（application.properties（YAML））
15. JAR包裡面的配置文件參數（application.properties（YAML））
16. @Configuration (mailto:@Configuration)配置文件上 @PropertySource(mailto:@PropertySource) 註解載入的參數；
17. 預設參數（通過 SpringApplication.setDefaultProperties 指定）；
這裡我們只對比常用的幾個地方的配置優先順序：
命令行參數 > JAR包外面的 application-{profile}.properties > JAR包內的 application-{profile}.properties > JAR包外的 application.properties > JAR包內的 application.properties
這樣可能不太直觀，而且有的項目會將 application.properties 文件放在config文件夾內，於是進一步對比了這兩個位置的優先順序，結果如下
SpringBoot 應用程式在啟動時會遵循以下順序進行載入配置文件
- 類路徑下的配置文件
- 類路徑內
config子目錄的配置文件 - 項目根目錄下的配置文件
- 項目根目錄下
config子目錄的配置文件
. project-sample
├── config
│ ├── application.yml （4）
│ └── src/main/resources
| │ ├── application.yml （1）
| │ └── config
| | │ ├── application.yml （2）
├── application.yml （3）
註：src/main/resources下的配置文件在項目編譯時，會放在target/classes下
啟動時載入配置文件順序：1 -> 2 -> 3 -> 4，優先順序 4 > 3 > 2 > 1
註意：
- 如果在
IDEA中是多module項目，3 和 4 的位置是指的是項目根目錄下的位置 - 當 .properties 和 .yml 文件同時存在時，.properties會失效，.yml會起作用。
二、bootstrap.yml配置文件
在 SpringCloud 的項目中，我們常常會碰到另外一個配置文件 bootstrap.yml。這個配置文件主要是用於應用程式上下文的引導階段，該配置文件的載入是在 application.yml 之前。
bootstrap.yml 和 application.yml 文件的區別可參考：What is the difference between putting a property on application.yml or bootstrap.yml in spring boot
在 SpringCloud 中有兩種上下文，一種是 bootstrap, 另外一種是 application, bootstrap 是應用程式的父上下文。官方的原話是 A Spring Cloud application operates by creating a “bootstrap” context, which is a parent context for the main application。
bootstrap.yml配置文件的使用場景：
- 使用配置中心時，這時需要在bootstrap配置文件中添加連接到配置中心的信息，來載入外部配置中心的配置信息
- 一些固定的不能被覆蓋的屬性
- 一些加密/解密的信息
項目中 bootstrap.yml 示例
spring:
application:
name:
profiles:
active: local
cloud:
nacos:
# 遠程配置
config:
server-addr:
namespace:
group: ${spring.profiles.active}
file-extension: yml
# 服務發現
discovery:
server-addr:
namespace:
group: ${spring.profiles.active}
三、配置中心的配置
在 SpringCloud 項目中，我們的配置常由配置中心進行統一管理，這就涉及到本地與遠程配置文件的優先順序問題。這裡只說明遇到過的兩種: SpringCloud Config 和 Nacos。
- SpringCloud Config
SpringCloud Config 中的遠程配置，預設是無法被本地覆蓋，如果需要本地配置覆蓋遠程配置，需要在遠程做如下配置：
spring:
cloud:
config:
allowOverride: true
overrideNone: true
overrideSystemProperties: false
上面的說法可以在如下鏈接中得到驗證：
https://cloud.spring.io/spring-cloud-commons/multi/multi__spring_cloud_context_application_context_services.html#overriding-bootstrap-properties
- Nacos
Nacos中的遠程配置，似乎不支持本地覆蓋，在Nacos項目中Issue中得到證實，似乎官方也沒有這種打算。值得一提的是，即使通過命令行指定的參數，也不能覆蓋遠程配置。
關於該問題的Issue:
- Unable to override datasource
- 在使用命令行參數(-Dserver.port = 9000)啟動被nacos管理的服務客戶端時,發現命令行參數沒有生效
- nacos是否存在類似springcloudconfig的allow-override等本地控制許可權參數？或者是否支持這個參數
四、踩過的坑
在一次開發過程中，我們希望服務(serviceA)的某些節點的配置與其他節點配置不同，剛開始的想法是在啟動命令行加入參數 spring.application.name=serviceB，然後在配置中心 nacos 中複製一份serviceA的配置命名為 service B。但是實際測試中，不能修改 application.name 的值，因為參與到一些業務配置。
接著我們想直接在命令行中加入區別於其他節點的參數，希望能夠覆蓋遠程的配置，但前面也說過，命令行的配置無法覆蓋遠程Nacos配置，且Nacos沒有提供支持覆蓋的開關，所以也沒能達到我們預期的結果。
實際測試的結果，配置優先順序：nacos上的配置 > 命令行配置 > system env > classpath:application.yml > classpath:bootstrap.yml
最後我們發現nacos支持指定服務配置，以及服務發現的名稱，這些配置是在 bootstap.yml 文件中指定，預設值是 spring.application.name。實際測試結果，通過命令行可以覆蓋該文件中的配置，這樣正好能夠滿足我們的需求：不修改application.name，又可以使部分節點的配置區別於其他節點。
java -jar ./app.jar --spring.profiles.active=local --spring.cloud.nacos.config.name=serviceB --spring.cloud.nacos.discovery.service=serviceB
