从Node EOL 到Node LTS 以及其间的所有版本

嘿，马可、马特奥，能请到你们来，我真是太高兴了。

你好。太棒了。

在请大家自我介绍之前，我先简单介绍一下我自己。我和大家之间有一层Node.js的联系。我想我们三个人都在使用Node.js的爱尔兰公司工作。这是一个有趣的小插曲。

首先，我叫哈维尔·佩雷斯。我是 HeroDevs 的一名技术产品管理负责人。我负责 JavaScript 生态系统中的二十五项以上技术，以及 JavaScript 生态系统之外的几项技术，当然还包括Node.js。

我刚才提到，我与马特奥和马可的渊源是这样的——嗯，现在回想起来好像是很多年前的事了，大概十二年前——我当时在一家叫FeedHenry的公司工作，那是一家位于爱尔兰沃特福德的爱尔兰公司。早在2012年，Node.Node还处于0.7版，我记得后来是0.10版，我们就在那时开始使用Node了。我还记得0.10版，然后是0.12版。我们经历了所有这些版本。 关于分支、合并等历史细节，我们就不必赘述了。这些都有详细记录。

但那正是我与Node.js 紧密合作的时候。当时我们正在开发 RSS 技术和连接云服务的移动应用——这涉及高强度 I/O 操作，在当时还是一项非常新颖的技术，但我们深知这就是我们必须采用的技术。我认为我们的选择是正确的。我们的首席技术官和工程团队也没有错。

我只想说，能和大家在一起，看到你们Node 使用Node 我感到非常兴奋和高兴。Node 发生了许多变化。每隔六个月，情况就会发生变化，对吧？有时变化还相当显著。所以，能聊聊这些真是令人兴奋。那么，马特奥，我们先从你开始吧？你能简单介绍一下自己吗？跟我们说说你与Node、OpenJS 和 TSC 的故事。

当然。是啊，当然，当然。

好吧，我大概是在2010年左右开始Node。2011年，我开始攻读博士学位。在那之前，我一直在用Ruby和Java开发，当时我想找一种既能像Java一样快，又能像Ruby一样容易开发的语言。Ruby在开发阶段非常快，但在运行时却很慢——至少当时是这样。我觉得现在可能还是这样。

然后我看到了这段视频……当时我就觉得，这就是我要找的技术。但说实话，那并不是那个转折点。 真正的转折点，是在我真正理解了 NPM 以及 NPM 正式发布之时——这并非一蹴而就，而是发生在稍后的某个时刻。当我意识到这一点时——回过头来和 HeroDevs 的各位讨论这个话题——我意识到 NPM 实际上将解决如何大规模复用软件的问题，而这在 NPM 出现之前，对 Java 世界乃至 Ruby 世界来说都是一个巨大的难题。 在NPM出现之前，没人能解决这个问题。这就是NPM的核心创新，其结果便是造就了全球最大的软件仓库——里面既有优质资源，也充斥着恶意软件，而恶意软件正是最大的攻击目标。所以它成了最诱人的目标，诸如此类。

作为曾遭国家行为体攻击以获取我电脑访问权限的受害者之一——这方面我确实运气不佳。但这段经历很棒。所以Node 开始使用Node 还在“left-pad”漏洞出现数月前就预见到了它，而且我一直在技术前线奋战了很长时间。

其实我们之间有一段小渊源。2013年、2014年，我供职于一家名为NearForm的小公司，当时我们的办公室就紧挨着FeedHenry——真的是隔壁。所以我们之间确实有这段小渊源。这些年来，有几位同事从FeedHenry跳槽到NearForm，也有人反向跳槽。这段历程相当有趣。 那段时光我们大概都在爱尔兰，办公室就在隔壁。那真是段快乐的岁月。

那场风波之后，我开始为Node.js 做出贡献。IOJS 的分裂影响巨大，随后基金会成立了。当时Node 里有很多我想修复Node 无能为力的问题，直到基金会成立后，我才开始着手解决这些问题。 起初我只是为Node 做些微小的贡献，几年后，我成为了 CTC 的成员，后来 CTC 并入了 TSC。之后，我不知怎么的，好像是抽到了短签，被选为Node.js TSC 的主席。

