本文探讨spring boot应用在使用maven多profile构建并打包为可执行jar后，在命令行运行时无法读取profile特定配置的问题。通过分析spring boot的属性加载机制，重点讲解application-{profile}.properties文件未被正确加载导致@value注入失败的原因，并提供确保profile配置生效的解决方案和最佳实践。
引言
在使用Spring Boot开发多环境应用时，我们通常会为不同的部署环境（如开发、测试、生产）定义各自的配置文件，例如application-dev.properties、application-prod.properties等。通过激活特定的Profile，Spring Boot应用能够加载对应的配置。然而，有时会遇到一个令人困惑的问题：在集成开发环境（IDE）中运行应用时，Profile特定的配置能够正常加载并注入到Bean中；但当应用被打包成可执行JAR并在命令行中运行时，却出现IllegalArgumentException: Could not resolve placeholder的错误，表明某个属性未能被解析。
本教程将深入分析这一现象背后的原因，并提供详细的排查步骤和可靠的解决方案，帮助开发者确保Spring Boot应用在各种运行环境下都能正确加载和使用Profile特定的配置。
Spring Boot属性加载机制概览
Spring Boot提供了一套强大且灵活的外部化配置机制，其核心是Environment抽象和PropertySource加载器。
-
默认配置文件：
- application.properties或application.yml是Spring Boot的默认配置文件。
- Spring Boot会按照特定顺序加载这些文件，并将其中的键值对添加到Environment中。
-
Profile特定配置文件：
- 为了支持多环境配置，Spring Boot引入了Profile的概念。可以通过创建application-{profile}.properties（或application-{profile}.yml）文件来为特定Profile定义配置。
- 当一个或多个Profile被激活时，Spring Boot会加载对应的Profile特定配置文件，并将其中的属性合并到Environment中。Profile特定配置的优先级高于默认配置。
-
Profile激活方式：
- 命令行参数：通过--spring.profiles.active=profileName或-Dspring.profiles.active=profileName在启动命令中指定。这是最常见的命令行激活方式。
- 环境变量：设置SPRING_PROFILES_ACTIVE=profileName。
- application.properties文件：在application.properties中设置spring.profiles.active=profileName。这种方式通常用于设置默认激活的Profile。
- Maven Profile与资源过滤：在Maven项目中，可以通过定义Maven Profile，并结合资源过滤（resource filtering）在构建时动态设置application.properties中的spring.profiles.active值。
属性优先级： Spring Boot的属性加载具有明确的优先级顺序，通常命令行参数具有最高优先级，其次是环境变量，然后是JAR包外部的配置文件，最后是JAR包内部的配置文件（其中Profile特定配置高于默认配置）。
问题分析：为何命令行下Profile配置未生效？
当Spring Boot应用在命令行运行时抛出Could not resolve placeholder 'custom.property' in value "${custom.property}"错误时，这意味着在Spring容器尝试实例化TestController并注入custom.property时，Environment中根本没有找到名为custom.property的属性。
结合提供的场景，custom.property被定义在application-local.properties中，并且通过java -jar -Dspring.profiles.active=local ...命令尝试激活local Profile。理论上，这应该能使application-local.properties被加载。那么，问题可能出在哪里呢？
application-local.properties未被正确打包： 这是最常见的原因。当使用Maven构建可执行JAR包（特别是使用maven-shade-plugin或spring-boot-maven-plugin时），有时资源文件可能没有被正确地包含在最终的JAR包中，或者被放置在了Spring Boot无法识别的位置。
Profile激活逻辑的误解或冲突： 虽然命令行参数-Dspring.profiles.active=local通常会生效，但如果application.properties中通过Maven过滤设置了spring.profiles.active=@activatedProperties@，并且在构建时没有激活相应的Maven Profile，或者Maven过滤本身没有正确执行，可能导致最终JAR包内的application.properties没有预期值。不过，命令行参数通常会覆盖这些内部设置。因此，更可能的问题是application-local.properties本身的加载。
Shade插件的资源合并问题（可能性较低）： maven-shade-plugin在创建"fat JAR"时，需要合并多个JAR包中的资源。虽然用户已配置了AppendingTransformer来处理META-INF/spring.factories等文件，但理论上仍可能存在其他资源合并冲突导致配置文件丢失或损坏。然而，对于普通的.properties文件，这种情况相对较少。
核心推测：最直接的原因是，当应用以JAR包形式运行时，application-local.properties文件未能被Spring Boot的Environment正确识别和加载，导致custom.property属性在注入时缺失。而在IDE中，由于IDE通常直接从项目源码或编译后的target/classes目录运行，其资源加载机制可能与打包后的JAR有所不同，从而避免了此问题。
解决方案与最佳实践
为了解决这个问题并提高应用的健壮性，我们提供以下解决方案和最佳实践：
方案一：在application.properties中提供默认值（推荐）
这是最简单且最有效的解决方案，同时也是一个良好的实践。即使Profile特定的配置文件未能加载，或者在没有激活任何Profile的情况下，应用也能有一个默认值，避免启动失败。
操作步骤： 在src/main/resources/application.properties文件中，为custom.property提供一个默认值。
示例代码：
# src/main/resources/application.properties spring.profiles.active=@activatedProperties@ custom.property=Default Value From Main Application Properties
同时，保持application-local.properties中的Profile特定值：
# src/main/resources/application-local.properties custom.property=Local Environment Specific Value
原理： 当local Profile被激活时，application-local.properties中的custom.property值（"Local Environment Specific Value"）将覆盖application.properties中的默认值（"Default Value From Main Application Properties"）。如果local Profile未能被激活或application-local.properties未能加载，@Value("${custom.property}")将回退到使用application.properties中的默认值，从而避免IllegalArgumentException。
方案二：确认JAR包内资源完整性
确保application-local.properties文件确实存在于最终打包的JAR文件中，并且位于Spring Boot能够识别的位置。
操作步骤：
-
检查JAR包内容： 使用jar tvf target/myapp-standalone-0.0.1-SNAPSHOT-shaded.jar命令（将文件名替换为实际的JAR包名称）来列出JAR包中的所有文件。 验证application.properties和application-local.properties是否存在于JAR包的根目录（对于Spring Boot的“fat JAR”或“thin JAR”的BOOT-INF/classes目录）。
jar tvf target/myapp-standalone-0.0.1-SNAPSHOT-shaded.jar | grep "application"
预期输出应包含类似以下内容：
... 1234 Sat Jan 01 00:00:00 UTC 2023 application.properties 5678 Sat Jan 01 00:00:00 UTC 2023 application-local.properties ...
-
检查Maven资源过滤配置： 确保pom.xml中的资源过滤配置正确，尤其是在使用Maven Profile动态设置spring.profiles.active时。虽然你的配置看起来是正确的，但有时构建工具链中的细微差异可能导致问题。
<resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> <!-- 确保这里是true --> <includes> <include>**/*.properties</include> <include>**/*.json</include> </includes> <excludes> <exclude>**/*.jks</exclude> </excludes> </resource> </resources>当通过Maven Profile激活时（例如mvn clean package -P local），application.properties中的@activatedProperties@应该被替换为local。你可以解压JAR包，检查application.properties的内容是否符合预期。
方案三：简化Profile激活策略
虽然在application.properties中使用Maven过滤来设置spring.profiles.active是可行的，但在命令行运行时，通常更推荐直接使用命令行参数或环境变量来激活Profile，以避免潜在的构建时和运行时配置冲突。
推荐做法： 让application.properties不包含spring.profiles.active的Maven过滤占位符，而是完全依赖命令行参数或环境变量。
示例： application.properties中不再包含spring.profiles.active=@activatedProperties@。 命令行启动时，始终明确指定： java -jar -Dspring.profiles.active=local target/myapp-standalone-0.0.1-SNAPSHOT-shaded.jar
这种方式使Profile的激活更加显式和可控，减少了因构建过程导致的运行时不一致性。
方案四：调试属性加载过程
如果上述方法仍无法解决问题，可以通过开启Spring Boot的调试日志或手动检查Environment来深入了解属性的加载情况。
-
开启调试日志： 在启动命令中添加-Ddebug参数，或者在application.properties中设置logging.level.org.springframework.boot=DEBUG。这将打印出Spring Boot启动时大量的调试信息，包括属性源的加载顺序和内容。
java -jar -Dspring.profiles.active=local -Ddebug target/myapp-standalone-0.0.1-SNAPSHOT-shaded.jar
仔细查看日志中关于PropertySource加载和Environment处理的部分，可以发现application-local.properties是否被加载，以及custom.property的值是什么。
-
手动检查Environment： 在应用启动后，可以通过注入Environment对象来程序化地检查属性值。
import org.springframework.beans.factory.annotation.Autowired; import org.springframework.core.env.Environment; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RestController; @RestController public class TestController { @Autowired private Environment env; // 注入Environment对象 // @Value("${custom.property}") // 暂时注释掉，避免启动失败 // private String activeProfile; @GetMapping("/testing") public ResponseEntity<String> getTestMEthod() { String customProperty = env.getProperty("custom.property"); String activeProfiles = String.join(",", env.getActiveProfiles()); String message = "Custom Property: " + customProperty + ", Active Profiles: " + activeProfiles + " says hello"; return ResponseEntity.ok().body(message); } }通过这种方式，即使@Value注入失败，你也能在运行时通过API端点检查Environment中实际存在的属性值，从而定位问题。
注意事项
- IDE与命令行环境差异：IDE（如IntelliJ IDEA）在运行Spring Boot应用时，通常会直接从target/classes目录加载资源，或者有其特定的Profile激活和资源处理机制。这可能与打包后的JAR在命令行下的运行环境存在差异。因此，总是建议在打包后进行命令行测试。
- Maven Shade插件：maven-shade-plugin虽然功能强大，但有时可能因配置不当导致资源合并问题。确保transformers配置正确，特别是对于Spring Boot需要特殊处理的META-INF/spring.factories等文件。在你的pom.xml中，这部分配置看起来是合理的。
- Spring Boot版本：确保使用的Spring Boot版本没有已知的相关Bug。如果怀疑是版本问题，可以尝试升级到最新的稳定版本。
总结
当Spring Boot应用在命令行运行时无法读取Profile特定配置，并出现Could not resolve placeholder错误时，最常见的原因是Profile特定的配置文件（如application-local.properties）未能被Spring Boot的Environment正确加载。
解决此问题的关键在于：
- 在application.properties中为所有@Value注入的属性提供一个默认值，以增加应用的
