Spring Cloud Config环境下单应用如何覆写application-{profile}.yml属性

问题结论 #

该覆写能力仍然支持，既不是功能删除也不是Bug，本质是Spring Boot 2.4+重构配置处理逻辑后，Spring Cloud Config 3.x的默认配置源优先级规则发生了变更，和服务端返回的配置文档顺序直接相关：加载顺序越靠后的配置源优先级越高，会自动覆盖前面配置源的同名属性。

失效原因 #

Spring Cloud Config 3.x默认的远程配置源排序规则为：公共无profile配置 → 公共带profile配置 → 应用专属无profile配置 → 应用专属带profile配置。你场景中的application-db.yml属于带profile的公共配置，默认优先级高于myapp.yml这类应用专属无profile配置，所以后者的配置被前者覆盖，和2.4版本之前的顺序正好反过来，才会出现覆写失效的问题。

你之前添加的spring.cloud.config.allowOverride等配置不生效，是因为这组配置仅用于控制远程配置源和本地配置、系统属性的优先级，无法调整远程配置源内部的排序规则。

解决办法 #

方案1：客户端兼容旧逻辑（改动最小）

在Config客户端的bootstrap.yml（必须是bootstrap配置，放在application.yml中不生效）中添加以下配置，回退到Spring Boot 2.4之前的配置处理逻辑，即可恢复原来的覆写规则：

spring:
  config:
    use-legacy-processing: true

也可以直接在启动参数中添加--spring.config.use-legacy-processing=true实现同样效果。

方案2：服务端调整配置排序（全局生效）

在Config服务端的配置中添加排序规则，将应用专属配置的优先级调整到公共带profile配置之上：

spring:
  cloud:
    config:
      server:
        sort-configuration-properties:
          - "application*" # 公共配置排在前面，优先级更低
          - "{application}*" # 应用专属配置排在后面，优先级更高

调整后所有客户端的应用专属配置都可以覆盖公共profile配置，不需要逐个修改客户端。

方案3：调整配置文件命名规则

将应用需要覆写的属性放到对应profile的应用专属配置文件中，比如你场景中可以把覆写配置放到myapp-db.yml里，带profile的应用专属配置默认优先级高于带profile的公共配置，自然可以生效。

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