我们再多聊聊TSC吧。光是聊你做过的事情，马泰奥，我们就能聊上好几个小时。那皮诺和Fastify呢？

据我所知，过去一年里，我在该生态系统中维护的所有模块的下载量已达420亿次。

太疯狂了。难以置信。

而且Fastify，顾名思义，就是最快的框架，对吧？

是啊。也许吧。

马可，请跟我们聊聊你自己。你是怎么接触到Node TSC 的？

是啊，我绝对算不上早期采用者。Node 我才开始对Node 产生兴趣。在那之前，我一直在做 Java 开发，当时我就总觉得，不想写那么多冗余的代码——那太无聊了。而当时Node.js 是最前沿的技术，依然处于行业前沿。

好久不见，我是在几年前加入 NearForm 时开始贡献代码的。我记得我是马泰奥离开后的那周加入的，所以这纯属巧合。之后，我开始更多地参与 JavaScript 生态系统的安全工作，并对当时各种流行的攻击手段产生了兴趣。

太棒了。对了，马可才二十二岁左右吧？你还很年轻呢，马可。

不，我二十八岁。

二十八岁。好的。这还很年轻。

好的。我想谈谈近期围绕Node.js 发生的一切。在此之前——这也是我们与 OpenJS 共同举办此次活动的原因之一——我们与 OpenJS 已经合作了几年。事实上，我们正是两年前开始参与他们的生态系统可持续性计划的。如您所知，HeroDevs 负责维护那些已达到生命周期终点的软件。 而 OpenJS 的立场非常明确：我们希望看到越来越多的创新和贡献，但同时也致力于保障安全与生态系统的可持续性。

我们深有体会——关于大规模部署的组织在升级或从一个版本迁移到另一个版本时有时会面临多大的困难，我们甚至可以就此畅谈数小时。毕竟存在破坏性变更等风险。但就在不久前Node 已正式达到生命周期终止（EOL）。就在四月底，也就是不到一个月前的 4 月 30 日Node ——这个曾被广泛使用且意义重大的版本——迎来了生命周期终止。 这意味着维护终止、更新停止，包括次要版本发布和补丁更新。

不好意思打断Node 被下载了多少次吗？

我现在不打算去 npm，但你告诉我。

九千五百万次。

只是说说而已。

我只想在这里提一下，大多数人在应用程序中部署Node.js 时——尤其是某些部署场景下——之后就再也没有进行过升级。 随着 Node.Node 的普及，我们发现许多公司和团队根本不进行更新。对他们来说，更新Node 非常棘手的大事Node 因为通常他们的依赖树已经严重滞后，需要进行大规模的重构和重组才能更新整个依赖树。因此，他们无法分阶段进行更新，而是必须采取“大爆炸式”的发布方式。

不过确实Node 的下载量一直徘徊在九千万大关附近。说实话Node.js 下载量最高的月份是在去年六七月间，当时大约有1.25亿次下载。Matteo 那里有很多有价值的数据。我看过你的一些图表——真的很棒。

是的，我的图表都在另一块屏幕上，所以我的数据是准确的。

马可，你给我看了一张包含所有Node 版本的截图——其中大部分版本的发布工作都是由你亲自负责的。跟我们说说那段经历吧。感觉如何？

我估计，在Node 转为 LTS 版本时，大约 70% 的发布工作是由我和其他志愿者完成的。

发布Node 大量努力，也需要极大的耐心，因为总会出现各种问题，而且还得与许多人沟通，并在遇到不熟悉的部分时寻求帮助。这确实是一项艰巨的工作。 我很高兴 HeroDevs 能赞助我在Node 方面的开源工作，因为可持续性面临的一个难题，就是如何为志愿者提供资金支持，让他们来完成这类繁琐且有时枯燥的工作。我想，这也是我们调整发布计划的主要原因之一。

