本文深入探讨了spring boot应用在命令行环境下无法正确加载 `application.properties` 或 `application-{profile}.properties` 中定义的属性，但在ide中运行正常的常见问题。通过分析spring boot的属性加载机制、maven配置文件与资源过滤的交互，以及`maven-shade-plugin`可能带来的影响，提供了详细的诊断步骤和确保多环境属性正确加载的解决方案。
引言：Spring Boot属性加载与多环境配置挑战
在Spring Boot应用开发中，通过 application.properties 或 application-{profile}.properties 文件管理不同环境的配置属性是标准实践。然而，开发者有时会遇到一个令人困惑的问题：应用在集成开发环境（IDE）如IntelliJ中运行一切正常，但在通过 java -jar 命令从命令行启动时，却无法解析某些属性，抛出 IllegalArgumentException: Could not resolve placeholder 错误。本教程将针对此类问题，结合实际案例，深入剖析其原因并提供行之有效的解决方案。
Spring Boot属性加载机制回顾
Spring Boot提供了一套灵活的外部化配置机制，其核心在于不同来源的属性具有不同的优先级。当应用启动时，Spring Boot会按照特定顺序加载属性源，包括：
- 命令行参数：java -jar myapp.jar --server.port=8081 或 -Dspring.profiles.active=dev。优先级最高。
- SpringApplication.setDefaultProperties
- @PropertySource 注解
- 配置类中的 properties 属性
- 操作系统环境变量
- application.properties 或 application.yml 文件：位于JAR包外部或内部。
- application-{profile}.properties 或 application-{profile}.yml 文件：特定于活动Profile的配置文件，优先级高于通用的 application.properties。
- @Value 注解：用于将属性值注入到Spring组件中。
当Spring Boot激活一个或多个Profile时（例如 local），它会首先加载通用的 application.properties，然后加载 application-local.properties。如果同一个属性在两个文件中都定义了，则Profile特定的文件中的值会覆盖通用文件中的值。
Maven配置文件（Profiles）与资源过滤
在多模块或多环境的Maven项目中，pom.xml 中的 <profiles> 元素和资源过滤机制（resource filtering）常用于在构建时动态调整配置。
Maven Profiles
Maven Profiles允许根据不同的构建环境（如 dev, prod, local）定义不同的构建行为或属性。例如：
<profiles>
<profile>
<id>local</id>
<properties>
<activatedProperties>local</activatedProperties>
</properties>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
<profile>
<id>dev</id>
<properties>
<activatedProperties>dev</activatedProperties>
</properties>
</profile>
<!-- 其他环境Profile -->
</profiles>在上述配置中，当激活 local 或 dev Profile时，activatedProperties 属性会被相应地设置为 local 或 dev。
资源过滤
Maven的资源过滤功能允许在构建过程中替换资源文件（如 .properties 文件）中的占位符。这通过在 pom.xml 的 <build><resources> 部分配置 <filtering>true</filtering> 来实现：
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
<includes>
<include>**/*.properties</include>
<include>**/*.json</include>
</includes>
<!-- ... -->
</resource>
</resources>
<!-- ... -->
</build>当 application.properties 文件中包含 spring.profiles.active=@activatedProperties@ 这样的占位符时，Maven在打包时会将其替换为当前激活的Maven Profile所对应的 activatedProperties 值。例如，如果 local Profile被激活，打包后的 application.properties 文件中将是 spring.profiles.active=local。
问题诊断：命令行运行失败的深层原因
结合案例描述，问题在于 custom.property 只存在于 application-local.properties 和 application-dev.properties 中，而不在 application.properties 中。当在命令行使用 java -jar -Dspring.profiles.active=local target\myapp-standalone-0.0.1-SNAPSHOT-shaded.jar 启动时，抛出 Could not resolve placeholder 'custom.property' 错误。
1. 命令行参数与Maven过滤的优先级和时序
- Maven过滤阶段：在 mvn package 命令执行时，如果激活了某个Maven Profile（例如 local），application.properties 中的 @activatedProperties@ 会被替换为 local。因此，打包后的JAR文件中，application.properties 可能变为 spring.profiles.active=local。
- Spring Boot运行时：当通过 java -jar -Dspring.profiles.active=local 启动时，-D 参数直接设置了Spring Boot的活动Profile。这个命令行参数的优先级是最高的，它会覆盖JAR包内部 application.properties 中定义的 spring.profiles.active。这意味着，即使JAR包内的 application.properties 经过Maven过滤后变成了 spring.profiles.active=dev，只要命令行传入 -Dspring.profiles.active=local，Spring Boot最终激活的仍是 local Profile。
2. application-{profile}.properties 文件未被正确加载
错误信息 Could not resolve placeholder 'custom.property' 明确指出，当Spring容器尝试实例化 TestController 并注入 @Value("${custom.property}") 时，它无法在任何已加载的属性源中找到 custom.property。这强烈暗示 application-local.properties 文件在此时并未被Spring Boot正确加载。
可能的原因包括：
- JAR包内容缺失：最常见的原因是 application-local.properties 或其他Profile特定文件在 maven-shade-plugin 打包过程中被意外地排除或未正确合并。maven-shade-plugin 在创建“胖JAR”（或称为“阴影JAR”）时，需要特别注意资源文件的合并策略。
- Profile激活时序问题：虽然命令行参数 -Dspring.profiles.active=local 确保了 local Profile被激活，但如果 application-local.properties 文件没有在Spring Boot属性加载的正确阶段被发现并解析，问题依然会出现。这通常与JAR包结构或资源处理器有关。
3. IntelliJ中运行成功的原因分析
IntelliJ在运行Spring Boot应用时，通常会直接从项目的 target/classes 目录加载资源，或者其内部的运行配置会确保Maven过滤正确应用，并且所有Profile相关的属性文件都能被正确识别和加载。它可能没有经过 maven-shade-plugin 的复杂打包过程，因此避免了潜在的资源合并问题。
解决方案与最佳实践
针对上述问题，可以从以下几个方面进行排查和解决：
1. 验证JAR包内容
首先，检查生成的JAR包（target\myapp-standalone-0.0.1-SNAPSHOT-shaded.jar）是否包含了所有必要的配置文件，特别是 application.properties 和 application-local.properties。
jar tvf target/myapp-standalone-0.0.1-SNAPSHOT-shaded.jar | grep "application"
预期输出应包含：
application.properties application-local.properties application-dev.properties ...
如果 application-local.properties 或其他Profile特定文件缺失，那么问题很可能出在 maven-shade-plugin 的配置上。
2. 确保 custom.property 具有默认值或存在于 application.properties 中
如果 custom.property 是一个在所有环境中都需要，但值可能不同的属性，最佳实践是在 application.properties 中提供一个默认值，然后在Profile特定的文件中进行覆盖。这样即使Profile文件加载失败，应用也能有一个回退值。
src/main/resources/application.properties
spring.profiles.active=@activatedProperties@ custom.property=Default Value from Base Config # 提供一个默认值
src/main/resources/application-local.properties
custom.property=Local Environment Value
src/main/resources/application-dev.properties
custom.property=Development Environment Value
通过这种方式，即使 application-local.properties 暂时未被加载，TestController 也能从 application.properties 中获取 custom.property 的默认值，避免启动失败。
3. 简化Maven Profile与Spring Profile的交互
虽然Maven过滤可以设置 spring.profiles.active，但在生产环境中，更常见且推荐的做法是直接通过命令行参数或环境变量来控制Spring Boot的活动Profile，而不是依赖于Maven过滤后的 application.properties。
src/main/resources/application.properties
# 移除 spring.profiles.active=@activatedProperties@ # 如果需要，可以设置一个默认的Profile，例如： # spring.profiles.active=default
然后，在构建时不再依赖Maven Profile来设置 spring.profiles.active，而是直接在命令行启动时指定：
java -jar -Dspring.profiles.active=local target/myapp-standalone-0.0.1-SNAPSHOT-shaded.jar
这种方式使得Profile激活更加清晰和可控，减少了Maven过滤和Spring Boot运行时属性加载之间的潜在冲突。
4. 检查 maven-shade-plugin 配置
maven-shade-plugin 在合并多个JAR包时，可能会遇到资源文件冲突或覆盖的问题。虽然案例中的 pom.xml 包含 AppendingTransformer 来处理 META-INF/spring.factories 等，但对于普通的 .properties 文件，通常不需要特殊处理，它们应该被直接包含在最终的JAR包根目录。
确保 maven-shade-plugin 没有意外地过滤或排除 application-{profile}.properties 文件。默认情况下，它应该会包含所有资源。如果仍然怀疑是Shade插件的问题，可以尝试暂时移除 `maven
