Spring Boot Profile配置在Linux不生效，Windows正常运行问题

环境与现象 #

使用Spring Boot 2.7.12 + Spring Cloud 2021.0.7开发应用，通过application.properties的分段Profile配置管理多环境：

• Windows（Oracle JDK 17）：激活testing Profile后，Profile段内的spring.config.import能正常覆盖全局配置，连接指定的远程配置中心。
• Linux（OpenJDK 17）：执行相同启动命令java -jar gateway.jar --spring.profiles.active=testing，Profile已激活，但spring.config.import仍使用全局的http://localhost:8888/，报错连接拒绝：

Caused by: org.springframework.web.client.ResourceAccessException: I/O error on GET request for "http://localhost:8888/cloud-gateway/testing": Connection refused; nested exception is java.net.ConnectException: Connection refused

原始配置 #

spring.application.name=cloud-gateway
spring.config.import=configserver:http://localhost:8888/
#---
spring.config.activate.on-profile=testing
spring.config.import=configserver:http://192.168.30.10:8888/
spring.cloud.config.username=service
spring.cloud.config.password=password

临时解决方案 #

将全局默认配置显式归属到default Profile段后，Linux环境下配置正常生效：

spring.application.name=cloud-gateway
#---
spring.config.activate.on-profile=default
spring.config.import=configserver:http://localhost:8888/
#---
spring.config.activate.on-profile=testing
spring.config.import=configserver:http://192.168.30.10:8888/
spring.cloud.config.username=service
spring.cloud.config.password=password

原因分析 #

spring.config.import属于Spring Boot的早期加载属性，它的加载时机早于Profile激活逻辑。在原始配置中，未归属任何Profile的全局spring.config.import会被优先加载，而不同环境（Windows/Linux）的配置解析器在处理"全局配置+Profile配置"的覆盖逻辑时，可能存在细微差异：Linux环境下，早期加载的全局配置优先级意外高于Profile内的重写配置，导致属性未被覆盖。

当把默认配置放到default Profile段后，所有spring.config.import都归属到明确的Profile上下文，Spring Boot激活testing Profile时，会按照标准的Profile优先级规则（激活的Profile > default Profile）正确覆盖配置，消除了跨环境的解析差异。

结论 #

对于spring.config.import这类核心早期加载属性，即便官方文档说明全局配置会被激活的Profile配置覆盖，仍建议显式将默认配置归属到default Profile段，以此保证跨环境的配置行为一致性，避免因解析逻辑差异导致的异常。

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