本文深入探讨spring boot应用在命令行以jar包形式运行时，无法正确加载`application-{profile}.properties`中配置的属性值，导致`could not resolve placeholder`错误的常见原因。文章将提供详细的诊断步骤和解决方案，包括maven配置文件过滤、打包检查及属性配置最佳实践，确保应用在不同环境下都能正确读取配置。
引言：Spring Boot外部化配置与配置文件
Spring Boot提供了强大的外部化配置机制，允许开发者将配置与代码分离，以便在不同环境（如开发、测试、生产）中使用不同的配置。其核心是application.properties或application.yml文件。当需要针对特定环境进行配置时，可以通过创建application-{profile}.properties（或.yml）文件来实现，其中{profile}是环境的名称。
例如：
- application.properties: 默认配置，在任何Profile未激活时生效。
- application-local.properties: local Profile激活时生效。
- application-dev.properties: dev Profile激活时生效。
Spring Boot会根据激活的Profile加载相应的配置文件，并以优先级合并配置。在代码中，我们通常使用@Value注解来注入这些配置属性：
@RestController
public class TestController {
@Value("${custom.property}")
private String customProperty; // 注入名为 custom.property 的配置
@GetMapping("/testing")
public ResponseEntity getTestMethod() {
String message = customProperty + " says hello";
return ResponseEntity.ok().body(message);
}
} 问题现象：JAR包运行时的属性加载失败
在开发过程中，我们可能会遇到这样的情况：Spring Boot应用在IDE（如IntelliJ IDEA）中运行时一切正常，能够正确加载并使用application-{profile}.properties中的属性。然而，当我们将应用打包成可执行JAR文件，并通过命令行java -jar运行并尝试激活特定Profile时，却会抛出org.springframework.beans.factory.BeanCreationException: ... Could not resolve placeholder 'custom.property' in value "${custom.property}"错误，导致应用无法启动。
这个错误表明Spring Boot在初始化Bean时，无法找到名为custom.property的配置属性值。这通常是由于以下一个或多个原因造成的：
- 期望的Profile未被正确激活。
- Profile对应的配置文件未被正确打包到JAR中。
- 属性在任何激活的配置文件中都不存在。
核心原因分析：配置文件与Profile激活机制
要解决此问题，我们需要深入理解Spring Profile的激活机制、Maven资源过滤以及JAR包的结构。
1. Maven资源过滤（Resource Filtering）
在多环境配置中，我们经常使用Maven的资源过滤功能来动态设置一些属性。例如，在application.properties中设置：
# src/main/resources/application.properties spring.profiles.active=@activatedProperties@
这里的@activatedProperties@是一个Maven占位符。在pom.xml中，通过Maven Profile和资源过滤配置，我们可以在打包时将这个占位符替换为实际的Profile名称：
local local true dev dev src/main/resources true **/*.properties **/*.json
当执行mvn clean package -Pdev时，application.properties中的@activatedProperties@会被替换为dev。
2. Spring Profile激活顺序与优先级
Spring Boot激活Profile有多种方式，其优先级如下（从高到低）：
- 命令行参数： -Dspring.profiles.active=profileName
- 操作系统环境变量： SPRING_PROFILES_ACTIVE=profileName
- application.properties / application.yml： spring.profiles.active=profileName
如果application.properties中设置了spring.profiles.active=local，同时命令行又通过-Dspring.profiles.active=dev指定了Profile，那么命令行参数会覆盖配置文件中的设置。
3. application.properties的默认作用
application.properties是Spring Boot的默认配置文件。如果没有任何Profile被激活，或者Profile激活失败，Spring Boot将只加载application.properties中的配置。如果我们的custom.property只存在于application-local.properties或application-dev.properties中，而application.properties中没有定义，那么在Profile未成功激活时，就会出现Could not resolve placeholder错误。
这正是问题描述中可能出现的情况：custom.property只存在于application-local.properties和application-dev.properties，而application.properties中只有spring.profiles.active=@activatedProperties@。如果@activatedProperties@未被正确替换，或者替换后仍然导致Profile激活失败，那么custom.property将无法被找到。
诊断与解决方案
针对上述分析，我们可以采取以下诊断步骤和解决方案：
1. 检查打包后的JAR文件内容
这是诊断此类问题的首要步骤。使用jar tvf命令查看打包后的JAR文件中是否包含预期的配置文件，以及配置文件内容是否正确。
jar tvf target/myapp-standalone-0.0.1-SNAPSHOT-shaded.jar
检查以下几点：
- application.properties内容： 确认其中的@activatedProperties@是否已被Maven过滤替换为实际的Profile名称（例如local）。如果没有被替换，说明Maven资源过滤未生效。
- application-local.properties是否存在： 确认application-local.properties文件是否被正确打包到JAR的根目录或BOOT-INF/classes下。
如果application.properties中的占位符未被替换，或者application-local.properties文件缺失，那么问题就出在Maven的打包配置上。
