自2009年首次发布以来，Node.js一直是一项改变游戏规则的技术。概括来说，它允许开发人员使用JavaScript在服务端运行脚本，在页面发送到用户的Web浏览器之前生成动态Web内容。Node.js是“JavaScript无处不在”的潮流代表；在这种潮流推动下，服务端和客户端脚本不再需要使用不同的语言编写，开发Web应用只用一种编程语言就够了。

如果你像我一样也是JavaScript和Node.js的粉丝，你会很高兴看到它们正在迎来全方位的改进。

Node 12新特性与改进

“全方位改进”是什么意思呢？其实就在几个月前，Node.js 12版刚刚发布了。

2019年4月23日Node.js 12正式发布，全球各地的JavaScript爱好者都欢欣鼓舞。需要明确的是，这不只是一个普通的旧版本更新，而是一个有诸多重要内容更新的关键版本升级。具体升级内容如下。

V8 JavaScript引擎升级

每次的新版本JavaScript V8引擎都会带来一些性能调整和改进，此外这次还有一些非常值得注意的升级。具体有：

零成本异步堆栈跟踪——通过异步调用框架丰富error.stack属性，而无需为V8引擎添加额外的运行时。
参数不匹配的调用更快——以前V8必须用统一的方式处理参数过多或过少的函数调用，造成性能损失。现在引擎变得更聪明了，知道什么时候可以跳过这一步，从而将调用开销减少了60%。
更快的异步函数和Promise——实际上现在使用异步要比Promise快两个微拍（microtick），因为对Promise不熟悉的开发者可以使用语法风格更加同步的async/await。
更快的JavaScript解析——在网页启动时，解析JS的耗时只有引擎总耗时的10％不到。最新发布的JavaScript解析器在桌面端的解析速度提高了30％。

使用TLS 1.3提高安全性

TLS（传输层安全），是Node处理加密流通信的方法。

随着Node.js 12的发布，TLS也升级到了1.3版；虽然版本号只多了一点，但这次实际上是重大更新，加入了很多性能和安全性增强功能。听起来有些不可思议，但TLS 1.3实际上是比TLS 1.2更简单的协议，比后者更安全、更易配置，并且可以更快地在应用程序之间协商会话。

Node应用可以在TLS 1.3的帮助下更好地保护终端用户隐私，同时减少HTTPS握手所需的时间来提高请求性能。

小结：为所有用户提供更好的安全性并减少服务之间的通信延迟，我认为这是一大进步。

合理配置的默认堆大小

下面来谈一些底层改进。以前，JavaScript堆大小默认等于浏览器V8引擎设置的堆大小上限，前者可以手动调整。Node.js 12发布开始，JS堆大小将根据可用内存来自动配置，这样Node就不会尝试使用比可用内存更多的内存空间了，避免了耗尽内存导致进程被迫终止的问题。

新版在处理大量数据时不会再出现内存不足错误——以前经常会出现这种问题。需要的话，开发者还可以使用旧的–max-old-space-size标志手动设置上限，但新功能出现后手动设置大小的需求应该就没那么多了。

默认的http解析器变为llhttp

很多人（包括我自己）都不知道，Node中之前使用的http_parser库非常难以维护和改进，这就是llhttp诞生的原因。该项目是一个http_parser到TypeScript的端口，然后通过llparse运行以生成C或bitcode输出。

测试表明llhttp比http_parser快156％；前者的代码量更少，并且所有性能优化都是自动生成的——相比之下http_parser需要手动优化代码。

从Node.js 12开始，官方决定将默认解析器切换到llhttp，开始对其进行全面测试。我们希望它在用途各异的众多应用中都能维持出色的性能表现。

按需生成诊断报告

谈到调试的话题，Node.js 12引入了一个新的实验性功能，允许用户根据需要或在发生某些触发事件时生成报告。

这种实时报告可以帮助开发者诊断生产中的问题，包括崩溃、性能下降、内存泄漏、高CPU使用率、意外错误等等——这些都是通常需要数小时甚至数天才能调试、诊断和修复的东西。

集成堆转储

这个版本中关于堆的另一项特性是Node.js 12内置的集成堆转储，它可以加速调试过程。

现在开发者无需安装新模块来调查内存问题——只需通过命令行或API调用告诉Node你需要哪种JSON格式的诊断摘要，然后解析你能处理的所有信息即可。

Node.js中的原生模块更易使用

底层改进说完了。此外，对于Node生态系统中的开发人员和模块开发者来说也有一些改进值得一提。

新版进一步完善了为Node创建和构建原生模块的流程，包括更好地支持原生模块与worker线程的结合，N-API也升级到了第4版，让开发者可以更容易为原生异步函数配置自己的线程。

总的来说，这意味着Node专属模块的创建者和维护者可以像纯JavaScript模块的创建者一样轻松地维护这些模块。之前维护人员需要为模块支持的所有Node.js版本各做一份二进制文件，而新版N-API大大简化了这部分工作。

Worker线程即将到来——实验标志已被删除