我们来聊聊这个吧。Node 的一大新闻就是发布计划的调整。Marco，你想先谈谈这个吗？做出这个决定是基于哪些考虑？

首先，对于还不了解情况的朋友——我们每六个月发布一次新版本。奇数版本不是长期支持（LTS）版本，偶数版本才是长期支持版本：比如18、20、22等。但现在这一情况将发生变化，改为每年发布一次，且所有偶数版本都将作为长期支持版本。

还有一点让我很喜欢这个社区，那就是这里的一切都非常公开透明，对吧？我特意去找了几个月前讨论过这个话题的讨论区。

是的，主要原因在于同时维护四个版本——因为有时需要发布四个版本——工作量实在太大，尤其是安全版本。这给主要由志愿者组成的贡献者群体带来了很大压力。另一个问题是，各版本的维护工作差异过大。 LTS版本与最新版本差异巨大，导致修复程序的回溯移植非常困难。因此，这会产生大量工作，可能超出了志愿者所能持续承担的范围。

因此，我们的想法是：与其发布那么多包含重大变更的大版本，不如试着缩小我们保留的版本范围。因此，在 2027 年，我们将发布Node ，这将是首个成为 LTS 的奇数版本。这意味着我们每年只需发布一个大版本，这将简化发布人员的工作。而且我认为这对企业也有帮助——你们只需更新一个大版本，而不是两个。

马泰奥，你对此有什么看法吗？还有其他讨论过的事项吗？

顺便说一句，有一点挺好的，那就是第27版正好与年份对应，对吧？就在2028年。

最关键的是要与年份保持一致。

因此Node 将成为 LTS 版本，而 2027 年的Node 也将是 LTS 版本。这里有几点需要说明。最根本的原因在于数据。与其他所有因素相比，这一决定主要基于真实数据。 几乎没有人使用非 LTS 版本。真的几乎没人用。所以这样做毫无意义。发布团队为推出这些版本所做的一切工作，最终只服务于极少数人。而模块作者则需要为这些版本进行测试和维护，但它们的寿命只有六个月。再次强调，这真的不值得。

在开源领域，所有项目都有一个众所周知的现象：如果社区做出了正式的长期支持（LTS）承诺，人们自然会利用这一点。既然如此，谁还会去用非LTS版本呢？

是的，正是如此。有些人这么做是因为想尝试新功能。而且新程序的架构设计中，有一个较长的Alpha版本阶段，我们可以在此期间发布重大变更和破坏性变更。所以，如果你想体验前沿功能，可以使用该版本。 我们依然会发布 Alpha 版本，所以相关工作照常进行。不过最大的区别在于，这些 Alpha 版本不提供任何安全保障。因此无需进行回溯移植，什么都不用做。这减少了安全版本发布所需的工作量，鉴于目前涌入的大量有效报告，安全问题是我们当前最关切的重点之一。

这是本次讨论的另一个重点——安全与漏洞。在深入探讨这个话题之前，我想先提一个重要问题：每六个月我们都会推出大量新功能。这不仅仅是修复 CVE 漏洞，对吧？我想问问大家——你们是怎么做到的？你们有这么多志愿者，还在不断添加新 API、提升性能……

说实话，让我们来深入探讨一下。我们是否在提升性能？是的，或许有一点点。但最大的顾虑在于不破坏向后兼容性，并尽量减少导致用户无法升级的原因。这才是主要驱动力。正如我常说的，我们确实可以让Node.js 变得快得多，但这会引发各种问题。 你们想要更快吗？你们愿意为此付出多少代价？这就是问题所在。而且我们已经证明，即使Node.js 的兼容性只有四、五成，对某些人来说也足够了——确实有项目就是这么做的，而且运行良好。但实际上，拥有大规模部署的企业是不会迁移的。这很难。真的很难。

马可，还有什么？

