我有一台云主机，已经运行了好几年。上面跑了很多乱七八糟的服务，大部分都是用 Node.JS 写的。由于开发和部署的时间不同，这些服务运行在 Node.JS 的不同版本下。运行在老的 Node.JS 版本下的程序往往都不能运行在新的 Node.JS 版本下，我也没兴趣（精力）去把它们逐一升级。因此我就有了这样的需求，不同版本的 Node.JS 需要在同一台服务器上 Side By Side 地运行，且相互不干扰。
nvm vs. n
大部分 Node.JS 开发者，甚至很多前端、React-Native 开发者都知道 nvm，而且在工作中也往往用它来切换 Node.JS 的版本。但是 nvm 却不适合运行在服务器上，因为它的缺省配置都是在当前开发用户下的，并且以开发时切换 Node.JS 作为它的主要场景。
在服务器上，则需要用到 TJ 的写的另外一个工具：n。本文不是 n 的教程，所以最好你先去看看官网的 README。
n 可以通过 npm 全局安装，因此其执行本体缺省在 /usr/local/lib/node_modules/n 下，有个 Symbolic Link 在 /usr/local/bin/n。通过 n 下载的不同版本的 Node.JS 文件，则被放在 /usr/local/n/versions/node 下面（如果你安装过 iojs，那么还会有 iojs 的目录）:
即使 n 升级了，这些安装过的不同版本的 Node.JS 文件也都在，无需重新安装。
你可以先安装几个 Node.JS 的版本：
n 0.10.41
n 5.4.1
测试程序
然后随便创建个目录，写个 index.js:
console.log(process.version)
console.log(process.argv)
执行 n use 0.10.41 index.js，返回:
v0.10.41
[ '/usr/local/n/versions/node/0.10.41/bin/node',
'/Users/rongshen/trash/nv/index.js' ]
执行 n use 5.4.1 index.js，返回:
v5.4.1
[ '/usr/local/n/versions/node/5.4.1/bin/node',
'/Users/rongshen/trash/nv/index.js' ]
看，你的程序可以通过这种方式运行在不同的 Node.JS 版本下，还不耽误传参数。
Daemon
既然是服务，就要运行在后台(Crontab 或者 Service)。那么 n 的使用就必须使用完整路径，例如：
/usr/local/bin/n use 0.10.41 index.js
从其他全局 Node.JS Tools 启动
有时，我们的服务是从其他全局 Node.JS 工具启动的，例如 forever。那么可以首先找出 forever 的绝对路径：
> which forever
/usr/local/bin/forever
然后执行：
> /usr/local/bin/n use 0.10.41 /usr/local/bin/forever index.js
forever 比较特别之处在于，它可以通过 -c 参数指定启动的 Node.JS 程序的版本，因此你也可以写成：
> forever -c `n bin 0.10.41` index.js
warn: --minUptime not set. Defaulting to: 1000ms
warn: --spinSleepTime not set. Your script will exit if it does not stay up for at least 1000ms
v0.10.41
[ '/usr/local/n/versions/node/0.10.41/bin/node',
'/Users/rongshen/trash/nv/index.js' ]
error: Forever detected script exited with code: 0
上面的 warn 和 error 不用去管。这里用到了 n bin 0.10.41，这个 bin 参数是用来返回特定 Node.JS 版本的安装目录的，例如:
> n bin 0.10.41
/usr/local/n/versions/node/0.10.41/bin/node
pm2
pm2 比较特别，它自己从全局的 node 来 fork 服务进程。所以你需要告诉 pm2 用哪个程序来作为服务程序的解释器，写法如下：
> pm2 -f start index.js --interpreter `n bin 4.2.4`
生产环境尽量少用全局工具
其实在生产环境下（甚至在大部分开发环境下），我都建议将这些全局工具安装在本工程的目录下安装一份，例如，通过 npm install gulp 而不是 npm install gulp -g。
这些工具会被安装到当前目录下的 ./node_modules/.bin 中，引用这里的版本可以避免全局版本冲突:
> ./node_modules/.bin/gulp your-gulp-task
而不是:
> gulp your-gulp-task
另外，package.json 中的 scripts 也会将 ./node_modules/.bin 加入到可执行文件的搜索目录中， 所以在 package.json 的 scripts 中是可以简写为：
"scripts": {
"start": "gulp your-gulp-task"
},
npm 或优先到 ./node_modules/.bin 里找 gulp。
这些方法可以让你的项目的自包含性更好，降低了全局依赖带来的版本冲突。
** 过了两天发现，有人就这个问题全局问题发了篇文章: The Issue With Global Node Packages。