深入理解 Spring Boot 3.5：EnvironmentPostProcessor 与配置覆盖规则

在 Spring Boot 3.5 项目中，常常会遇到多层配置（默认配置、占位符配置、Profile 配置、外部配置、配置中心）叠加的场景。本文记录了我在实际项目中遇到的加密属性解密问题、配置覆盖顺序以及解决方案，分享对 EnvironmentPostProcessor 和 Spring Boot 配置加载顺序的理解。

通过本文，你可以了解如何在保证配置优先级正确的前提下，实现加密属性的安全解密，并避免多层配置冲突导致的运行时问题。

1. 背景介绍

在项目中，我们使用 Spring Boot 3.5，配置分为多层：

• 默认配置：common.properties，提供基础默认值
• 占位符配置：placeholder-keys.properties，用于占位符引用，如 ${ph.mysql.host}
• Profile 配置：application-dev.properties 等，覆盖本地环境特有配置
• 外部配置：通过 ExternalConfigProcessor 加载 /data/config/config.properties 等外部文件
• 配置中心：如 Nacos、Apollo，用于远程管理配置

此外，一些属性是加密的（例如数据库密码），格式为 dec()xxxx，需要在启动时解密。

2. 问题描述

在引入 ExternalConfigProcessor 和 DecryptEnvironmentPostProcessor 后，项目出现了 JDBC 连接异常：

• spring.datasource.url 中的 host 不是 profile 配置的值，也不是默认的本地值
• spring.datasource.username 和 password 已成功解密
• 调试发现原因在于解密逻辑使用了 addFirst，破坏了 PropertySource 原有顺序，导致占位符解析错误

3. 原因分析

3.1 Spring Boot 配置加载顺序

Spring Boot 3.5 的配置加载顺序（优先级从低到高）：

1. 默认属性（SpringApplication.setDefaultProperties）
2. application.properties / application.yml
3. spring.config.import 本地文件（按顺序加入，优先级低于 profile）
4. Profile 文件（application-{profile}.properties / .yml）
5. 外部配置文件（ExternalConfigProcessor.addFirst）
6. 配置中心（Nacos / Apollo）
7. 命令行参数（最高优先级）

注意：PropertySource 在 Environment 中的顺序决定了占位符 ${...} 的解析顺序，最前面的 PropertySource 优先。

3.2 问题根源

• 解密 PostProcessor 之前使用 addFirst 将解密后的属性放到最前面
• 这会覆盖 profile/import/external/远程配置的顺序
• 导致未加密属性（如 host/port）被错误解析 → JDBC 连接失败

4. 解决方案

4.1 DecryptEnvironmentPostProcessor 改为 replace

核心思想：只替换加密属性，保持 PropertySource 顺序不变。

示例实现：

private void replace(MutablePropertySources propertySources, MapPropertySource ps) {
    Map<String, Object> newSource = new HashMap<>(ps.getSource());
    boolean isReplaced = false;
    for (String name : ps.getPropertyNames()) {
        Object value = ps.getProperty(name);
        if (value != null) {
            String v = String.valueOf(value);
            if (v.length() <= decryptPrefixLength || !v.startsWith(decryptPrefix)) {
                continue;
            }
            isReplaced = true;
            v = v.substring(decryptPrefixLength);
            v = enhance.decode(v);
            newSource.put(name, v);
            LOGGER.debug("{} decrypt success !", name);
        }
    }
    if (isReplaced) {
        propertySources.replace(ps.getName(), new MapPropertySource(ps.getName(), newSource));
    }
}

• 效果：
  • username/password 解密成功
  • host/port 等未加密字段保持原有优先级
  • 与 profile/import/external/remote 配置兼容

4.2 ExternalConfigProcessor 与远程配置

• 多个 addFirst 的顺序影响最终优先级
• 远程配置中心（Nacos / Apollo）通常最后执行 addFirst → 优先级最高
• 如果希望外部文件优先于远程配置：
  • 调整 Processor 执行 order
  • 或者在 addFirst 前用 replace 覆盖远程配置中的同名属性

5. Spring Boot 3.5 配置加载顺序总结

注意：replace 可以在不破坏顺序的前提下修改 PropertySource 的部分属性。

6. 总结与经验教训

1. 多层配置优先级：Spring Boot 配置加载顺序决定最终值，占位符解析按 PropertySource 顺序查找
2. EnvironmentPostProcessor 顺序：order + addFirst/addLast/replace 决定最终覆盖关系
3. 解密逻辑：推荐使用 replace，只替换加密字段，不破坏原有 PropertySource 顺序
4. 外部文件与远程配置：多个 addFirst 时谁最后加入谁优先
5. 实战经验：
   • 调试 JDBC 等依赖配置时，先打印 PropertySource 顺序
   • 占位符 ${...} 解析顺序必须结合 PropertySource 优先级理解

源码地址：

配置文件相关可参考lite-task项目

DecryptEnvironmentPostProcessor.java

ExternalConfigProcessor.java

LcxmCommonPropertiesPostProcessor.java

[spring.factories](