我还有一件事要说。 大家根本不升级。每当有新一批用户Node 的使用量Node ，但他们却始终停留在那个版本。这种现象正在形成明显的层级分化。我查过数据Node 的下载量依然相当可观。每月下载量大概还在两千万次左右。这简直让人费解——大家到底为什么还要用这个来测试？这都已经是历史遗留版本了。这真的非常成问题。

在功能方面，我们一直在推出新内容。但实际上，我们在某种程度上还是比较保守的。我们本可以推出更多内容。大家原本希望推出更多内容，而我们则试图将范围控制得比大家实际希望的要小一些。

马可，你想补充点什么吗？

我觉得这简直难以置信，也要向Node.js 社区的每一位成员致敬，因为他们一直在不断添加新功能。现实情况是，为了保持向后兼容性，避免破坏基于内部实现的旧系统和框架——我们尽量不让用户受影响。这简直太疯狂了。 有时我们决定不移除某些功能，因为哪怕是一个简单的大版本变更，其影响也可能波及太多人、太多包。真正的难题在于生态系统。例如，有些在 npm 上存在了十五年的包依赖于我们想要弃用的某些内部实现，但我们无法移除，因为这些包虽然已无人维护，却每周仍有五千万次下载。这就是Node.js 往往非常保守的原因。 我们本可以废弃大量 API，移除许多已对外暴露的旧内部实现，但我们做不到。所以每当我看到某个大版本的变更日志时，总会觉得我们本该废弃更多内容，本可以做得更多，但我们做不到。

我听到的这些内容印证了我对这个社区和这个项目的既有认知——这是一个管理得当的项目。各位志愿者和协作者都做得非常出色。他们始终秉持着这样的承诺：在尽可能不破坏现有功能的前提下，持续推进项目发展。 虽然每个新版本都会带来一些破坏性变更和过时的 API，但大家始终恪守着这一承诺。在我看来，这正是Node.js 成功的关键，也是众多组织和应用程序采用它的原因：这里有规范的流程，更有对长期支持的坚定承诺。

现在让我们来谈谈——嗯，虽然这听起来不太愉快，但确实很有意思，有时甚至让人感到有些遗憾——关于安全方面的情况。TSC最近宣布的一项重大变动，Mateo，就是暂停了漏洞赏金计划。虽然有一篇博客文章对此进行了说明，但也许你可以在这里为我们的听众做个说明——同时请澄清，这并不影响修复漏洞的流程。

有两个问题。好的。首先，从去年年初开始，我们看到大量低质量的AI生成的漏洞报告涌现。数量之大令人震惊。因此，有几点情况同时存在。当你报告Node.js漏洞时，可能会发现一个影响Node 漏洞Node 基本上可以成为发起拒绝服务攻击的“银弹Node 这非常糟糕。这是我们可能遇到的情况之一。 又或者，我们可能会收到一个从技术上讲确实是漏洞，但极其依赖特定环境的漏洞——就像月亮和金星必须同时对齐那样，而触发它的唯一方法是先用右脚跳三下，再用左脚跳三下，然后念出咒语。这类漏洞也会被上报。

说实话，这些确实是真实的漏洞。我并不是说它们不是。我只是想说，它们充其量只是些微不足道的漏洞，在更长的攻击链中或许能被利用来扩大攻击者的渗透范围，但单看它们本身，重要性微乎其微。不过，既然它们是 CVE，我们就必须按此对待。但在代码库中发现它们的成本几乎为零。

那么，问题就变成了：我们是否应该为这些漏洞设立赏金？我们是否应该为此买单？我正在消耗代币来生成代币，从而获得金钱。这么说吧：花一百欧元购买代币，以此换取一项能带来一千欧元赏金的漏洞——这绝对是一笔超值的投资。一百美元的订阅费，通过赏金每月能转化为一千欧元。人们完全可以靠这个生活。

