Node 12 值得关注的新特性

前言

时隔一年，Node.js 12 如约而至，正式发布第一个 Current 版本。

该版本带来了诸如：

V8 更新带来好多不错的特性。
HTTP 解析速度提升。
启动速度大幅提升。
更好的诊断报告和堆分析工具。
ESM 模块更新。

原文地址：https://medium.com/@nodejs/introducing-node-js-12-76c41a1b3f3f 语雀地址：https://www.yuque.com/egg/nodejs/nodejs-12

LTS vs Current

如果你不了解 Node.js 的 Long Term Support 发布策略的话，一定要看看 https://github.com/nodejs/Release 。

就目前而言，Node.js 6.x 和 8.x 将在 2019 年末结束 LTS 的支持，大家尽快升级到 10.x 吧。

快速体验

$ nvs add node/12
$ nvs use 12
$ node -v
v12.0.0

具体参考这篇文章：科普文：使用 nvs 管理本地 Node.js 版本

V8 更新到 7.4

大部分情况下，我们不用去考虑性能问题，坐等 V8 版本更新就好了。（大雾）

本次版本更新，也带来了好几个不错的特性：

同时，跑了下我们 Egg 的一些内部测试，发现序列化有 10~20% 的性能提升，恐怖如斯！

另，奇丑无比的 Private Class Fields 也能用了：

class IncreasingCounter {
  #count = 0;
  
  get value() {
    console.log('Getting the current value!');
    return this.#count;
  }
  increment() {
    this.#count++;
  }
}

HTTP 解析速度提升

默认的 HTTP 解析器切换为 llhttp ，性能提升恐怖如斯：

点评：恐怖如斯。

启动速度提升

通过 v8 code cache 的支持，在构建时提前为内置库生成代码缓存，从而提升 30% 的启动耗时。同时，通过重用主进程缓存，Workers Threads 的启动速度提升了 60% 。

点评：恐怖如斯。

Workers Threads

在 10.x 已经引入的 Workers Threads 特性，在 12.x 里面默认启用，无需使用 --experimental-worker 开启。同时基于上一条的介绍，启动的速度也得到大幅提升。

诊断报告

提供了新的实验性功能『诊断报告』，一个非常有用的特性。可用于帮助分析诸如：崩溃，性能问题，内存泄漏，高 CPU 占用等等问题。详见这篇文章。

点评：这也是 AliNode 之前的一个卖点之一。

Heap Dump

以前我们分析问题的时候，需要手动安装对应的类库或者使用 AliNode。

在 12.x 里面内置了该功能，详见：

点评：又一个 AliNode 的功能被内置了。但其实影响不大，AliNode 的核心在于分析平台，这块的采集能力，本来他们就打算开源回馈出去的。

同时，由于上述提到的 V8 升级，现在可以按照可用内存动态调整堆大小了。

ESM 模块方案更新

ES6 模块仍然还在实验阶段，不过有了新的方式，具体参见这篇文章。

点评：让子弹再飞一会，该特性真的不是痛点，不急。

其他更新

更好的原生模块支持，N-API 升级为版本 4，并 backport 到 Node.js 8.x 和 10.x。详细参见这篇文章。
TLS 升级为 1.3，增强安全功能。
随着 C++ 编译器的更新，现在要求 GCC 6 和 glibc 2.17 ，对应的操作系统 Win7 和 macOS 10，详细参见这篇文章。

不过目前 node-gyp 的一些原生模块会编译失败：

[email protected] › [email protected] › fsevents@^1.2.7 optional error: Error: Run "sh -c node install" error, exit code 1
    at ChildProcess.<anonymous> (/Users/tz/.npm-global/lib/node_modules/tnpm/node_modules/[email protected]@runscript/index.js:74:21)
    at ChildProcess.emit (events.js:196:13)
    at maybeClose (internal/child_process.js:1000:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:267:5)