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