看了一篇外文，讲如何使用node环境变量的。这期我也结合自己的一些经验写写读后感吧。
概述
说来话长，我最早接触环境变量还是在学Java的时候。特地找了张比较复古的图片，记得当时照着书本配环境变量都折腾好了几天。我后来还写到了百度知道里，现在都能搜到。
无论何种语言，在开发和生产中，我们都会碰到各种各样的环境变量，直接写到系统环境里显然不合适。不过，也有例外。我刚进厂的时候，我们的产品还真的就是给客户环境加无数的系统变量，当时都震惊了。（汗）
Node开发
在Node开发中我们又是怎样使用环境变量的呢？
命令行
每次运行前先set各种变量，这个自然很蠢，就不往下说了。
set PROT=8080
node main.js
cross-env
cross-env是npm script里最常用的一种添加环境变量的方式：用法很简洁，先在本地安装cross-env包，接着往package.json的script里一路列变量就行了。
yarn add -D cross-env
// package.json
{
"scripts": {
"main": "cross-env NODE_ENV=production SCOPE=onion node main.js"
},
"dependencies": {
"cross-env": "^5.1.4"
}
}
如上，调用的时候在控制台运行yarn main或是npm run main，环境变量就起效果了。具体体现如下，就是把代码里的proces.env.*给替换成npm script里对应的值。
// main.js
console.log(proces.env.NODE_ENV); // production
console.log(proces.env.SCOPE); // onion
dotenv
cross-env很简洁，但也过于简单——它只能适应仅有少数环境变量的程序。假如有成百上千个变量值呢，我总不可能把这些都列在package.json里吧？
OK，你可以把这成百上千的变量放到文件里，比如给这个文件起个名字叫.env。
# .env
NODE_ENV=production
SCOPE=onion
PORT=8080
DB_CONN="balabala"
...
事实上就是有一个叫dotenv的npm包这么做的。安装还是一样简单：
yarn add -D dotenv
接着在main.js的开头加一句require("dotenv").config()，它就会在运行时自动读取根目录里.env文件的配置了。
// main.js
require('dotenv').config();
console.log(proces.env.NODE_ENV); // production
console.log(proces.env.SCOPE); // onion
当然，你不想在代码里四处添加require('dotenv')，也可以选择预加载——加个-r参数就行了。有的人还喜欢把这个这些配置加到vscode的launch.json里，道理是一样的。
node -r .env main.js
Webpack
Webpack一般用于前端模块的构建和打包，但事实上对node后端项目打包也很方便。我在部署lambda function的时候就用到了webpack，它能把一个庞大的项目压缩至几兆，是解决aws lambda依赖大小限制的重要手段。
OK，webpack处理环境变量与上述种种略有不同，并非运行时调取proces.env对象；而是在build时用字符串替换掉所有proces.env.*。
// main.js
console.log(proces.env.NODE_ENV);
console.log(proces.env.SCOPE);
上述代码事实上在打包后等价于：
console.log('production');
console.log('onion');
有个很经典的webpack插件叫DefinePlugin，就可以处理这些变量，他用于定义全局常量。你可以这么使用：
// webpack.config.js
module.exports = {
...
plugins: [
new webpack.DefinePlugin({
'process.env.NODE_ENV': 'production',
'process.env.SCOPE': 'onion'
})
]
...
};
后来，我又发现了一个专门处理环境变量的插件叫EnvironmentPlugin, 它与DefinePlugin最后等价。
// webpack.config.js
module.exports = {
...
plugins: [
new webpack.EnvironmentPlugin({
NODE_ENV: 'production'
SCOPE: 'onion'
})
]
...
};
有了EnvironmentPlugin就可以把所有变量都放到webpack.config.js。当然，假如你坚持需要专门的.env文件里，强大如webpack社区也早已为你考虑到了——dotenv-webpack。同dotenv一样，你把所有环境变量列到.env里，然后在webpack.config.js添加新插件即可。
// webpack.config.js
const Dotenv = require('dotenv-webpack');
module.exports = {
...
plugins: [
new Dotenv()
]
...
};
VS Code
VS Code是目前最主流的Node开发工具，假如开发组团队全部使用VS Code，大家也可以把环境变量配到.vscode/launch.json里。
// launch.json
{
"configurations": [
{
"env": {
"NODE_ENV": 'production'
"SCOPE": 'onion'
}
}
]
}
VS Code也可以和.env文件打通：
// launch.json
{
"configurations": [
{
"envFile": "${workspaceFolder}/.env"
}
]
}
生产环境
上面提到的都是本地开发环境里如何使用环境变量，但是在生产环境里必须要有更多安全的考量；环境变量很可能包含敏感信息，比如数据库密码、access key、credentials等等。因此这些变量不适合直接提交到较开放的代码仓库里。一般的解决方法有这么几种：
-
私有部署
将配置文件上传到私有Git上，并在build或是运行时，依靠构件工具自动拉取这些配置。
-
持久化配置服务
云服务商都会打包持久化配置服务，主要就是存储环境变量。比如aws的Systems manger，我经常用它里面的SSM:parameter store来处理lambda的环境配置。这些配置可以直接通过云服务自带的SDK获取：既可以运行前预加载，也可以在运行时异步加载。这个服务与role相关，因此确保了第三方服务器即便拿到了Token也无法访问。
-
加密服务
在某些安全级别特别高的服务器里，内部私有Git都不被允许，还不信任敌国势力股权下的云服务商，那就只能使用加密服务了。一般来说就是将所有环境变量加密存储，并利用SDK解密后放入运行环境中。
小结
环境管理是开发中经常碰到的问题。我记得以前开发团队内部会手手相传某个巨大的配置文件；谁也不知道它们各自的作用，且经常被人更改，每次更改后如果不到某个环节还不知道特定效果。因此每天都会有人喊，“咋又打不开了？”，“可能是一个月前改的某个变量吧，我的配置发给你试试。”
想起来还是回味无穷的。现在开发中除了极少数配置，我已经把绝大多数环境变量放到AWS的Systems manager里了，开发时也是动态读取。Systems manager价格也很便宜，一个月几毛钱吧。许多问题开阔一下眼界就迎刃而解了。
