多Spring Profile启动Spring Boot应用时配置加载结果不一致问题排查

云上老周

2026-10-2

可能的原因

以下是按排查优先级排序的常见诱因：

启动参数优先级覆盖
Spring Boot 中--开头的命令行参数优先级高于-D开头的系统属性，如果队友启动时额外添加了--spring.profiles.active=docker,development参数，会替换掉-D参数指定的profile顺序，最终后加载的development配置会覆盖docker的配置，得到http://foo。
此外如果队友的系统环境变量中设置了SPRING_PROFILES_ACTIVE=docker,development，也会产生同样的效果，Spring Boot 中环境变量的优先级高于jar包内配置文件和-D参数。
本地高优先级配置文件覆盖
Spring Boot 配置文件优先级遵循：当前运行目录下的config子目录配置 > 当前运行目录下的配置 > jar包内classpath:/config下的配置 > jar包内classpath:/下的配置。如果队友本地运行jar的目录下存在application.yml、application-development.yml或者config/子目录下的同名配置文件，且文件中配置了service.baseurl: http://foo，会直接覆盖jar包内docker profile的配置值。
如果开启了Spring Boot Devtools，用户主目录下的.spring-boot-devtools.properties配置优先级极高，也可能存在覆盖配置的情况。
配置文件内的profile引入规则
如果development对应的配置文件中存在spring.profiles.include=docker配置，被include的profile会先加载，作为主profile的development会后加载，最终development的配置会覆盖docker的配置。
IDE运行配置覆盖
如果队友是通过IDEA、Eclipse等IDE直接启动项目，IDE的运行配置中「Active Profiles」字段如果设置的顺序为docker,development，会覆盖启动命令中的profile参数，导致最终加载顺序反转。
Docker启动参数覆盖
如果是通过Docker启动，即使镜像内部的启动命令固定为指定的-D参数，只要docker run时通过-e SPRING_PROFILES_ACTIVE=docker,development或者--entrypoint参数修改了启动命令，也会改变实际生效的profile顺序。