15.2 多环境配置：开发、测试、生产环境隔离

在 Electron 应用开发中，你一定会遇到这样的场景：开发时希望窗口自动打开 DevTools、加载本地代理的 API 地址；测试时需要连接内网的测试服务器、输出详细日志；而到了生产环境，必须关闭调试工具、切换为正式的接口地址、启用自动更新。这些差异如果靠手工注释代码来切换，不仅低效，还极易导致配置泄漏到线上。因此，在项目初期就建立一套清晰的环境隔离机制，是保证工程质量和安全性的关键一步。

15.2.1 环境变量的定义与注入

Electron 应用本质上同时运行在 Node.js 环境和浏览器环境，这两个环境对“环境变量”的理解不完全相同。Node.js 侧可以直接读取 process.env，而浏览器侧的代码通常无法访问 Node.js 的 process 对象（在现代安全实践中，渲染进程的 nodeIntegration 通常被关闭）。因此，我们需要一种统一的机制，将环境标识注入到应用的各个角落。

方案一：使用 cross-env 和 webpack.DefinePlugin / vite.define

这是最通用的做法。在项目根目录的 package.json 中，通过 cross-env 设置环境变量，然后在打包工具中注入：

// package.json
{
  "scripts": {
    "dev": "cross-env NODE_ENV=development electron .",
    "test": "cross-env NODE_ENV=test electron-builder --config",
    "build": "cross-env NODE_ENV=production electron-builder"
  }
}

对于使用 Webpack 的项目，在 webpack.config.js 中通过 webpack.DefinePlugin 将 process.env.NODE_ENV 替换为字符串字面量：

new webpack.DefinePlugin({
  'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV || 'production'),
});

Vite 用户则可以直接使用 define 配置项：

// vite.config.js
export default defineConfig({
  define: {
    'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV),
  },
});

经过这样的编译时替换，你的渲染进程代码中就可以安全地使用 process.env.NODE_ENV，而且它会在打包时被硬编码为对应环境的字符串，既避免了运行时跨环境访问 Node.js API 的安全问题，也获得了良好的死码消除效果。

方案二：使用 dotenv 加载 .env 文件

对于更复杂的多环境变量（比如 API 地址、密钥、第三方服务标识），建议使用 .env 文件来管理。在主进程中你可以直接使用 dotenv 库：

// main.js
const dotenv = require('dotenv');
const path = require('path');

// 根据启动参数或 NODE_ENV 加载对应 .env 文件
const envFile = process.env.NODE_ENV === 'test' ? '.env.test' : '.env';
dotenv.config({ path: path.join(__dirname, envFile) });

渲染进程需要通过编译时注入的方式获取这些变量。你可以在 Vite 或 Webpack 中读取 process.env 并将需要的变量显式替换掉。

15.2.2 开发环境的特征

开发环境追求的是极致的反馈速度和调试便利性。通常你需要在主进程代码中进行以下判断：

// main.js
const isDev = process.env.NODE_ENV === 'development';

function createWindow() {
  const win = new BrowserWindow({
    webPreferences: {
      devTools: isDev,  // 生产环境关闭 DevTools
    },
  });

  if (isDev) {
    win.loadURL('http://localhost:3000'); // 开发时加载前端 dev server
    win.webContents.openDevTools();
  } else {
    win.loadFile(path.join(__dirname, 'dist/index.html'));
  }
}

同时，开发环境常常需要允许某些安全策略的放松（例如打开 nodeIntegration 以便快速调试），但你必须在代码中通过环境变量严格限定，以免这些配置误入生产发布。

15.2.3 测试环境与持续集成

测试环境介于开发和正式发布之间，一般用于 QA 团队和自动化测试。它的配置特点通常包括：

连接内网的测试服务器，而不是生产 API；
开启更详细的日志输出（如 electron-log 的 debug 级别）；
关闭自动更新检查，防止测试过程中弹出更新提示；
可能包含特殊的菜单项，用来触发测试辅助功能（如清空缓存、模拟崩溃）。

在 CI 环境中，你可能会直接用命令行参数区分测试配置：

cross-env NODE_ENV=test electron . --test-server=http://192.168.1.100:8080

主进程中通过 process.argv 或使用 commander 解析这些参数，再结合 app.commandLine.appendSwitch 设置 Chromium 的内部开关，以达到所需的测试状态。

15.2.4 生产环境的安全锁定

生产环境是交付给最终用户的，安全与性能是第一优先级。配置上必须严格收紧：

禁用 DevTools、nodeIntegration、remote 模块（如果还在使用）。
启用 contextIsolation，确保渲染进程无法直接触碰 Node.js。
使用预加载脚本和 contextBridge 精确暴露 API。
强制使用生产环境的 API 地址，且不能留给用户修改的入口（除非是设置页面由用户主动配置）。
启用自动更新，并将更新源指向稳定的生产服务器。
压缩资源、开启签名（macOS 的 Hardened Runtime，Windows 的代码签名），防止被篡改。

这些配置大多可以通过环境变量结合 electron-builder 的配置文件完成。例如，在 electron-builder.yml 中根据环境选择不同的更新服务器：

# electron-builder.yml
publish:
  provider: generic
  url: ${env.UPDATE_SERVER}

然后在 CI 构建生产包时设置 UPDATE_SERVER=https://update.yourdomain.com，测试包则指向一个测试用的更新地址。

15.2.5 实用的工程结构建议

为了将环境隔离的思想落到实处，推荐在项目中建立一个集中的配置模块，作为所有环境变量的唯一出口：

// config/index.js
const env = process.env.NODE_ENV || 'production';

const configs = {
  development: {
    apiBase: 'http://localhost:4000',
    devTools: true,
    logLevel: 'debug',
    autoUpdate: false,
  },
  test: {
    apiBase: 'http://test-api.example.com',
    devTools: true,
    logLevel: 'verbose',
    autoUpdate: false,
  },
  production: {
    apiBase: 'https://api.example.com',
    devTools: false,
    logLevel: 'error',
    autoUpdate: true,
  },
};

module.exports = configs[env];

然后在主进程和可渲染进程（通过编译时注入）中直接引入这个配置对象。这样做的好处是所有环境差异一目了然，修改参数时不需要在代码各处搜索 if (isDev) 的散落逻辑，也避免了因为环境判断遗漏导致的生产事故。

15.2.6 避免常见陷阱

永远不要在源码中硬编码生产环境的密钥或接口地址，即使它们被打包进 asar 文件，也可以被反编译提取。敏感数据应通过环境变量注入或由后端动态获取。
测试环境与生产环境务必使用独立的代码签名证书。如果测试环境的证书泄露，不会影响正式版本的签名链条。
在打包前务必验证 NODE_ENV 的值。许多团队在 CI 流水线中专门加入一个检查步骤，确保生产包中不会残留 devDependencies 或开发模式的代码片段。

多环境配置看似琐碎，却是桌面应用工程化的基石。它让同一个代码库能够优雅地应对从开发调试到用户交付的全生命周期，而不会因为一个漏掉的 if 条件就让数万用户的应用程序崩溃或暴露内网地址。