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 版本的完整功能列表。