Node.js 14 正式发布：V8 引擎升级，新增异步本地存储 API

Node.js 14 版本于近日正式发布， 此版本包含的亮点如下：

• 对诊断功能的改进

• 升级 v8 引擎

• 新增实验性的异步本地存储 API

• 强化流 API

• 移除实验性模块中的警告

• 移除一部分早期版本中废弃的 API

本文最初发布于 Medium的Nodejs 专栏，经原作者授权由 InfoQ 中文站翻译并分享

Node.js 14 取代 Node.js 13 成为了我们的当前（current）版本。根据发布时间表，Node.js 14 将是未来 6 个月的当前版本，然后在 2020 年 10 月升级为稳定版本(LTS)。 像往常一样，企业用户应该等到 10 月份 Node.js 升级为 LTS 之后，再升级其生产环境中的 Node.js 版本。 不过，现在是使用 Node.js 14 测试应用和尝试新功能的最佳时机。

提醒一下，Node.js 12 和 Node.js 10 的稳定版本将分别持续维护到 2022 年 4 月和 2021 年 4 月（点击查看更多LTS策略）。

点击https://nodejs.org/en/download/current/下载新版本，马上开始学习吧！

在我们开始深入介绍新版本的功能之前，需要提醒一点，那就是新版本中添加的功能会很快被添加到当前稳定版本中去，这就意味着我们在不升级主版本的情况下，也可以在当前稳定版本的小版本更新中使用这些新功能。因此借这个机会我们向大家重点介绍下 Node.js 14 版本中的一些内容，即使这些内容中可能有些部分已经在之前的版本中存在了。

诊断报告变成稳定功能

在 Node.js 14 中诊断报告将是一个稳定的功能（在 Node.js 12 中是试验性的功能）。在推进和建立可用、易用的 Node.js 诊断功能的工作进程中，这是非常重要的一步。其中大部分工作是由 Node.js 诊断工作组推进的。

诊断报告功能使你在生成报告的时候，既可以根据需要生成，也可以通过事件触发生成。对诊断报告的信息分析可以帮助你诊断各种生产环境问题，包括崩溃、性能慢、内存泄露、CPU 使用率高、未捕获的异常等。点击链接可以了解到更多关于诊断报告功能的信息。作为一个稳定的特性，启用诊断报告所需的命令行选项将减少一个，并且用户在生产环境中可以很容易启用它。

V8 升级到 V8 8.1

与往常一样，新版本的 V8 JavaScript 引擎带来了性能调整和改进，同时也使 Node.js 保持了在语言和运行时方面持续改进的一致性。V8 的升级还给我们带来了一个好玩的命名，V8 的版本 8(“ V8 的 V8”)。

新的 JavaScript 功能主要包括：

• 可选链——MDN
  

• Nullish 合并——MDN
  

• Intl.DisplayNames ——MDN
  

• 为 Intl.DateTimeFormat 启用 calendar 和 numberingSystem 选项——MDN
  

了解 V8 中新功能的更多信息，请查看 Node.js V8 博客：https://v8.dev/blog。

实验性异步本地存储 API

该项目一直在致力于帮助管理多个版本之间异步调用上下文的 API。实验性Async Hooks API 已在早期的版本中引入了。Async Hook 的关键用例之一是异步本地存储（也称为连续本地存储）。已经有许多 npm 模块提供了 API 来满足这种需求，但是这些年来，在 Node.js 核心之外维护这些功能一直很棘手；并且在这个项目上社区已经达成共识，认为由 Node.js 提供统一的 API 会更合理，因此 14.x 版本带来了实验性的Async Local storage API（也在 13.10 中添加了该 API）。我们正在寻求社区来尝试这个 API，并向我们反馈有关抽象模型、API 接口、用例覆盖范围、功能稳定性、命名、文档等方面的信息，这样我们就可以在以后的版本中将其变成稳定功能。给我们提供反馈的最佳方法是在诊断仓库的问题区）创建一个问题，并命名为“AsyncLocalStorage API 的经验报告”。

流