但这真的是我们想要鼓励或维持的吗？如果现在有公司愿意赞助，那当然没问题。我们非常乐意进行筛选并完成相关工作。但现实是，已经没有赞助商了。说实话，我们想终止这种乱象。这种乱象才是最大的问题，因为很多人会把它当作一种快速赚钱的手段，而报告内容却完全缺乏专业性。 我并不介意与人工智能对话，但人工智能的表现反而比我们见过的许多报告更专业。我们甚至见过有人直接将提示词复制粘贴到报告中。他们的专业性甚至连正确复制粘贴都做不到。

当然，我们想谈谈人工智能。听众们也想谈谈人工智能。不过首先，马可，还有一件重要的事——悬赏计划的暂停并不影响安全漏洞报告流程。该流程保持不变。

你能详细介绍一下这个流程吗？包括接诊和分诊环节？

是的，漏洞提交是通过HackerOne进行的。 我们通过HackerOne接收漏洞报告。我们会对这些报告进行分类处理——这是由志愿者负责的，所以只有部分人在有空时才会参与分类工作。由于收到的报告数量庞大，且目前生成报告所需的时间与分类处理所需的时间之间存在不平衡，因此对这项工作感兴趣的人并不多。要验证问题是否属实并复现它，需要花费一定时间。这就是最大的问题之一。

不过，当我们在HackerOne上收到报告，且报告数量足够发布新版本时，我们会发布公告，例如宣布两周后将发布一个安全更新版本。在此期间，我们会私下为这些漏洞编写补丁。 此外，我们还需协调多个版本，确保它们能与更新版同步发布。这是最困难的部分，因为需要协调两到三个人——有时甚至更多——毕竟我们需要将修复漏洞的开发人员与发布人员集中起来，确保他们能同步开展工作。因此，每次发布安全更新时，工作量都十分庞大。那几周对所有参与人员来说都异常紧张。

这也是我们调整日程安排的原因之一——为了在那些时段减少工作量。当然，这一点不言而喻：报告中的信息越详尽越好。如果你已经有了具体的解决方案，请将所有内容都写进报告中。

人们很少会附上修复方案。大多数情况下这根本不可能。即使有修复方案，大多数人也不会附上。但我们很欢迎大家提供。有时会有非常好的补丁，有时则没有。

这个流程虽然可行，但因为是串联进行的，所以工作强度很大。我们在Node.js 组织内部维护Node 几个Node 的依赖项Node 叫 LLHTTPNode 就是我们的 HTTP 解析器。我们需要发布这个 HTTP 解析器的版本——顺便说一句，这是一项很有意思的技术，你应该找个时间让 Paolo 来聊聊这个。 总之，这就是那个 HTTP 解析器。此外还有 Undici，这是我们用于 Fetch 的库，同时也支持许多基于 WhatWG 的新 API。 我是 Undici 的主要维护者，在Node 的每次安全版本发布中，都会包含大量 Undici 的修复。目前Node 三个 LTSNode 、Node 以及当前活跃的Node ——我们需要为这三个版本发布补丁。Node 使用的是 Undici 6，而其他版本则各自使用不同的版本。

这个社区、这些贡献者和合作者付出了巨大的努力。此外，还有成千上万家组织正在运行基于 JavaScript、Node.js、TypeScript 等技术的生产环境系统。正因如此，像 HeroDevs 这样的公司才会回馈这些社区并做出贡献。你不仅是在提供帮助——作为社区的一员，你还能从中获得丰富的专业知识和经验。

好的，我们来聊聊人工智能吧，毕竟大家当然都想聊这个话题。 市面上涌现了大量新工具，人们也在报告这些AI系统中的漏洞。但我同时也听说——Marco，你写过一篇关于这个话题的不错博文——这不仅仅是报告问题，上下文和知识才是最重要的部分。不过我也想谈谈一个事实，那就是情况实际上正在好转。也许现在，这些大型语言模型（LLMs）确实开始报告一些真实的漏洞了。

