学委好久没有更新NodeJS专栏，还以为NodeJS冷门，没想到最近看到几个读者留言问怎么优雅的管理多环境的配置。
太忙了，写篇短文简单展示一下原理。正好基于前篇 【NodeJS 后端开发 07 MySQL数据库连接池开发生产应用 】简单尝试了mysql库来连接数据库。
本篇尝试一个更加优雅的方式，通过环境变量来控制程序动态加载不同的配置。
这个搞Java的同学最清楚，比如我们开发springboot应用的时候会放置多个application.yml。
然后部署的时候通过环境变量来选择配置。
这个用NodeJS来做就更加简单了
NODE_ENV=process.env.NODE_ENV console.log('NODE_ENV:', NODE_ENV)
直接贴在node REPL 终端查看：
process对象为Node上下文的内置对象，可以直接获取，这个对象管理了node进程相关的数据。
比如 process.env就是我们获取环境变量设置的入口了（读者可以自行打印查看更多信息）。
配置一个环境变量，重试代码
export NODE_ENV=雷学委
打开node的终端
这里我们看到，设置的环境变量被进程内部读取到了。
继续根据环境自适应的profiling。
上面展示了设置不同变量代码中能够获取到该环境变量的值。
安照这个机制，我们可以把配置文件按照下面进行命名，让程序加载不同的文件名，比如下面：
config.dev.json
config.testing.json
config.prod.json
然后只需要写一份应用代码：
复制下面代码保存为app.js
//雷学委Demo代码 const NODE_ENV=process.env.NODE_ENV || 'dev' console.log('NODE_ENV:', NODE_ENV) //定位当前目录下的config.<环境类型>.json const configPath = __dirname + '/config.' + NODE_ENV + '.json' console.log('configPath:', configPath) //加载并打印数据库的配置细节 const dbConfig = require(configPath) console.log('dbConfig:', dbConfig)
我们直接来看效果；
运行代码在这：
#开发环境启动应用 node app.js
#测试环境启动应用 export NODE_ENV=testing && node app.js
#生产环境启动应用 export NODE_ENV=prod && node app.js
很轻松吧，一份代码根据不同的环境适配了。
实际运行应用app.js的服务器，上面会配置环境变量NODE_ENV为对应的dev/testing/prod值。
上面代码仅为原理展示。
好了到这里读者应该能够懂得profling如何做了。（可以三连了）
下面看看为什么。
为啥搞这么多外部配置，直接写在代码里面根据主机名字加载不好么？
一般企业会有大量的服务器，然后会把服务器划分为几类，比较典型的划分为：
很多中大公司会有下面这样一个划分：
这样能够把一个应用层层把关提拔到最上层的生产环境（production）。
学委想对小白说的： 比如说一个游戏的新功能，往往会经过开发机器调试，然后大量测试，把大量的潜在的重要的bug解决了，提拔到预发布，最后到生产环境。这个过程通过一些列的自动化测试，回归测试，可以大大保证系统的质量。还有一种高端玩法就是灰度发布，加上这个制度，这就是我们常说产品平滑上线的流程了。
这好像扯远了，产品发布这一套能再写亿篇！
我们回到主题，通常就是只开发一份代码，发布到不同环境之后，程序动态的连接到正确的数据库，加载对应的数据，数据虽不同但是程序在任意环境的行为要绝对一致。
这里配置外部化考量是：配置外部化可以减少代码跟环境的耦合
而不是发布一个类型的环境，就得修改代码。
特别是互联网/金融项目都会有严苛的质量把关，哪怕是修改一个标点符号，整个产品提升的过程都得从开发环境重新来过。
因此，配置外部化很有必要。
那么，应用能否跟外部环境毫无关联？
比较有经验的朋友，可能会想匿名函数，或者亚马逊的lamda，或者serverless app（无服务器应用）
如果业务没有任何环境区分，那就可以做到程序跟环境没有耦合，这就充分的说明了serverless的一个优点！（没有耦合，意味着随便拿一个云服务器部署，即可轻松实现弹性伸缩了，但这并非此文出发点，有机会再说）
