#Windows下的多版本node安装
时间：2019-06-24 作者：鬼小妞 说明：在此教程中，你可以快速了解什么是node.js、nvm、npm以及如何正确在windows下安装多版本node.js。 备注： 本文仅供参考，描述不当的地方，请评论指正
[TOC]
Node.js官网
JavaScript、Node.js与V8的关系
请点击引用的原文JavaScript、Node.js与V8的关系 对于了解Node的开发人员，我们都知道Node是基于Chrome V8引擎开发的能使JavaScript在服务器端运行的运行时环境（runtime environment）。一方面，它提供了多种可调用的API，如读写文件、网络请求、系统信息等。另一方面，因为CPU执行的是机器码，它还负责将JavaScript代码解释成机器指令序列执行，这部分工作是由V8引擎完成。
一、node.js
Node.js 是一个基于 Chrome V8 引擎的 JavaScript 运行环境。Node.js 使用了一个事件驱动、非阻塞式 I/O 的模型，使其轻量又高效。Node.js 的包管理器 npm，是全球最大的开源库生态系统。
1.1 什么是node.js
它是一个Javascript运行时环境 依赖于Chrome V8引擎进行代码解释 轻量、可伸缩，适于实时数据交互应用
node.js是一个JS运行时环境（简单来说就是可以解析、执行js代码）：不是一门语言/库/框架。其实就是学Web服务器开发,node.js使用javasctipt进行编程，运行在JavaScript引擎上（ Chrome V8），不像其他语言，要运行在服务器端（apache,Naginx,iis tomcat)等其他http服务器上。它不用建设在任何服务器软件之上。Node.js的设计理念与经典的LAMP架构（LAMP=Linux + Apache+ Mysql+php）有着很大的不同，可以提供强大的伸缩能力。
- （1）Node.js中的JavaScript没有BOM、DOM，只有EcmaScript（基本语法），因为服务端不操作页面
- （2）在Node这个javascript执行环境中为js提供了一些服务器级别的操作API（文件读写、构建网络服务、网络通信、http服务器等）
1.2 node.js特性
- node.js特性（解决服务器高性能瓶颈问题）:
- 单线程
- 非阻塞I/O（简单来讲就是异步）
- 事件驱动
- 跨平台
首先，如果想了解清楚node.js的特性你可能需要先了解js中：同步&异步、线程&进程、事件循环、宏任务、微任务
单线程
在Java、PHP或者.net等服务器端语言中，会为每一个客户端连接创建一个新的线程。而每个线程需要耗费大约2MB内存。也就是说，理论上，一个8GB内存的服务器可以同时连接的最大用户数为4000个左右。要让Web应用程序支持更多的用户，就需要增加服务器的数量，而Web应用程序的硬件成本当然就上升了。
Node.js不为每个客户连接创建一个新的线程，而仅仅使用一个线程。当有用户连接了，就触发一个内部事件，通过非阻塞I/O、事件驱动机制，让Node.js程序宏观上也是并行的。使用Node.js，一个8GB内存的服务器，可以同时处理超过4万用户的连接。另外，单线程带来的好处，还有操作系统完全不再有线程创建、销毁的时间开销，单线程cpu的利用率永远是百分之百。坏处，就是一个用户造成了线程的崩溃，整个服务都崩溃了，其他人也崩溃了。
多线程、单线程的一个对比：
也就是说，单线程也能造成宏观上的“并发”。
单线程本身来说，存在如下几个弱点：
1、无法利用多核CPU 2、错误会引起整个应用退出，应用的健壮性需要考虑 3、大量计算占用CPU将使阻塞程序的运行 严格来说，Node并非真正的单线程架构，Node自身还有一定的I/O线程存在，这些I/O线程由底层libuv处理，这就意味着Node在访问系统I/O时还是多线程的，对于文件读取、SQL查询、网路请求这些具体操作，Node还是使用多线程来进行处理从而保证Node的处理效率。
为了应对单线程存在的CPU利用率问题，Node采用了多进程的架构，也就是著名的Master-Worker模式，又称主从模式，如下图所示，这种典型的用于并行处理业务的分布式架构具有较好的伸缩性和稳定性。Node通过fork()复制的进程都是一个个独立的进程，这个进程中有着独立的V8实例，每个独立进程需要至少30毫秒的启动时间和至少10MB的内存，虽然fork()进程是有一定开销的，但是可以提高多核CPU的利用率，这在CPU普遍多核化的今天还是有很大的作用的，同时我们也应该认识到Node通过事件驱动的方式在单线程上已经可以解决大并发的问题，启动多进程只是为充分利用CPU资源。
Node的Master-Worker多进程模式中主进程和工作进程通过消息传递的形式而不是共享或直接操作资源的方式进行通信，通过fork()创建工作进程之后会在主进程和工作进程之间创建IPC通道，关于多进程相关内容，Node官方提供了cluster模块对进程进行管理，相关内容可参考cluster。
关于应用的健壮性问题，我们同样可以采用上述的Master-Worker模式，主进程只负责管理工作进程，具体的业务处理交由工作进程来完成，在工作进程中监听uncaughtException事件可以捕获未知的异常，然后告知主进程，主进程根据策略重新创建工作进程，或者直接退出主进程，这种情况代码中一定要给出足够的日志信息，通过日志监控任务及时产生报警。
非阻塞I/O non-blocking I/O
例如，当在访问数据库取得数据的时候，需要一段时间。在传统的单线程处理机制中，在执行了访问数据库代码之后，整个线程都将暂停下来，等待数据库返回结果，才能执行后面的代码。也就是说，I/O阻塞了代码的执行，极大地降低了程序的执行效率。
由于Node.js中采用了非阻塞型I/O机制，因此在执行了访问数据库的代码之后，将立即转而执行其后面的代码，把数据库返回结果的处理代码放在回调函数中（事件队列），从而提高了程序的执行效率。
当某个I/O执行完毕时，将以事件的形式通知执行I/O操作的线程，线程执行这个事件的回调函数。为了处理异步I/O，线程必须有事件循环（even loop），不断的检查（事件队列里）有没有未处理的事件，依次予以处理。
阻塞模式下，一个线程只能处理一项任务，要想提高吞吐量必须通过多线程。而非阻塞模式下，一个线程永远在执行计算操作，这个单线程的CPU核心利用率永远是100%。所以，这是一种特别有哲理的解决方案：与其人多，但是好多人闲着；还不如一个人玩命，往死里干活儿。
事件驱动event-driven
在Node中，客户端请求建立连接，提交数据等行为，会触发相应的事件。在Node中，在一个时刻，只能执行一个事件回调函数，但是在执行一个事件回调函数的中途，可以转而处理其他事件（比如，又有新用户连接了），然后返回继续执行原事件的回调函数，这种处理机制，称为“事件环”机制。
Node.js底层是C++（V8也是C++写的）。底层代码中，近半数都用于事件队列、回调函数队列的构建。用事件驱动来完成服务器的任务调度，这是鬼才才能想到的。针尖上的舞蹈，用一个线程，担负起了处理非常多的任务的使命。
node.js特性之间的关系
单线程，单线程的好处，减少了内存开销，操作系统的内存换页。
如果某一个事情，进入了，但是被I/O阻塞了，所以这个线程就阻塞了。
非阻塞I/O， 不会傻等I/O语句结束，而会执行后面的语句。
非阻塞就能解决问题了么？比如执行着小红的业务，执行过程中，小刚的I/O回调完成了，此时怎么办？？
事件机制，事件环，不管是新用户的请求，还是老用户的I/O完成，都将以事件方式加入事件环，等待调度。
说是三个特点，实际上是一个特点，离开谁都不行，都玩儿不转了。 Node.js很像抠门的餐厅老板，只聘请1个服务员，服务很多人。结果，比很多服务员效率还高。 Node.js中所有的I/O都是异步的，回调函数，套回调函数。
跨平台
Node刚发布的时候，只能在Linux平台上运行，后来Node在架构层面进行了改动，在Node和操作系统之间引入了一层libuv，从而实现跨平台。 跨平台指的是PC端、移动端、Web/H5
1.3 使用Node.js的优缺点及解决方案
优点
Node.js的特性也就是它的优点，总结起来就是
高并发（最重要的优点） 适合I/O密集型应用
缺点
正是Node.js的特性，所以它也因此存在很多缺点
1、不适合CPU密集型应用；- CPU密集型应用给Node带来的挑战主要是：由于JavaScript单线程的原因，如果有长时间运行的计算（比如大循环），将会导致CPU时间片不能释放，使得后续I/O无法发起；
- 解决方案：分解大型运算任务为多个小任务，使得运算能够适时释放，不阻塞I/O调用的发起；
2、只支持单核CPU，不能充分利用CPU3、可靠性低，一旦代码某个环节崩溃，整个系统都崩溃- 原因：单进程，单线程
- 解决方案： （1）Nginx反向代理，负载均衡，开多个进程，绑定多个端口； （2）开多个进程监听同一个端口，使用cluster模块；
4、开源组件库质量参差不齐，更新快，向下不兼容5、Debug不方便，错误没有stack trace
1.4 适合Node的领域
- 互联网
- E-Commerce电子商务
- 支付处理
- 社交媒体
- 实时服务
- 媒体
- 企业Web服务
- ...更多请看下文node.js适用场景
1.5 Node.js适合用来开发什么样的应用程序呢？
node.js善于I/O不善于计算，因为node最擅长的就是任务调度，如果你的业务哟很多的CPU计算，实际上也就是相当于这个计算机阻塞了这个单线程，就不适合node开发
当应用程序需要处理大量并发的I/O（异步操作）、而在向客户端发出响应之前，应用程序内部并不需要进行非常复杂的处理的时候，node非常适合。node.js也非常适合与Web socker配合，开发长连接的实时交互应用程序。比如：
用户表单收藏 考试系统 聊天室 图文直播 提供json的API（为前台Angular使用）
如果你理解了js内存运行程序的事件队列，执行栈，异步这些特性与原理，你就可以轻松判断什么时候适合用node.js开发。对上面问题的回答，如果以执行栈和事件队列来分析的话，就是：
线程必须先处理完执行栈中的任务，才会把事件队列里队首的事件放到执行栈中，等这个任务完成后，再去事件队列里取队首的任务放到执行栈中，循环往复，直到事件队列事件为空。如果在发送一个异步请求的之前，执行栈有很多任务，事件队列就必须要排队一段时间，排队时间太长，就不适合用node来开发，而实际上，基本上大多数的项目，都会用到node.js。
1.6 适合Node.js的场景
好了，理解完node.js适合用来开发什么样的应用程序之后，我们来看看适合NodeJS的场景有哪些：
RESTful API
这是NodeJS最理想的应用场景，可以处理数万条连接，本身没有太多的逻辑，只需要请求API，组织数据进行返回即可。它本质上只是从某个数据库中查找一些值并将它们组成一个响应。由于响应是少量文本，入站请求也是少量的文本，因此流量不高，一台机器甚至也可以处理最繁忙的公司的API需求。
统一Web应用的UI层
目前MVC的架构，在某种意义上来说，Web开发有两个UI层，一个是在浏览器里面我们最终看到的，另一个在server端，负责生成和拼接页面。 不讨论这种架构是好是坏，但是有另外一种实践，面向服务的架构，更好的做前后端的依赖分离。如果所有的关键业务逻辑都封装成REST调用，就意味着在上层只需要考虑如何用这些REST接口构建具体的应用。那些后端程序员们根本不操心具体数据是如何从一个页面传递到另一个页面的，他们也不用管用户数据更新是通过Ajax异步获取的还是通过刷新页面。
大量Ajax请求的应用
例如个性化应用，每个用户看到的页面都不一样，缓存失效，需要在页面加载的时候发起Ajax请求，NodeJS能响应大量的并发请求。 总而言之，NodeJS适合运用在高并发、I/O密集、少量业务逻辑的场景。
Node.js的若干使用场景举例：
- 网站（如express/koa等）
- im即时聊天(socket.io)
- api（移动端，pc，h5）
- HTTP Proxy（淘宝、Qunar、腾讯、百度都有）
- 前端构建工具(grunt/gulp/bower/webpack/fis3…)
- 写操作系统（NodeOS）
- 跨平台打包工具（PC端的electron、nw.js，比如钉钉PC客户端、微信小程序IDE、微信客户端，移动的cordova，即老的Phonegap，还有更加有名的一站式开发框架ionicframework）
- 命令行工具（比如cordova、shell.js）
- 反向代理（比如anyproxy，node-http-proxy）
- 编辑器Atom、VSCode等
可以说目前大家能够看到的、用到的软件都有Node.js身影，当下最流行的软件写法也大都是基于Node.js的，比如PC客户端luin/medis采用electron打包，写法采用React+Redux。在未来，Node.js的应用场景会更加的广泛。更多参见github.com/sindresorhu…。
1.7 不适合Node.js的场景
1.计算密集型应用 2.单用户多任务的程序 3.逻辑十分复杂的事务 4.unicode与国际化
二、为什么要安装多版本Node.js
首先，在回答这个问题之前，建议先看一下Node.js的发展历史，不过，现在你已经不需要考虑这个多版本版本安装了，也不需要思考，开发使用io.js还是node.js。因为现在io.js和node.js合并了，详情查看和解方案Reconciliation Proposal。不过，我们还是要明白在合并之前为什么需要考虑安装多版本node.js。
在io.js和node.js合并之前，我们 通常使用：
- 社区版——io.js
- 官网版——node.js
两者都是基于V8引擎开发的
2.1 io.js
io.js（JavaScript I/O）是兼容 NPM 平台的 Node.js 新分支，由 Node.js 的核心开发者在 Node.js 的基础上，引入更多的 ES6 特性，它的目的是提供更快的和可预测的发布周期。
2.1.1 io.js目标
- 持续集成
- 100% 测试通过作为正常状态
- 严格的 SemVer-compliant 版本
- 提交者版权所有，脱离公司控制
- 透明的追求共识的管制。
- 每周发布
- 支持V8版本
- 活跃的开发
- 可预期的路径
- 社区结盟 由于io.js和node.js已经合并了，所以io.js也已经叫node.js。所以io.js和node.js 两者的官网是一样的。
2.2 安装多版本的原因
-
1.在io.js和node.js合并之前，安装多版本Node.js，其实就是安装io.js和node.js。因为io.js有很多新特性，而node.js是属于稳定性的版本，很多新特性node.js是不支持。社区版的版本更新非常快有很多新特性，但是很多项目的环境不支持这些新特性，所有有时需要在io.js和node.js之间切换，就需要安装io.js和node.js。
-
2.现在，我们只需要考虑安装的版本是奇数版本还是偶数版本，是LTS版本还是Current版本 一般来说，我们安装官网推荐的两个版本：LTS版本和Current版本
而LTS代表了一个被不断修正与改进的版本，包含Node.js平台的最新特性。有时候我们的项目中需要到的环境不支持node的新特性，那么就需要切换到LTS版，如果同时，你又想要研究新特性，那么就需要current版本。
三、理解Node.js的版本发布
Node.js 的发布是 以时间的流逝为准，在保证兼容性靠拢的前提下跳版本 ，而不是以兼容性和新特性的多少为准，这也解释了为什么 Node.js 的版本看上去跳得那么快
越来越多开发人员选择Node.js作为开发平台。但是由于Node.js版本众多，对于新手选择什么版本，如何选择成为一个问题。本文初略介绍一下Node.js的版本发布规律，作为新手选择版本的参考。注意，本文的介绍的内容只是辅助解决选择版本的首先需要面对的一个问题，而不是全部的
3.1 Node.js的发布流程
你可以去官网上的关于版本发布的信息，为了方便了解以下是我今日（2019-6-24）在官网上的版本发布概览信息图：
注意以下说明是当前流程，在Node.js过去的演进过程中可能存在不同的方法或有例外情况。关于Node.js的发布流程，有以下要点：
- 每6个月发布一个主要版本(即Major号变更)，作为Current版本
- 发布月份:
4月发布偶数版本，10月发布奇数版本- 每12个月将一个版本转入LTS版本。对，只有偶数版本（一般是在其后续奇数版本发布时）
- LTS版本要经历两个阶段：活跃期（Active）与维护期（Maintenance)
活跃期(Active)共18个月，主要在不改变兼容性的情况下，周期性修改自身Bug与合并其他版本的重要修改维护期（Maintenance)共12个月，只负责修改本版本的Bug以及特别紧急的如安全性问题或者文档更新。
3.2 Node.js官网的下载
当用户访问Node.js官网时，会遇到的最主要下载页面，如下：
或者：
可以看到主要是两个版本推荐下载：10.16.0与12.4.0， 根据Semver版本规定版本首数字10或12代表Major（主）版本号。
3.3 LTS和Current的区别
- LTS——长期支持（Long Term Support）
- Current——当前的 你可以这么理解：LTS版本为
相对稳定版， Current版本为测试版
Current就代表最新发布的版本（每6个月一次的），它可能是奇数版本也可能是偶数版本。因为其是最新的，所以包含Node.js平台的最新特性。
而LTS代表了一个被不断修正与改进的版本。
每个时刻Current版本只有一个，LTS版本可能有3个，LTS-Active版本可能有2个.
在Node.js官网中给出的LTS版本总是处于LTS的最新版本（目前是10.16.0）， 根据发布计划，该版本处于活跃期(Ative)我们可以看到其MINOR版本在不断升级过程中。
3.4 LTS （Long Term Support）
3.4.1 Node.js LTS 计划
Node.js core 在 Node.js 与 io.js 合并后，为了保证发布稳定有序，让开发者能够合理安排升级，开始使用 LTS（Long Term Support）来规划发布周期。 第一个 LTS 版本是 v4，发布于 2015 年 10 月。在这个规划下，Node.js 的版本相当于 master 分支在特定时间下经过稳定化处理的快照，时间到了就将 master 分支上稳定的部分整合起来，发布新的版本，因此 Node.js 的发布是 以时间的流逝为准，在保证兼容性靠拢的前提下跳版本 ，而不是以兼容性和新特性的多少为准，这也解释了为什么 Node.js 的版本看上去跳得那么快（不是“啊，我们攒了这么多大招，可以发新版了！”而是“啊，四月到了该发版了，我们把攒过的大招过一遍，看有什么够稳定能加进去的，虽然可能这些招不怎么大就是了……”）。
值得一提的是，目前的常青浏览器/主流 JavaScript 引擎/ECMAScript 标准/C++ 标准也是采用类似的原则，以时间跨度为基准，从主干上截取稳定特性来进行发布的。
每一个 LTS 都会有一个代号，从元素周期表取元素名，按照字母表排序，挑选出合适的。
- v4 的代号是 Argon(氩)
- v6 的代号是 Boron（硼）
- v8 的代号是 Carbon ( 碳 )
- v10 的代号是 Dubnium（钅杜）
Node.js 的版本命名规则遵循 semver语义化版本（Semantic Versioning），版本号分为三部分，后面有详细介绍semver,请查看本文3.5章节。
- 第一个数字（semver-major）增加，表示有不兼容的改变；
- 第二个数字（semver-minor）增加，表示有保持兼容的新特性；
- 第三个数字（semver-patch）增加，表示有在保持兼容性与特性不变的前提下的改动，比如修复了 bug 或者改进了文档。
这个命名规则有利也有弊，此处不赘述，但它的一些矛盾之处使得 Node.js 的命名有一些例外，比如安全更新即使会导致不兼容，为了能够更新到所有 major 版本，也依然是 semver-minor，去semver官网 查看详细的semver介绍https://semver.org/lang/zh-CN/ ，
3.4.2 一个 LTS 的一生
具体请到node.js的Release发布git分支上了解更多LTS相关信息https://github.com/nodejs/Release
current(1.4~1.10)
-
LTS
current: 第一年的四月到十月- 目前 Node.js 会在每年四月从 master 截取分支出来，收集足够稳定的特性，发布一个 major 的偶数版本（比如 v6.0.0），作为下一个 LTS 的备选。在当年四月到十月这段 6 个月的期间，这个偶数版本称作“current”（比如 v6.0.0 "current"）。在接受社区反馈后，这个版本会修复 bug，增加新特性，不断改善，还可能删掉一些兼容性影响太大的改进，此时这个版本的 minor 版本会不断增加。开发者可以利用这段时间，用这个候选 LTS 版本在线下测试自己的应用，并将兼容性问题与 bug 反馈给 Node.js 的开发者。
active(1.10~3.4)
-
LTS
active: 第一年的十月到第三年的四月- 到了当年十月，这个偶数版本就会成为 LTS（比如 v6.9.0 "LTS"），此时它也被称为 "active LTS"。在此后 18 个月的 active 期间，这个版本几乎不会再有任何不兼容的变更，除了安全相关的 OpenSSL 以外其他的依赖（比如 v8）也不会进行大的更新。这段时间内开发者可以将线上的 Node.js 升级到这个稳定的 LTS 版本，并使用 Node.js 的新特性进行迭代。
maintenance(3.4~4.4)
-
LTS
maintenance: 第三年的四月到第四年的四月- 经过 18 个月的 active 时期后，在第三年的四月，这个版本将会迎来最后 12 个月的 maintenance 时期，这个时候它的更新只有安全更新和 bug 修复。由于 Node.js 每年十月出一个 LTS，因此在这个版本 active 时期的 2/3 的节点，就会有一个新的 active LTS 诞生（目前就处于 v4 LTS 还剩下 6 个月的 active 时，v6 LTS active 发布的时间点）。等到它的 active 时期结束时，开发者已经有 6 个月的时间过渡到下一个 active LTS。即使开发者更新的进度比较慢，也还有 12 个月的 maintenance 时间，抓紧进行升级。12 个月后，这个 LTS 将会结束它的寿命，不再迎来任何更新。因此，每个偶数版本，都会有 3 年的寿命。
3.4.3 这LTS跟 Node.js 的源代码是怎么对应的？
首先，Node.js 的 Github Repo 有一个 master 分支，大部分的 commit 是通过 PR 提交到这个分支上的。根据这些 commit 是否改变了兼容性或者引入了新特性，它们会被打上 semver-major 或者 semver-minor 的标签。
在每年四月前需要准备 LTS 的时候，Node.js 会从 master 分支截取一个新的分支出来，假如这个是 v6，那么这个分支就叫 v6.x-staging 。之后与这个 LTS 相关的修改／打算进入这个 LTS 的修改，比如 bug 修复等，还是提交 PR 到 master ，但需要加一个 tag lts-watch-v6.x 。被合并到 master 之后，这些变动会被负责发布的人挑出来，合并到 v6.x-staging 。
当到了四月的某一天，v6 的第一个版本可以发布的时候，负责发布的人会创建一个 v6.x 分支，从 v6.x-staging 再挑出变更合并进来。从四月到十月，对 v6 的所有修改，无论是 minor 或者 patch，依然先提交 PR 到 master ，然后再被挑出来合到 v6.x-staging ，发版本时再进入 v6.x 。这样，master 总是保留着最新的变动。而其他版本相关的分支，都是从 master 上挑出适合发版本的 commit，混合出来的缩影， v6.x-staging 保留着 v6.x LTS 相关的修改， v6.x 保留每一次 v6 发布的版本。除了负责处理分支的人以外，其他开发者是不会动这些版本相关的分支的。
3.5 Semver
什么是Semver
去semver官网 查看详细的semver介绍https://semver.org/lang/zh-CN/
Sem+ver, Sem是Semantic（语义的）之意，ver是Version（版本）之意。 Semver整体表示一种版本命名的方式，要体现一定的版本变更内容的含义。 目前的Semver一般指由Semver.org组织制定的版本规范。其基本要求如下：版本号的基本形式为MAJOR.MINOR.PATCH，即3部分组成，增加每个部分的值的含义分别如下：
- MAJOR： 软件的API改变
- MINOR： 修改或添加功能，但保持向后兼容（API未变）
- PATCH：补丁，主要是错误修复
四、开发者如何选择node.js版本
- 如果需要尝试最新的ES规范建议采用latest版本
- 如果是项目使用，保持稳定 建议采用长期版本
一般来说，我们安装官网推荐的两个版本：LTS版本和Current版本
4.1 追求稳定性的——LTS
对于追求稳定性的 Node.js 应用开发者来说，只需要每年十月一个版本成为 active LTS 的时候线上跟进升级即可，也就是每 12 个月升一次 major 版本，每次升级的版本还有 18 个月 + 12 个月的寿命，中间跟进 minor 和 patch 的时候不用太担心兼容问题。
目前的推荐是最好在一个 active LTS 出来的 12 个月内完成线上的升级（因为 12 个月后会出下一个 active LTS）。进度落后的话，妥协到 18 个月，这个 LTS 的 active 时期结束前也可以。再赶不上，起码要在 30 个月内这个版本结束寿命之前升级完，否则连安全更新也没有了。
担心直接升级遇到的兼容问题较多的话，则可以在每年四月偶数版本新出来的时候，提前在线下进行测试和升级准备，将问题反馈到社区（当然如果没空也不需要管这一步），并不断跟进，十月再升线上版本。这样线上下都是 12 个月升一次 major，只不过时间点不同。虽然线下需要跟进的兼容性问题多了一些，但同时也可以通过反馈让自己的兼容性需求被社区照顾到。
4.2 热衷于尝试新特性——current
热衷于尝试新特性，或者不在生产环境使用的实验性项目，则可以尝试每年十月发布的奇数 major 版本。每个奇数版本只会维护 8 个月，而且不会有 LTS 那样的兼容性保证，但Node.js 的开发者会利用这个版本为下一个 LTS 做准备，因此它会有更多大胆的尝试，比如更频繁的 v8 更新（意味着更多的 ECMAScript 新特性实现以及性能优化）。
因此，现在还在线上使用 v4.x 的开发者，已经可以准备升级到 v6.x 了。如果你的线上应用还在使用 LTS 计划启用前发布的版本，如 v0.12.x，也最好抓紧升级到 v4.x 或者以上，因为 2016 年 12 月之后 v0.12.x 将不会再有任何安全更新，更早的版本就更没有了，主要是 OpenSSL 的漏洞将不会被修复，这些应用将会暴露在各种安全风险之下。一旦升级到 v4.x 或更高，今后的升级将会相对容易许多，平时只要记得跟进 minor 或者 patch 即可，或者懒一点的只需要关注安全更新。