虽然Node 10开始就引入了Worker线程，但到了12版中，启用Worker线程不再需要标志——实验阶段快要结束了。在Node.js 11.7.0之前，开发者需要在命令行中使用–experimental-worker标志启动node才能访问Worker线程模块。

$ node -e "require('worker_threads'); console.log('success');"
internal/modules/cjs/loader.js:605
    throw err;
    ^
Error: Cannot find module 'worker_threads'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:603:15)
    at Function.Module._load (internal/modules/cjs/loader.js:529:25)
    at Module.require (internal/modules/cjs/loader.js:657:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at [eval]:1:1
    at Script.runInThisContext (vm.js:123:20)
    at Object.runInThisContext (vm.js:312:38)
    at Object. ([eval]-wrapper:6:22)
    at Module._compile (internal/modules/cjs/loader.js:721:30)
    at evalScript (internal/bootstrap/node.js:720:27)
$
$ node --experimental-worker -e "require('worker_threads'); console.log('success');"
success
$

在执行CPU密集型JavaScript操作时Worker的表现非常出色；但它对I/O密集型任务没什么帮助，这种时候Node内置的异步I/O操作比Worker更高效。

启动时间的改进

Node.js 11引入了内置的代码缓存支持，将Worker线程的启动时间减少了近60％。

Node 12在此基础上更进一步，在构建时提前为内置库生成代码缓存，允许主线程使用代码缓存来处理用JavaScript编写的内置库的初始加载过程。

结果主线程的启动速度又提升了30％，你的应用为用户加载的速度也能变得更快了。

ES6模块支持，马上就要完成了

重头戏留到最后介绍。对我来说最令人兴奋的功能之一是ES6模块支持——这也是我们很多人一直在等待的东西。这个功能仍然是实验性的，Node团队正在收集测试反馈。这个功能意味着开发者只要动动手指就能够实现从前端到后端JavaScript的无缝过渡。

以下是最新版本的–experimental-modules的亮点所在：

ES2015 import语句可以将Javascript文件引用为相对链接./examples.js、绝对链接file:///opt.app/examples.js、包名称example-package或包中的路径example-package/lib/examples.js。

// relative urls
‘./examples.js’
 
// absolute URLs
‘file:///opt.app/examples.js’
 
// package names
‘example-package’
 
// paths within packages
example-package/lib/examples.js

.js文件中的导入和导出语法现在也都能用了。自ES6发布以来，开发人员终于可以像在传统JS中那样指定默认导出 import test from ‘./examples’、命名导出 import {example1, example2} from ‘./examples’ 和命名空间导出 import * as samples from ‘./examples’ 了。

// default imports / exports
import test from ‘./examples’
 
// named imports / exports
import {example1, example2} from ‘./examples’
 
// namespace exports
 import * as samples from ‘./examples’

将“type”: “module”添加到项目的package.json中，且Node.js将项目中的所有.js文件视为ES模块。这种方法允许Node将package.json用于包级元数据和配置，做法类似Babel等捆绑和配置工具。
使用.mjs结尾的文件会被显式视为模块，使用.cjs结尾的文件会被视为CommonJS。这些是仍然使用require和module.exports语法类型的文件。

现在这些功能不再需要标志就能使用，真是太棒了。

Node 12的新编译器和平台最低标准

最后要谈的是新版Node的运行需求变动。

Node.js 12通过内部改进和V8引擎的升级引入了许多新功能，最低运行需求也随之变化。对于macOS和Windows以外的平台而言，新版代码库现在至少需要GCC 6和glibc 2.17。使用这套新工具链编译的版本会包含编译时性能和安全性增强。

如果你使用的是Mac或Windows系统应该就没问题了：Windows系统版本需求没变，Mac用户至少需要Xcode 8和10.10“Yosemite”系统来运行新版Node。来自nodejs.org的Linux兼容版本将支持Enterprise Linux 7、Debian 8和Ubuntu 14.04，但可能需要在原生不支持GCC 6的系统上使用自定义工具链。我相信你会很快找出所需要的东西。

总结

Node.js的历史只有10年，现在还是单线程的，也没有像其他一些编程语言那样广泛应用，但Node拥有一些其他编程语言难以企及的优势：它是用JavaScript构建的，并且既可以在客户端也能在服务端运行。

致力于支持和改进Node的团队和企业是业界最优秀的。Node正在持续从核心JavaScript和其他语言中学习，挑选合适的部分并吸纳到自身当中，为开发人员和应用程序打造一个不断进步的平台。

Node.js 12带来了一些非常令人兴奋的改进，例如ES6模块支持、更好的应用程序安全性和更快的启动速度等。虽然直到2019年10月它才会进入LTS（长期支持）模式，但我还是要深入研究这些新功能，看看团队还能想到哪些内容来继续改进这个平台，使其成为更加出色的服务端解决方案。

英文原文：https://blog.logrocket.com/node-js-12/

创作场景

Node.js 12：服务端 JavaScript 的未来