Spring Boot 配置文件的优先级是什么？环境变量、命令行和 application.yml 谁覆盖谁？

知识点详解：同一个配置键，怎样得到最终值？

先比较来源，再比较文件

假设教学配置使用 server.port：

来源	假设值
application.yml	8080
OS 环境变量 SERVER_PORT	9090
启动参数 —server.port=7070	7070

在默认接受命令行属性、且没有其他更高来源覆盖的情况下，最终使用 7070。

重点是前提。Spring Boot 可以关闭命令行属性加入，测试环境也可以加入优先级更高的来源。因此“命令行永远最高”不准确。官方来源顺序

生产问题还需要检查容器实际注入的环境，而不是只看开发机器的变量。

application-prod.yml 不是放进去就自动生效

特定 Profile 文件是否参与读取，首先取决于相应 Profile 是否激活。

同样的配置键可能出现在包内默认文件、包内 Profile 文件、包外文件以及包外 Profile 文件。标准加载规则允许后面的来源覆盖前面的值，但自定义位置、导入和分组会进一步影响过程。

所以要同时核对：激活了哪些 Profile，文件是否位于实际搜索位置，是否使用了替换默认位置的配置。

不要把“目录里有 prod 文件”当成运行环境正在使用它的证明。配置文件是候选来源，实际加载才是事实。

环境变量还需要映射到正确的配置键

环境变量往往不能直接使用点号，框架通过相应绑定规则处理名称。

server.port 与 SERVER_PORT 是常见例子，但复杂键名、列表或自定义结构不宜只凭经验猜测。应按官方 relaxed binding 规则与实际绑定对象检查。

值读进 Environment，也不保证所有代码都用了它。某个地方如果写死常量、手动读取另一键名，或者绑定对象没有被正确创建，仍会出现“配置看起来正确，行为却没变”。

因此排查的最后一段是：最终值怎样进入业务代码？

查询配置来源时，不要泄露秘密

可以使用受控诊断信息，检查最终值与来源。Actuator 的 env、configprops 等工具能够辅助定位，但必须限制访问并处理敏感内容。

公开打印完整环境变量，可能把数据库密码、API Key 和签名材料一起暴露。诊断一个超时值，不需要输出整套生产环境。

较好的记录包括配置键、脱敏后的有效值、来源位置、激活 Profile 和应用版本。这样才能说明为什么某一次启动用了这个值，而不是只留一张配置文件截图。

面试官继续追问

系统属性和环境变量相同，谁更优先？

在官方标准顺序中，Java System properties 位于 OS 环境变量之后，可覆盖其值。完整环境仍应核对其他来源和自定义设置。

改完外部配置，进程会自动更新吗？

不能默认。普通外部配置加载与运行时刷新是不同能力，需要看具体组件和设计。文件变化不代表已经运行的对象重新绑定。

配置优先级和 Bean 覆盖是同一回事吗？

不是。一个决定属性值来源，另一个涉及同名 Bean 的定义与注册规则，不应混成一张覆盖表。

面试速记卡

• 常见比较：启用默认规则时，命令行通常高于环境变量，高于配置文件。
• 完整范围：测试、系统属性与自定义来源还会参与覆盖。
• 文件规则：位置、Profile、导入与实际加载路径都要检查。
• 排查链路：来源 → 加载 → 覆盖 → 绑定 → 使用。
• 诊断安全：核对有效值与来源，敏感配置必须脱敏。