在 Node.js 的流实现中，此版本中提供了一些标记为 SemVer major（译者注：SemVer major 表示的是大版本号不兼容）的更改。这些更改旨在提高 Streams API 的一致性，以消除歧义并简化 Node.js 核心各个部分的行为。例如，http.OutgoingMessage 与 stream.Writable 类似，而 net.Socket 的行为和 stream.Duplex 完全一样。一个显著的变化是 autoDestroy 选项现在默认设置为 true，使流在结束后始终调用_destroy。尽管我们认为这些 SemVer major 更改对大多数程序不会有影响，因为它们只更改了一些边缘的场景，但如果你严重依赖 Stream，最好在 Node.js 14 还是当前版本时进行测试，以便为未来的发布做好准备。 Node.js 14 将会在 2020 年 10 月成为 LTS。

实验性 Web Assembly 系统接口

用 Web Assembly 编写的 Node.js 包为某些使用场景带来了更好的性能和跨平台支持的机会。 为了支持这些场景，14.x 版本中包含了 Web Assembly 系统接口（WASI）的实验性实现。虽然 WASI 对 Node.js v14 来说并不是新事物，但值得注意的是它在简化原生模块的体验上非常有潜力。你可以在 API 文档中了解有关它的更多信息：https://nodejs.org/api/wasi.html。

移除实验模块警告

其实在 Node.js 13 中，我们就已经移除了实验模块警告，不再需要使用 -experimental-modules 标志来处理，但是如果在 Node.js 中使用EcmaScript Modules功能，Node.js 13 中仍然会发出实验功能警告：ESM 模块导入属于试验性功能。

从 Node.js 14 开始，在 Node.js 中使用 ESM 时不再会出现此警告。虽然 Node.js 中的 ESM 实现仍处于试验阶段。根据我们的稳定性指数：“该功能不受语义版本控制规则的约束。向后兼容的更改或删除可能会在将来的任何版本中发生。”在生产环境中用户应谨慎使用该功能。

请记住，Node.js 中 ESM 的实现和你所熟悉的并不一样。大多数转译工作流都支持的一些功能是 Node.js ESM 实现不支持的，例如：可选的文件扩展名或者 JSON 模块。来自转译环境的模块很可能需要一定程度的重构才能在 Node.js 中使用。值得一提的是，我们的许多设计决策都是基于两个主要目标做出的，即规范合规性和 Web 兼容性。我们相信，当前的实现为编写 ESM 模块提供了一个可以长期使用的模型，为走向通用 JavaScript 的目标铺平了道路。请在文档中阅读更多内容。

虽然当前 Node.js 中的 ESM 实现仍处于试验阶段，但我们相信，推进 Node.js 中 ESM 功能到“稳定”状态是近在咫尺的。消除警告是朝这个方向迈出的重要一步。

新的编译器和平台最低要求

Node.js 为很多平台提供了预构建二进制文件。针对每个主版本，都会对最小工具链做适当的评估和提高。

为了支持包认证功能，我们在这次发布时将所有 macOS 的二进制文件转到了 macOS 10.15（Catalina）下用 Xcode 11 编译了。由于二进制文件仍在编译中，以达到支持相应编译目标的发行要求，我们预计不会对较老版本的 macOS 的 Node.js 用户产生负面影响。针对 Node.js 14，我们将最低的 macOS 支持版本提高到了 macOS 10.13（High Sierra）。

在基于 Linux 的平台上，对于 Node.js 14，最低 GCC 版本仍为 GCC 6，但是我们计划为某些使用 GCC 8 的平台构建并发布二进制文件。

针对停止维护的 Windows 系统版本，Node.js 14 将不会为其发布版本。

有关更多详细信息，请参见 Node.js BUILDING.md。

行动呼吁

在进入 “current” 阶段的 6 个月中，Node.js 14 将接受大量贡献到 Node.js 中的新特性，因此在接下来的 6 个月中，此发行版本非常适合进行功能尝试、项目测试以及升级 Node.js 到最新版本的兼容性测试，同时，请给我们提供反馈，帮助该发行版在 10 月顺利过渡到 LTS。

感谢！

我们想借此机会对所有促成此版本发布的贡献者和 Node.js 合作者表示非常感谢。我们还要感谢 Node.js 构建工作组 确保我们拥有创建和测试发行版的基础架构，并对 Node.js 14 的工具链进行必要的升级。

你可以点击这里查看 v14.0.0 版本的完整功能列表。

本博客由 Michael Dawson 和 Bethany Griggs 撰写，同时 Node.js 社区委员会和 Node.js 技术指导委员会也对内容做了贡献。

原文链接：

Node.js version 14 available now