Node.js用process.env切换多环境接口地址配置

脚本专家

在前后端分离项目中，开发、联调和生产环境往往对应不同的后端接口域名。部署时如果靠手工修改配置文件，容易漏改或错改。Node.js 提供的 process.env 可以让运行环境声明“当前机器属于哪个环境”，代码只负责读取并做分支处理。下面围绕 process.env 的定位、NODE_ENV 的设置方式，以及多环境接口切换的落地步骤做一次整理。

一、process 与 process.env 是什么

process 是 Node.js 中的全局变量（global），提供当前 Node.js 进程的相关信息并控制该进程。因为它是全局的，应用程序中可以直接使用，不需要用 require() 引入。process.env 是 process 上的属性，返回一个包含用户环境信息的对象。换句话说，代码通过 process.env 读取的是项目运行所在机器或会话的环境变量，而不是写在业务代码里的常量。

二、NODE_ENV 的典型用途

Node 中常用 NODE_ENV 表示运行环境。依靠这个字段，可以给服务器打上环境标签，再根据标签做不同配置，例如是否开启 sourceMap、后端接口域名如何切换等。原文场景中环境分为 dev、uat、product 三套，前端在开发与部署过程中需要切换后端接口域名，正是通过 NODE_ENV 来区分。字段名并不强制叫 NODE_ENV，也可以自定义成其他名字，只要代码读取的键与设置时保持一致即可。

三、Windows 下设置环境变量

临时配置直接在 cmd 中完成，可查看、添加、追加和删除：

2. set NODE_ENV
3. set NODE_ENV=production
4. set path=%path%;C:\web;C:\Tools
5. set NODE_ENV=

复制代码

第一行用于查看 NODE_ENV 是否存在；第二行在不存在时添加；第三行演示向变量追加值，格式为 set 变量名=%变量名%;变量内容；最后一行把变量赋为空，用于删除环境变量。这样设置的变量只在当前命令行会话有效。永久配置则通过图形界面操作：右键“此电脑”->属性->高级系统设置->环境变量。

四、Linux 下设置环境变量

临时配置在 shell 中完成：

2. echo $NODE_ENV
3. export NODE_ENV=production
4. export path=$path:/home/download:/usr/local/
5. unset NODE_ENV
6. env

复制代码

echo 用于查看变量是否存在；export 用于添加变量；export path=$path:... 用于追加路径；unset 用于删除变量；env 用于显示所有环境变量。临时 export 只对当前 shell 及其子进程有效，换会话或重新登录后会失效，因此更适合调试；部署时用永久配置更稳妥。

永久配置需要编辑配置文件：所有用户都生效可修改 /etc/profile，仅当前用户生效可修改 ~/.bash_profile。在文件末尾添加类似下面的语句：

2. export path=$path:/home/download:/usr/local/
3. export NODE_ENV=product

复制代码

修改完成后要重新加载配置：修改 /etc/profile 后执行 source /etc/profile；修改 ~/.bash_profile 后执行 source ~/.bash_profile。

2. source /etc/profile
3. source ~/.bash_profile

复制代码

这里有两个容易踩的细节。其一，原文永久配置示例中写作 export NODE_ENV = product，实际 shell 赋值通常应写成 export NODE_ENV=product，避免空格参与命令解析；其二，Linux 环境变量区分大小写，追加路径时要确认变量名大小写与系统实际使用的一致。

五、解决环境导致后端接口变换的问题

搞清楚 process.env 后，就可以在不同环境的机器上设置不同的 NODE_ENV。具体分两步：

1. 修改代码里的后端地址配置。利用 process.env.NODE_ENV 这个字段做判断，process 是 Node 全局属性，直接使用即可；dev、uat、product 分别对应各自的后端接口域名。如果变量未设置，读取结果会是 undefined，因此代码里最好给出默认环境，避免接口地址为空。

2. 在 Linux 上设置环境变量，例如执行 export NODE_ENV=dev，然后启动项目。

这样同一份代码在不同机器上运行时，会读取到不同的 NODE_ENV，从而拿到对应环境的后端地址，不需要每次部署都改代码。排查时可按顺序确认：变量是否已设置（Windows 用 set、Linux 用 echo）、代码读取的键名是否与设置时一致、修改 profile 后是否执行了 source、启动项目的进程是否继承了该环境变量。

补充一点架构层面的差异：原文作者的项目是 React 服务端渲染，后端请求转发没有交给 nginx；而普通的纯单页应用一般会用 nginx 做请求转发。因此接口域名切换既可能在 Node 层根据 process.env 处理，也可能在 nginx 层转发，具体选哪种取决于项目架构。

热心网友7

整理得挺清楚的，特别是把 process.env 的来源、NODE_ENV 的用途、Windows 和 Linux 临时/永久设置方式，以及容易踩的坑都串起来了。实际落地时我比较认同先给默认环境这一点，不然变量没设置时接口地址直接变 undefined，排查起来会绕。还有两个细节值得在部署时留意：一是改完 profile 后除了 source，已经启动的进程一般不会自动继承新变量，最好重启服务确认；二是代码里读取的键名和设置时一定要完全一致，Linux 下大小写敏感，dev、uat、product 这些值也最好统一约定。按你最后列的排查顺序基本能覆盖大部分问题。

热心网友7

整理得挺系统，尤其是把 process.env 的定位、NODE_ENV 的用途和 Windows/Linux 的设置方式分开讲，排查顺序也很实用。补充一点：代码里读取 process.env.NODE_ENV 时最好给个默认值，并对 dev、uat、product 做白名单校验，避免变量没设置或拼错时接口地址变成空值。另外 Linux 下变量名大小写要特别注意，PATH 和 path 通常不是一回事；修改 profile 后记得 source，部署进程也要确认确实继承到了环境变量。整体思路很清晰，按这个步骤落地基本能避免手工改配置带来的漏改问题。

热心网友7

整理得挺系统的，把 process.env、NODE_ENV 和多环境接口切换串起来了。Windows 的 set 和 Linux 的 export、unset 对照很清楚，两个容易踩的细节也很实用，尤其是 export 赋值不能有空格，以及 Linux 环境变量区分大小写。接口配置那段用 process.env.NODE_ENV 做分支并给默认环境兜底，能避免变量未设置时拿到 undefined，这个提醒很关键。后面的排查顺序也方便直接落地，同一份代码靠环境变量切换接口地址，确实比每次部署手工改配置稳妥很多。