Spring Boot 属性文件加载机制概述
spring boot以其强大的外部化配置能力而闻名，其中最核心的便是通过application.properties或application.yml文件来管理应用配置。当涉及到特定环境的配置时，spring boot支持使用application-{profile}.properties（或.yml）的命名约定，通过激活相应的profile来加载这些配置。然而，spring boot对这些配置文件的查找位置有严格的约定。
根据Spring Boot的官方文档，SpringApplication会从以下四个默认位置加载application.properties（以及其Profile特定版本）文件，并将其添加到Spring Environment中：
- 当前目录的/config子目录。
- 当前目录。
- 一个config包（通常指类路径下的config目录）。
- 类路径根目录（classpath root），例如src/main/resources。
这些位置的优先级从高到低排列，即/config子目录下的配置会覆盖当前目录的配置，依此类推。对于application-{profile}.properties文件，Spring Boot也会遵循相同的查找顺序。
自定义路径加载失败的原因分析
在实际开发中，开发者有时会尝试将application-{profile}.properties文件放置在src/main/resources下的自定义子目录中，例如src/main/resources/properties。当在application.properties中通过spring.profiles.active=dev激活dev环境时，Spring Boot并不会自动去src/main/resources/properties目录下查找application-dev.properties。这是因为该自定义目录不属于Spring Boot默认的四个查找位置之一。
即使尝试通过自定义PropertySourcesPlaceholderConfigurer或AbstractSecurityWebApplicationInitializer来手动加载这些文件，也往往难以达到预期效果。例如，原始问题中提供的DevPropertyReader类：
@Configuration
@Profile("local")
public class DevPropertyReader {
@Bean
public static PropertySourcesPlaceholderConfigurer properties() {
PropertySourcesPlaceholderConfigurer ppc = new PropertySourcesPlaceholderConfigurer();
// 显式指定了 application.properties 和 EnvironmentProfiles/application-local.properties
Resource[] resources = new ClassPathResource[] { new ClassPathResource("application.properties"), new ClassPathResource("EnvironmentProfiles/application-local.properties") };
ppc.setLocations(resources);
ppc.setIgnoreUnresolvablePlaceholders(true);
System.out.println("env active profile");
return ppc;
}
}这段代码的问题在于，它尝试显式加载EnvironmentProfiles/application-local.properties。虽然这能加载到特定文件，但它绕过了Spring Boot自动根据spring.profiles.active来动态加载application-{profile}.properties的机制。这意味着，如果spring.profiles.active被设置为dev而不是local，或者有其他Profile，这个手动配置将无法生效。同时，ActiveProfileConfiguration类主要是为了通过ServletContext或系统环境变量设置spring.profiles.active，但它本身并不解决从非标准路径加载Profile特定文件的问题。核心在于，Spring Boot的外部化配置机制期望这些文件位于其预定义的查找路径中。
推荐解决方案
解决此问题的最简单、最直接且符合Spring Boot规范的方法，就是将Profile特定的配置文件（如application-dev.properties、application-prod.properties）移动到Spring Boot默认的查找位置之一。最常见的做法是将其放置在类路径根目录，即src/main/resources目录下。
示例：
假设您的项目结构如下：
src
└── main
└── resources
├── application.properties
└── properties
├── application-dev.properties
└── application-prod.properties为了让Spring Boot能够正确加载application-dev.properties或application-prod.properties，您只需将它们从properties子目录中移出，直接放在src/main/resources目录下：
src
└── main
└── resources
├── application.properties
├── application-dev.properties
└── application-prod.properties完成此操作后，您可以在application.properties中指定：
# src/main/resources/application.properties spring.profiles.active=dev
或者通过命令行参数、环境变量等方式激活Profile，Spring Boot将能够自动找到并加载application-dev.properties中的配置。
注意事项与最佳实践
- 遵循约定优于配置原则： Spring Boot的设计哲学是“约定优于配置”。遵循其默认的目录结构和命名约定，可以大大简化配置管理，减少不必要的复杂性。
- 理解加载优先级： 如果在多个默认位置都存在同名或同Profile的配置文件，Spring Boot会按照优先级规则进行覆盖。例如，外部/config目录下的配置会覆盖类路径下的配置。
-
其他激活Profile的方式： 除了在application.properties中设置spring.profiles.active，您还可以通过以下方式激活Profile：
- JVM系统属性： -Dspring.profiles.active=dev
- 环境变量： SPRING_PROFILES_ACTIVE=dev
- 命令行参数： --spring.profiles.active=dev 这些方式的优先级通常高于application.properties中的设置。
- 自定义配置源： 如果确实有特殊需求，需要从完全自定义的、非Spring Boot默认查找路径加载配置，可以考虑实现EnvironmentPostProcessor接口或自定义PropertySourceLocator。但这通常只在非常复杂的场景下才需要，并且会增加系统的复杂性。对于Profile特定的配置文件，强烈建议遵循Spring Boot的默认约定。
总结
Spring Boot的外部化配置功能强大而灵活，但其对配置文件位置的约定是其正常工作的基础。当遇到Profile特定配置文件无法加载的问题时，首先应检查这些文件是否位于Spring Boot默认的四个查找位置之一。将它们放置在src/main/resources目录下是最常见且推荐的解决方案，能够确保spring.profiles.active机制的正确生效，从而避免不必要的自定义配置和潜在的问题。遵循Spring Boot的约定，是构建健壮、可维护应用的基石。
