Spring Cloud Config 属性的加载优先级是什么？

Question

Spring 有明确的加载外部化配置的顺序。

1. 主目录中的 Devtools 全局设置属性（当 devtools 处于活动状态时为 ~/.spring-boot-devtools.properties）。
2. 测试中的 @TestPropertySource 注释。
3. 测试中的 @SpringBootTest#properties 注释属性。
4. 命令行参数。
5. 来自 SPRING_APPLICATION_JSON 的属性（嵌入在环境变量或系统属性中的内联 JSON）。
6. ServletConfig 初始化参数。
7. ServletContext 初始化参数。
8. 来自 java:comp/env 的 JNDI 属性。
9. Java 系统属性 (System.getProperties())。
10. 操作系统环境变量。
11. 仅在 random.* 中具有属性的 RandomValuePropertySource。
12. 打包 jar 之外的特定于配置文件的应用程序属性（application-{profile}.properties 和 YAML 变体）。
13. 打包在 jar 中的特定于配置文件的应用程序属性（application-{profile}.properties 和 YAML 变体）。
14. 打包 jar 之外的应用程序属性（application.properties 和 YAML 变体）。
15. 打包在 jar 中的应用程序属性（application.properties 和 YAML 变体）。
16. @Configuration 类上的 @PropertySource 注释。
17. 默认属性（通过设置 SpringApplication.setDefaultProperties 指定）。

然而，来自Spring Cloud Config 的配置似乎有明显的遗漏。有谁知道 Spring Cloud Config 在上面的位置

Answer 1

正如其他人所说，配置服务器是第一位的。如果您尝试使用本地属性（即）覆盖配置服务器的属性application-local.yml，那么您需要向配置服务器添加两个属性**：

\n

spring.cloud.config.allowOverride=true\nspring.cloud.config.overrideNone=true\n

\n

根据文档：

\n

\n

通过引导上下文添加到应用程序的属性源通常是“远程”的（例如，来自配置服务器），并且默认情况下它们不能在本地覆盖。如果您希望应用程序使用自己的系统属性或配置文件覆盖远程属性，则远程属性源必须通过设置 spring.cloud.config.allowOverride=true 来授予其权限（它不会\xe2\ x80\x99 无法在本地设置此\n）。设置该标志后，就会有一些更细粒度的设置\n来控制远程属性相对于系统\n属性和应用程序\xe2\x80\x99s本地配置的位置：\nspring.cloud.config.overrideNone=true 进行覆盖使用任何本地\n属性源，并且\nspring.cloud.config.overrideSystemProperties=false 如果只有系统\n属性和环境变量应覆盖远程设置，而不\n本地配置文件。

\n

\n

另请参阅有关使用通过系统/命令行属性进行覆盖的内容。spring.cloud.config.override-system-properties=false上面引用的文档有不一致的地方，我从引用中删除了它。

\n

请注意，如果您希望远程配置服务器覆盖本地属性文件源，但不覆盖本地系统属性或环境属性，请在配置服务器中添加以下内容：

\n

spring.cloud.config.allowOverride=true\nspring.cloud.config.overrideNone=false\nspring.cloud.config.overrideSystemProperties=false\n

\n

** 在这种情况下，该overrideSystemProperties值将被忽略。看org.springframework.cloud.bootstrap.config.PropertySourceBootstrapConfiguration#insertPropertySources

\n

注意：以上所有内容均适用于 Spring Boot 2.3.x。版本 2.4.x 使用备用加载优先级。请参阅https://github.com/spring-cloud/spring-cloud-config/issues/1856

\n