确实如此。确实如此。我们发现了真正的漏洞。这是真的。大型语言模型（LLMs）的能力——其中大部分以前只是bug，但现在甚至变成了真正的漏洞。我认为这一比例已显著上升。上次我查看时，这个比例是66%，而之前是50%。 之前情况曾一度非常糟糕，但后来有所好转。到目前为止，我认为报告的大多数问题都足够合理，且调试起来并非易事。那些简单的问题已经记录在案。我们一直在开展一项工作，旨在安全文档中详细记录所有能区分“优质漏洞”与“劣质漏洞”的标准。

Node.js 与 Mitre 有关联吗？

遗憾的是，目前还不行。我们已经申请了访问权限，但至今尚未获批。我相信这终将实现——毕竟这肯定属于关键的开源项目之一。不过，即便没有这个权限，我们也能看到LLM报告的问题数量有所减少。而且我读到的一点特别有趣：它们不仅具备超越人类的能力，还能将多个漏洞串联起来，从而生成实际可用的漏洞利用程序。

是啊，这正是难点所在。这就是其独特之处——那唯一且具体的一点。在某些情况下，一些严重程度仅为低或中级的CVE，一旦与其他CVE串联起来，就可能演变成极其严重的漏洞。

马可，我得问你：我们收到了新的 CVE 漏洞报告，也获得了新的漏洞修复方案。但随后你们还得回过头去为 HeroDevs 的那些已停止维护的版本打补丁。这需要付出多少工作量？

是啊，所以……当我说我在用Node 、Node 、Node 开发时，其他同事都会一脸茫然：什么？因为依赖库太老旧，在这些旧版本的Node 。另一个大问题是这些旧版本的安全性太差。这种情况经常发生。 每当我在修复漏洞时，我都会自问：六七年前我们是怎么熬过来的？因为随着我们不断推进工作，发现了大量漏洞和 bug。每当有新的安全补丁发布，我都会检查它是否适用于已停用的旧版本，而大多数时候确实适用。所以即便我们已经向前迈进，在旧版本中依然能发现 bug。这简直太疯狂了。

为了让听众更清楚：长期支持的结束意味着上游将不再提供修复程序。以Node 为例，您将不得不转向像 HeroDevs 这样的商业解决方案。这显然是一个巨大的挑战，而项目持续前进——坦率地说，尽可能快地前进——也是理所当然的。这当然带来了迁移和破坏性变更的挑战。 正如Matteo之前所说，我们发现许多企业和组织并未进行迁移。他们仍在使用18、20等版本，甚至一些更旧的版本。

马可，这工作量可不小，你和HeroDevs的其他几位工程师在开发和测试上都付出了巨大努力。其实，这正是我想问你们的另一件事。每次发布前肯定都要进行海量的测试，你们是怎么做到的？

是的。发布过程中最难的部分是让持续集成（CI）通过。我们在许多冷门平台上运行了大量测试。我们有一个名为“金矿中的金丝雀”（Canary in the Goldmine）的机制，会将候选版本与生态系统中的 npm 包进行兼容性测试，以确保不会破坏这些包。我们有大量需要运行数小时的 CI 任务。每次任务失败，就必须重新运行并等待数小时。虽然这相当令人头疼，但确实至关重要。

这种感觉永远不会消散。

这个问题始终无法解决。有一段时间，我确实在努力提高系统的可靠性。我们每天都会收到一份可靠性报告，显示有多少测试结果不稳定，有一阵子我一直在修复这些问题，并将报告数据输入AI系统。虽然有几个人抱怨这些PR（拉取请求）质量不高，但至少我是在尽力帮忙。后来我停手了。但问题非常棘手，因为就连将这些修复方案合并到代码库里都很困难，这绝非易事。

是啊，这工作量确实巨大。任何负责发布版本的开发者都能感同身受。

最后我想补充一点。最近在伦敦举办了一场Node.js社区聚会，会上讨论了多项计划。正是那时宣布了这次发布计划的调整。Marco或Matteo，关于Node.js的未来发展，你们还有什么要补充的吗？例如在安全方面——针对CVE报告数量的增加，在处理方式上是否有其他消息或调整？

