Spring Cloud Config场景下Spring Boot配置属性优先级的行为验证

结合Spring Cloud Config Client的默认加载与优先级规则，你总结的三个行为基本和框架的设计逻辑完全匹配，不存在认知偏差，以下是逐点的规则拆解和边界说明：

第一个假设的核验结论 #

你观察到的“远端配置的server.port无法通过-Dserver.port覆盖”，在框架默认配置下是完全成立的。

• Spring Cloud Config Client在完成远端配置拉取后，默认开启spring.cloud.config.override-system-properties=true规则：只要配置中心的目标配置文件里存在对应属性的键值，这个远端值的优先级就会高于Java系统属性（也就是通过-D传入的JVM启动参数），直接覆盖系统侧的同属性值。
• 这个设计本身是为了强化配置中心的管控能力，避免应用维护人员通过临时JVM参数绕过统一的配置规范。
• 如果需要让-D参数具备覆盖远端配置的能力，只需要在客户端增加配置项spring.cloud.config.override-system-properties=false，此时远端配置的优先级会回落到普通本地配置层级，自然会被更高优先级的系统属性覆盖。

第二个假设的核验结论 #

“远端未覆盖的属性，可在本地配置文件中自定义生效”的描述，是完全准确的。

• 配置中心的强制覆盖规则，仅作用于远端配置集合里已经明确存在的属性。如果拉取到的远端配置中根本没有对应属性的键，整个本地配置加载流程和原生Spring Boot没有任何差异，你可以在本地application.yaml/application.properties里自定义任意属性值，不会受到配置中心加载流程的干预。
• 举个实际的例子：如果配置中心只集中管理了业务数据源、注册中心地址这类公共属性，没有配置应用的actuator端口，你完全可以在本地配置文件里自定义management.server.port的值正常生效。

第三个假设的核验结论 #

“本地配置文件定义的属性，可通过-D参数覆盖”的描述，在默认配置下也是准确的。

• 当某一个属性的取值完全不涉及远端配置的来源时，整个优先级序列会回归原生Spring Boot的默认规则：Java系统属性（-D传入的参数）的优先级远高于jar包内打包的本地application.*配置文件，自然可以直接覆盖本地文件里定义的同属性值。
• 这里需要点明一个容易混淆的边界：如果同一个属性在远端配置中心已经有明确取值，那不管你在本地配置文件里有没有写这个属性，只要保持默认的override-system-properties=true配置，-D参数的覆盖就会失效——这也是你观察到第一个场景的核心原因。

特别提醒：很多开发者会混淆两类命令行传参的优先级差异。像java -jar app.jar --server.port=xxx这种直接跟在jar包后面的参数，属于Spring Boot原生的命令行参数，优先级是高于所有配置源的（包括配置中心拉取的远端配置），哪怕保持默认的override规则也能直接生效；只有-Dserver.port=xxx这种作为JVM系统属性传入的参数，才会受上面提到的配置优先级规则约束。

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