怎么通过 System.getenv() 与 System.getProperty() 的协同工作实现多级配置变量覆盖

在Ja va配置管理的实践中，环境变量、JVM参数和代码默认值三者可以构建出一条清晰的三级覆盖链：环境变量优先级最高，JVM参数次之，代码默认值做最后的兜底。为了规范且统一地使用这套机制，建议封装一个按序查找的工具方法，同时将键名风格统一为大写加下划线，这样能确保跨平台的一致性。

具体来说，环境变量（通过System.getenv()获取）优先级最高，它可以覆盖Ja va系统属性（System.getProperty()），而系统属性又可以覆盖代码里写死的硬编码默认值。这样，就形成了“环境变量 > JVM 参数 > 代码默认值”的三级配置覆盖链。

明确覆盖优先级与用途分工

环境变量尤其适合在部署时做差异化配置，比如不同服务器上的数据库地址。JVM参数（通过 -Dkey=value 传入）则适合在启动时动态指定一些开关，比如测试环境的标识。代码中的默认值只是最后的兜底方案。这三者并不冲突，关键是要按需组合使用，避免在代码里随意混用 getenv 和 getProperty 读取同一个键名，那样很容易造成逻辑混乱。

统一读取封装：优先查环境变量，未命中再查系统属性

推荐封装一个工具方法，严格按照固定顺序查找，这样可以保证各处读取逻辑一致，避免重复编写。下面是一个示例：

public static String getConfig(String key, String defaultValue) {
    // 1. 先查环境变量（最高优先级）
    String envValue = System.getenv(key);
    if (envValue != null && !envValue.trim().isEmpty()) {
        return envValue.trim();
    }
    // 2. 再查 JVM 系统属性（-Dkey=value）
    String propValue = System.getProperty(key);
    if (propValue != null && !propValue.trim().isEmpty()) {
        return propValue.trim();
    }
    // 3. 返回硬编码默认值
    return defaultValue;
}

调用示例：getConfig("DB_URL", "jdbc:h2:mem:test") —— 如果环境中设置了 DB_URL= jdbc:mysql://prod:3306/app，就直接返回环境变量值；否则去查 -DDB_URL=...；都没设置就用默认的 H2 内存库。

注意键名大小写与命名规范

这里有个细节需要留意：环境变量在 Linux/macOS 上通常全大写并用下划线（比如 REDIS_HOST），而 JVM 属性习惯用小写加点号（比如 redis.host）。如果想复用同一套配置逻辑，最好统一键名风格。两种方案供参考：

• 方案一（推荐）：约定所有配置项使用大写+下划线（如 APP_TIMEOUT_MS），环境变量和 JVM 参数都按此命名（启动时传 -DAPP_TIMEOUT_MS=5000）。
• 方案二：做映射转换，比如将 redis.host 自动转为 REDIS_HOST 再去查环境变量，但需要注意平台兼容性——Windows 环境变量不区分大小写，Linux 是区分的。

配合 Spring Boot 或其他框架时的注意事项

Spring Boot 本身就内置了类似的多源配置合并机制（支持 ENV、systemProperties、systemEnvironment 多源合并）。如果你手动使用 System.getenv/System.getProperty，有几点需要注意：

• 不要在 @Value 或 @ConfigurationProperties 中混用原始 API，应该统一走 Spring 的 Environment 抽象。
• 如果必须手动读取（比如在静态工具类初始化时），要确保在 Spring Context 创建前完成，或者使用 @PostConstruct 延迟加载。
• JVM 参数是在 ja va -D... 启动时传入的，运行时通过 System.setProperty 修改不会影响已经读取的配置——除非重新触发读取逻辑。