我目前还担任 OpenJS 基金会的理事，我们正与一群供应商合作，他们已表示愿意资助该悬赏计划的开发工作。 我们正在努力设计一种机制，既能让这些厂商合理地支持该计划并从中获益，又能让维护者觉得投入时间是值得的。如果我们对一些相对容易解决的问题设置悬赏，那简直就是一种“快速致富”的骗局。悬赏对象可能应该仅限于高危和关键漏洞。

说实话，我们完全可以这么做：拿这笔钱，通过销毁代币来自己找出所有漏洞。这已经变成了一场数字游戏。 我真的很想给那些做真正扎实工作、发现真正能影响数百万人的问题的研究人员提供高额赏金。我们确实遇到过几例——其中有些非常、非常重大的漏洞。但通常情况下，发现的只是微不足道的边缘案例，或者可能只有在node 未部署在CDN和负载均衡器之后时才有效，而坦白说，现在几乎没有人会这样配置。

或者总有人不断报告检查器协议的问题。 我们已经到处都写明了：如果你使用检查器协议，后果自负。这些是开发阶段的调试工具。请不要在生产系统中保持该协议开放。但人们却一直将其报告为攻击场景。但实际上，你根本无法保障其安全。它根本无法被加固——它从设计之初就是为了允许他人接管该node 。这是不可能的。

以前我从事应用安全工作时，曾做过一场演讲，内容是：看，外面有数以百万计的漏洞。大家应该多关注那些已有记录的漏洞利用。但即便是这些，往往也微不足道。

我们来谈谈我在上一期安全专题中处理的一个漏洞——在 Undici 项目中。在Node.js 中，我们提供了一个基于规范的 WebSocket 实现。虽然这个标准并不完美，但这属于另一个话题。 总之，WebSocket 标准提供了一种进行数据包压缩的选项，因为 WebSocket 数据包在 TCP 之上还有自己的帧结构——即 HTTP、WebSocket，然后是它们自己的帧结构。你可以对这些数据包进行压缩。我之前并不知道这一点，但我们的实现支持这一功能。

结果发现，如果有人使用Node.js 连接到一个你因某种原因不信任的远程 WebSocket 实例，该服务器可以向你发送一个“银弹”数据包，从而引发拒绝服务并导致你的应用程序崩溃——因为这个数据包大小可能只有几百千字节，但在内存中会膨胀到几百吉字节，最终导致系统崩溃。简直易如反掌。

情况就是这样。而另一方面——仍然以Undici为例——这是个必须手动启用的功能。只有当你启用该实验性功能并编写代码手动启用它时，才会出现这个漏洞。因此，情况是这样的：一方面，它很难被利用。 你需要一个能够连接到 WebSocket 且接受远程 WebSocket 服务器作为输入的应用程序，这使得该漏洞的适用范围非常有限。

如此之多，如此之多的细节。对我来说，这正是该项目及所有志愿者为这个生态系统带来的价值所在。

我刚刚快速浏览了一下问题，我觉得我们已经都讲到了。其中有一个问题是关于人工智能带来的漏洞类型。最后我想说一句：快乐的时光总是过得飞快。我相信，关于这个话题，我们还能再聊上两三个小时。

希望各位听众觉得这次分享很有价值。我们今后还会继续举办此类网络研讨会。请允许我再次强调，HeroDevs 是 OpenJS 基金会生态系统可持续发展计划的创始成员。我们在支持开源社区的同时，也为那些仍在使用已停止维护的Node 版本的企业提供服务。我们支持从 12 版开始的版本——Marco，是这样吗？

十二岁、十四岁、十六岁、十八岁，现在二十岁。

此外，针对希望在产品生命周期结束前做好准备的客户，我们还提供了二十二版和二十四版的定制版本，这些版本将在产品生命周期结束前推出。

太好了。马泰奥和马尔科，非常感谢你们的参与。感谢你们抽出时间。我很乐意继续这个话题，也感谢大家的收看。再见，各位。再见。

‍