SpringBoot外部配置加载详解

积累知识，胜过积蓄金银！毕竟在文章开发的过程中，会遇到各种各样的问题，往往都是一些细节知识点还没有掌握好而导致的，因此基础知识点的积累是很重要的。下面本文《Spring Boot外部配置加载问题解析》，就带大家讲解一下知识点，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

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中：

1. 当前目录的/config子目录。
2. 当前目录。
3. 一个config包（通常指类路径下的config目录）。
4. 类路径根目录（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中的配置。

注意事项与最佳实践

1. 遵循约定优于配置原则： Spring Boot的设计哲学是“约定优于配置”。遵循其默认的目录结构和命名约定，可以大大简化配置管理，减少不必要的复杂性。
2. 理解加载优先级： 如果在多个默认位置都存在同名或同Profile的配置文件，Spring Boot会按照优先级规则进行覆盖。例如，外部/config目录下的配置会覆盖类路径下的配置。
3. 其他激活Profile的方式： 除了在application.properties中设置spring.profiles.active，您还可以通过以下方式激活Profile：
   • JVM系统属性： -Dspring.profiles.active=dev
   • 环境变量： SPRING_PROFILES_ACTIVE=dev
   • 命令行参数： --spring.profiles.active=dev 这些方式的优先级通常高于application.properties中的设置。
4. 自定义配置源： 如果确实有特殊需求，需要从完全自定义的、非Spring Boot默认查找路径加载配置，可以考虑实现EnvironmentPostProcessor接口或自定义PropertySourceLocator。但这通常只在非常复杂的场景下才需要，并且会增加系统的复杂性。对于Profile特定的配置文件，强烈建议遵循Spring Boot的默认约定。

总结

Spring Boot的外部化配置功能强大而灵活，但其对配置文件位置的约定是其正常工作的基础。当遇到Profile特定配置文件无法加载的问题时，首先应检查这些文件是否位于Spring Boot默认的四个查找位置之一。将它们放置在src/main/resources目录下是最常见且推荐的解决方案，能够确保spring.profiles.active机制的正确生效，从而避免不必要的自定义配置和潜在的问题。遵循Spring Boot的约定，是构建健壮、可维护应用的基石。

本篇关于《SpringBoot外部配置加载详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！