application.yml和bootstrap.yml同属性时谁覆盖谁？是否与版本有关？

认知差异的核心原因是Spring Cloud版本迭代带来的默认规则变更，不存在跨所有版本的固定优先级逻辑，不同版本的实际表现如下：

• 旧版本逻辑（Spring Cloud 2020.0.x 代号Ilford之前，配套Spring Boot 2.3.x及更早版本）
  这个阶段bootstrap.yml是专为引导上下文设计的配置文件，加载时机比application.yml早一个父上下文层级，默认优先级更高，且默认不允许application.yml的同key配置覆盖bootstrap中的属性。这也是网上大部分早期技术资料提到“bootstrap.yml配置不会被覆盖”的来源，这个设计的初衷是存放配置中心连接参数、加密密钥这类需要在应用启动最早期初始化的配置，避免被业务侧的application配置意外篡改。
• 新版本默认逻辑（Spring Cloud 2020.0.0及之后版本，配套Spring Boot 2.4.x及更高版本）
  从这个版本开始，Spring Cloud官方默认禁用了bootstrap引导上下文的自动加载机制：
  • 如果没有手动引入spring-cloud-starter-bootstrap依赖，就算项目里存在bootstrap.yml文件，框架也不会自动扫描加载，自然会出现“application.yml配置生效、bootstrap配置不生效”的现象，不少开发者会误以为是配置覆盖，本质是bootstrap文件根本没有被加载。
  • 就算手动引入上述依赖启用了bootstrap上下文，这个版本的默认覆盖规则也做了调整：bootstrap.yml加载的配置优先级被调低，application.yml中的同key属性会默认覆盖bootstrap.yml的配置，和本地测试观察到的现象一致。
  • 如果需要在新版本中恢复旧版本“bootstrap配置不被application覆盖”的逻辑，只需要添加配置参数spring.cloud.bootstrap.allow-override=false即可。

注意不要混淆本地配置文件覆盖规则和配置中心配置的优先级：无论哪个版本，从配置中心拉取的远程配置，默认优先级都高于本地所有配置文件的配置。

内容的提问来源于stack exchange，提问作者Larry