4、配置文件深度剖析：rmc.config.json 结构、环境变量、多环境配置

说实话，很多同学用 RMC 命令行工具，最头疼的就是配置文件。我见过太多人，明明命令敲得飞起，结果一换环境就崩。说白了，配置文件才是整个工具的「大脑」。

今天咱们就把它彻底拆开，揉碎了讲。你想想看，一个项目从开发到测试再到上线，环境变量怎么切？多环境配置怎么管理？嗯，这些坑我都踩过，今天一并告诉你。

4.1 rmc.config.json 的核心结构

先看一个最典型的配置文件长什么样：

{
  "project": {
    "name": "my-app",
    "version": "1.0.0",
    "entry": "src/index.js"
  },
  "build": {
    "outputDir": "dist",
    "sourceMap": true,
    "minify": true
  },
  "server": {
    "port": 3000,
    "host": "localhost",
    "proxy": {
      "/api": "http://backend:8080"
    }
  },
  "env": {
    "NODE_ENV": "development",
    "API_BASE_URL": "http://localhost:8080/api"
  }
}

这个结构其实很直观。我个人习惯把配置分成四大块：项目信息、构建配置、服务配置、环境变量。每一块都有自己的职责，千万别混在一起写。

核心原则：配置文件的层级不要超过 3 层。超过 3 层，你自己过两周都看不懂。

4.2 环境变量的正确打开方式

我在项目中遇到过最头疼的事：开发环境好好的，一上测试环境就报错。查了半天，原来是环境变量写死了。

RMC 支持两种方式注入环境变量：

  1. 配置文件内定义：直接在 rmc.config.json 的 env 字段里写
  2. 系统环境变量：通过 RMC_ 前缀的变量覆盖

举个例子：

# 终端里设置
export RMC_API_BASE_URL=https://api.production.com
export RMC_NODE_ENV=production

# 然后运行 rmc build
# 工具会自动读取这些变量，覆盖配置文件里的值

为什么会这样设计？说白了，就是让你把「代码」和「配置」彻底分离。代码里永远不要出现具体的 URL 或密钥，这些都应该通过环境变量注入。

我的习惯：在 rmc.config.json 里只写开发环境的默认值。生产环境的配置，全部通过 CI/CD 流水线注入环境变量。这样本地开发不用改任何配置，上线也安全。

4.3 多环境配置的三种方案

你想想看，一个项目至少有三个环境：开发、测试、生产。每个环境的 API 地址、日志级别、调试开关都不一样。怎么管理？

我总结了三套方案，按推荐程度排序：

方案 适用场景 优点 缺点
方案一：单文件 + 环境变量覆盖 小型项目，环境差异小 简单，一个文件搞定 环境变量多了容易乱
方案二：多文件拆分 中型项目，环境差异大 清晰，每个环境独立 文件多了维护麻烦
方案三：继承 + 覆盖 大型项目，配置复杂 灵活，复用公共配置 学习成本稍高

方案一 最简单，就是上面那个单文件。通过 RMC_NODE_ENV 环境变量切换行为。适合个人项目或小团队。

方案二 是我最常用的。创建多个配置文件：

rmc.config.json          # 公共配置
rmc.config.dev.json      # 开发环境
rmc.config.test.json     # 测试环境
rmc.config.prod.json     # 生产环境

运行的时候指定环境：

rmc build --env prod

方案三 是进阶玩法。我曾经在一个大型微服务项目里用过，效果很好：

{
  "extends": "./rmc.config.base.json",
  "env": {
    "API_BASE_URL": "https://api.staging.com"
  }
}

子配置继承父配置，同名属性自动覆盖。这样公共部分只写一次，每个环境只写差异部分。

避坑指南：我曾经犯过一个错误——把数据库密码写进了配置文件，还提交到了 Git 仓库。结果整个团队都看到了生产环境的密码。记住：敏感信息永远不要写在配置文件里，必须通过环境变量或密钥管理服务注入。

4.4 配置文件的加载优先级

嗯，这里有个容易踩坑的点：当多个来源都有同一个配置项时，到底听谁的？

RMC 的加载顺序是这样的（后面的覆盖前面的）：

  1. 默认配置（工具内置）
  2. rmc.config.json 文件
  3. 通过 --config 参数指定的文件
  4. 系统环境变量（RMC_ 前缀）
  5. 命令行参数（--port=8080）

说白了，命令行参数的优先级最高。这很合理——你在终端里临时改个端口，不应该被配置文件限制住。

调试技巧：如果你不确定最终生效的配置是什么，运行 rmc config --show。这个命令会打印出合并后的完整配置，一目了然。

4.5 知识体系总览

说了这么多，咱们用一张图把整个知识体系串起来：

rmc.config.json 知识体系 rmc.config.json 项目信息 构建配置 服务配置 环境变量 name/version entry outputDir sourceMap port/host proxy NODE_ENV API_BASE_URL 多环境配置 开发 → 测试 → 生产 方案一：单文件+环境变量 方案二：多文件拆分 方案三：继承+覆盖

这张图把整个配置体系串起来了。你从中心节点出发，沿着四个分支走一遍，基本就掌握了全部内容。多环境配置在最下面，是最终的落地实践。

我的建议：刚开始用 RMC 的同学，先从方案一入手。跑通一个环境后，再慢慢扩展到多环境。别一上来就搞继承和覆盖，容易把自己绕晕。

好了，配置文件这块就讲到这里。记住一句话：配置是代码的一部分，要像对待代码一样对待它——该拆分的拆分，该注释的注释，该版本控制的版本控制。这样你的项目才能经得起折腾。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →