从 12 月 1 日开始，Electron 项目将进入一个安静期，并在 2026 年 1 月恢复到全力运行。有关完整详细信息，请参阅下面的 政策 部分。

自 2020 年以来，12 月一直是项目维护者从常规维护工作中抽身休息或专注于深入工作的时期。这种休息有助于我们恢复精力，为来年做好准备。

也就是说，像这样为期一个月的暂停只有在开源项目处于健康状态时才能实现——我们感谢所有维护者和外部贡献者为保持项目进展所做的持续努力。❤️

Electron 项目将在 2024 年 12 月暂停，然后在 2025 年 1 月恢复全速运行。

来自 GIPHY

12 月会保持不变​

1. 零日漏洞和其他重大安全相关的发布将根据需要发布。安全事件应通过 SECURITY.md 报告。
2. 行为准则 报告和审核将继续进行。

12 月会发生变化​

1. 2024 年最后一个稳定分支版本（包括 Electron 31、32 和 33）将在 12 月 1 日那一周发布。12 月将没有其他计划中的版本发布。
2. 12 月的最后两周将不会有 Nightly 和 Alpha 版本发布。
3. 除少数例外情况外，不会进行 Pull Request 的审查或合并。
4. 任何代码仓库的 Issue Tracker 都不会有更新。
5. 维护者不会在 Discord 上提供调试帮助。
6. 社交媒体内容将暂停更新。

2025年再见！

Electron 项目将在 2023 年 12 月暂停，并于 2024 年 1 月恢复全面开发。

来自 GIPHY

12 月会保持不变​

1. 零日漏洞和其他重大安全相关的发布将根据需要发布。安全事件应通过 SECURITY.md 报告。
2. 行为准则 报告和审核将继续进行。

12 月会发生变化​

1. Electron 28.0.0 将于 12 月 5 日发布。在 Electron 28 之后，12 月将不再有新的稳定版发布。
2. 12 月的最后两周将不会有 Nightly 和 Alpha 版本发布。
3. 除少数例外情况外，不会进行 Pull Request 的审查或合并。
4. 任何代码仓库的 Issue Tracker 都不会有更新。
5. 维护者不会在 Discord 上提供调试帮助。
6. 社交媒体内容将暂停更新。

未来计划​

这是我们第三年尝试静默期实验，到目前为止，我们已成功地平衡了一个月的休息时间和之后保持正常发布节奏的需求。因此，我们决定将其作为我们发布日历的常规组成部分。我们仍会在每个日历年的最后一个稳定版本中添加提醒。

2024 年再见！

electron/electron 仓库的第一次提交是在 2013 年 3 月 13 日¹。

10 年间，来自 1192 位独立贡献者的 27,147 次提交，Electron 已成为当今最流行的桌面应用程序构建框架之一。这个里程碑是庆祝和反思我们迄今为止的旅程，并分享我们一路走来所学到的经验的绝佳机会。

如果没有各位投入时间和精力为项目做出贡献，我们今天就不会取得如此成就。尽管源代码提交始终是最显而易见的贡献，但我们也必须感谢那些报告 Bug、维护用户态模块、提供文档和翻译，以及在网络空间中参与 Electron 社区的人们所付出的努力。对于我们这些维护者来说，每一次贡献都弥足珍贵。

在继续阅读这篇博客文章之前：谢谢你。❤️

我们是如何走到这一步的？​

Atom Shell 最初是作为 GitHub 的 Atom 编辑器 的基础构建的，该编辑器于 2014 年 4 月公开发布 Beta 版本。它从头开始构建，作为当时可用的基于 Web 的桌面框架（node-webkit 和 Chromium Embedded Framework）的替代方案。它具有一个强大的功能：嵌入 Node.js 和 Chromium，为 Web 技术提供强大的桌面运行时。

一年之内，Atom Shell 的功能和受欢迎程度开始迅速增长。大型公司、初创公司和个人开发者都开始使用它构建应用程序（一些早期采用者包括 Slack、GitKraken 和 WebTorrent），并且该项目被恰当地重命名为 Electron。

从那时起，Electron 一帆风顺，从未停止。以下是 npmtrends.com 提供的随时间推移的每周下载量统计：npmtrends.com

Electron v1 于 2016 年发布，承诺提供更稳定的 API、更好的文档和工具。Electron v2 于 2018 年发布，并引入了语义化版本控制，使 Electron 开发者更容易跟踪发布周期。

到 Electron v6 版本，我们转向了与 Chromium 匹配的每 12 周发布一个主要版本的节奏。这个决定改变了项目的理念，将“拥有最新的 Chromium 版本”从一个不错的选择提升为优先事项。这减少了升级之间的技术债务量，使我们更容易保持 Electron 的更新和安全。

从那时起，我们就像一台运转良好的机器，在每个 Chromium 稳定版发布的同一天发布一个新的 Electron 版本。到 2021 年 Chromium 将发布周期加快到 4 周时，我们能够轻松应对，并将发布节奏相应地加快到 8 周。

我们现在正使用 Electron v23（且仍在继续增长），并且仍然致力于为构建跨平台桌面应用程序提供最佳运行时。尽管近年来 JavaScript 开发工具蓬勃发展，但 Electron 仍然是桌面应用程序框架领域稳定、久经考验的中坚力量。Electron 应用程序如今无处不在：你可以使用 Visual Studio Code 编程，使用 Figma 进行设计，使用 Slack 进行交流，并使用 Notion 记笔记（以及许多其他用例）。我们为这一成就感到无比自豪，并感谢所有促成此事的人。

我们一路学到了什么？​

通往十周年的道路漫长而曲折。以下是一些帮助我们运营一个可持续的大型开源项目的关键经验。

使用治理模式扩展分布式决策​

当 Electron 首次流行起来后，我们必须克服的一个挑战是如何处理项目的长期发展方向。我们如何管理一个由分布在不同公司、国家和时区的几十名工程师组成的团队？

早期，Electron 的维护者团队依靠非正式协调，这对于小型项目来说快速且轻量，但无法扩展到更广泛的协作。2019 年，我们转向了治理模型，其中不同的工作组拥有正式的职责范围。这对于简化流程并将项目所有权的一部分分配给特定的维护者至关重要。如今，每个工作组 (WG) 负责什么？

• 负责发布 Electron 版本（Releases WG）
• 升级 Chromium 和 Node.js（Upgrades WG）
• 监督公共 API 设计（API WG）
• 维护 Electron 的安全（Security WG）
• 运营网站、文档和工具（Ecosystem WG）
• 社区和企业推广（Outreach WG）
• 社区管理（Community & Safety WG）
• 维护我们的构建基础设施、维护者工具和云服务（Infrastructure WG）

与我们转向治理模式的同时，我们也将其所有权从 GitHub 转移到 OpenJS Foundation。虽然最初的核心团队今天仍在 Microsoft 工作，但他们只是构成 Electron 治理的更大合作者群体的一部分。²

虽然这个模式并非完美，但它在全球疫情和持续的宏观经济逆风中很好地支持了我们。展望未来，我们计划修订治理章程，以指导我们度过 Electron 的第二个十年。

社区​

开源的社区部分很难，特别是当你的外展团队是穿着风衣的十几名工程师，上面写着“社区经理”时。话虽如此，作为一个大型开源项目意味着我们拥有大量用户，利用他们的精力为 Electron 构建用户态生态系统是维持项目健康的关键部分。

我们为发展我们的社区做了些什么？

构建虚拟社区​

• 2020 年，我们启动了社区 Discord 服务器。我们之前在 Atom 的论坛中有一个版块，但决定使用一个更非正式的消息平台，为维护者和 Electron 开发者之间的讨论以及一般的调试帮助提供一个空间。
• 2021 年，我们借助 @BlackHole1 的帮助，建立了 Electron China 用户组。该小组对于 Electron 在中国蓬勃发展的科技领域中的用户增长起到了重要作用，为他们提供了一个协作交流想法和讨论 Electron 的空间，而无需使用我们的英语语言空间。我们还要感谢 cnpm，感谢他们为 npm 的 Electron 夜间版本在中国镜像中提供支持。

参与高知名度的开源项目​

• 自 2019 年以来，我们每年都会庆祝 Hacktoberfest。Hacktoberfest 是 DigitalOcean 组织的一年一度的开源庆祝活动，每年都有数十位热情的贡献者希望在开源软件上留下自己的印记。
• 2020 年，我们参与了 Google Season of Docs 的初始迭代，与 @bandantonio 合作重新设计了 Electron 的新用户教程流程。
• 2022 年，我们首次指导了一名 Google Summer of Code 学生。@aryanshridhar 完成了一些很棒的工作，以重构 Electron Fiddle 的核心版本加载逻辑，并将其打包器迁移到 webpack。

自动化所有事情！​

如今，Electron 治理团队拥有大约 30 名活跃的维护者。我们中只有不到一半是全职贡献者，这意味着有很多工作要做。我们保持一切顺利运行的秘诀是什么？我们的座右铭是：计算机很便宜，而人的时间很宝贵。本着典型的工程师精神，我们开发了一套自动化支持工具，让我们的生活更轻松。

不是 Goma​

Electron 的核心代码库是一个庞大的 C++ 代码库，构建时间一直是限制我们发布错误修复和新功能的快慢的因素。2020 年，我们部署了 Not Goma，这是 Electron 专用的 Google 的 Goma 分布式编译器服务的后端。Not Goma 处理来自授权用户机器的编译请求，并将该过程分配到后端数百个核心上。它还会缓存编译结果，以便其他人编译相同的文件只需要下载预编译的结果。

自从推出 Not Goma 以来，维护者的编译时间从几小时缩短到了几分钟。稳定的网络连接成为贡献者编译 Electron 的最低要求！

持续因素身份验证​

持续因素身份验证 (CFA) 是围绕 npm 的双因素身份验证 (2FA) 系统的一层自动化，我们将其与 semantic-release 结合使用，以管理我们各种 @electron/ npm 包的安全自动化发布。

虽然 semantic-release 已经自动化了 npm 包的发布过程，但它需要关闭双因素认证，或者传入一个绕过此限制的秘密令牌。

我们构建了 CFA，以便为任意的 CI 作业提供基于时间的一次性密码 (TOTP) 用于 npm 2FA，这使我们能够利用 semantic-release 的自动化，同时保持双因素认证的额外安全性。

我们使用 CFA 与一个 Slack 集成前端，允许维护者在任何装有 Slack 的设备上验证包的发布，只要他们手头有 TOTP 生成器。

Sheriff​

Sheriff 是我们编写的一个开源工具，用于自动化 GitHub、Slack 和 Google Workspace 中的权限管理。

Sheriff 的核心价值主张是权限管理应该是一个透明的过程。它使用单个 YAML 配置文件来指定上述所有服务的权限。使用 Sheriff，获得仓库的协作者状态或创建新的邮件列表就像获得 PR 批准和合并一样简单。

Sheriff 还有一个审计日志，会发布到 Slack，当 Electron 组织内任何地方发生可疑活动时，会警告管理员。

…以及我们所有的 GitHub 机器人​

GitHub 是一个具有丰富的 API 可扩展性和第一方机器人应用程序框架 Probot 的平台。为了帮助我们专注于工作的更具创造性的部分，我们构建了一套较小的机器人，以帮助我们完成脏活累活。以下是一些示例

• Sudowoodo 自动化 Electron 发布过程从头到尾，从启动构建到将发布资源上传到 GitHub 和 npm。
• Trop 通过尝试根据 GitHub PR 标签将补丁移植到以前的版本分支来自动化 Electron 的回溯过程。
• Roller 自动化 Electron 的 Chromium 和 Node.js 依赖项的滚动升级。
• Cation 是我们 electron/electron PR 的状态检查机器人。

总而言之，我们这个小小的机器人家族极大地提高了我们的开发效率！

接下来是什么？​

当我们进入项目的第二个十年时，你可能会问：Electron 的下一步是什么？

我们将与 Chromium 的发布节奏保持同步，每 8 周发布一个 Electron 的新主要版本，使框架与 Web 平台和 Node.js 的最新和最强大的功能保持同步，同时保持企业级应用程序的稳定性和安全性。

我们通常会在即将到来的计划变得具体时宣布新闻。如果您想了解未来的发布、功能和常规项目更新，您可以阅读 我们的博客 并关注我们的社交媒体资料（Twitter 和 Mastodon）！

从 Electron 23 开始，Electron 将结束对 Windows 7、Windows 8 和 Windows 8.1 的支持。

根据 Chromium 的弃用政策，Electron 将从 Electron 23 开始停止对 Windows 7、Windows 8 和 Windows 8.1 的支持。这与微软停止对 Windows 7 ESU 和 Windows 8.1 扩展支持 的时间一致，时间为 2023 年 1 月 10 日。

Electron 22 将是支持 Windows 10 之前版本的最后一个 Electron 主要版本。Windows 7/8/8.1 将不再在 Electron 23 及更高版本的主要版本中得到支持。较旧版本的 Electron 将继续在 Windows 7 上运行，我们将继续为 Electron 22.x 系列发布补丁，直到 2023 年 5 月 30 日，届时 Electron 将停止对 22.x 的支持（根据我们的 支持时间表）。

为什么要弃用？​

Electron 遵循 Chromium 计划的弃用政策，该政策将在 Chromium 109 中弃用支持 (在此处了解 Chromium 的时间表)。Electron 23 将包含 Chromium 110，该版本将不再支持较旧版本的 Windows。

因此，包含 Chromium 108 的 Electron 22 将是最后一个受支持的版本。

弃用时间表​

以下是我们计划的弃用时间表

• 2022 年 12 月：Electron 团队进入假期休整期
• 2023 年 1 月：所有受支持的发布分支都接受与 Windows 7 和 8 相关的问题。
• 2023 年 2 月 7 日：Electron 23 发布。
• 2023 年 2 月 8 日 - 2023 年 5 月 29 日：Electron 将继续为早于 Electron 23 的受支持产品线接受修复。
• 2023 年 5 月 30 日：Electron 22 达到其支持周期终点。

这对开发者意味着什么

• Electron 团队将为稳定的受支持产品线接受与 Windows 7/8/8.1 相关的问题和修复，直到每个产品线达到其支持周期终点。
  • 这特别适用于 Electron 22、Electron 21 和 Electron 20。
• 对于早于 Electron 23 的版本，将接受与 Windows 7/8/8.1 相关的新问题。
  • 任何更新的发布产品线将不再接受新问题。
• 一旦 Electron 22 达到其支持周期终点，所有与 Windows 7/8/8.1 相关的现有问题都将被关闭。

接下来会发生什么​

如果您有任何问题或疑虑，请随时通过 info@electronjs.org 与我们联系。您还可以在我们的官方 Electron Discord 中找到社区支持。

Electron 项目将在 2022 年 12 月暂停，并于 2023 年 1 月恢复全速运行。

来自 GIPHY

12 月会保持不变​

1. 零日和其他重大安全相关发布将根据需要发布。 应该通过 SECURITY.md 报告安全事件。
2. 行为准则 报告和审核将继续进行。

12 月会发生变化​

1. 12 月份不发布稳定版本。12 月最后两周不发布 Nightly 和 Alpha 版本。
2. 除少数例外情况外，不会进行 Pull Request 的审查或合并。
3. 任何代码仓库的 Issue Tracker 都不会有更新。
4. 维护者不会在 Discord 上提供调试帮助。
5. 社交媒体内容将暂停更新。

为什么会发生这种情况？​

鉴于2021年12月寂静月（Quiet Month）的成功，我们希望在2022年再次举办。对大多数公司来说，12月仍然是一个比较平静的月份，所以我们希望让我们的维护者有机会好好充电。每个人都在期待2023年，我们预计会有好事情发生！我们鼓励其他项目考虑采取类似的措施。

上个月，Electron 维护者团队在加拿大温哥华会面，讨论了该项目在 2023 年及以后的发展方向。在会议室里，核心维护者和特邀合作者们用了四天时间讨论了新举措、维护痛点以及项目的整体健康状况。

未来，团队将继续全力致力于定期快速发布 Chromium 更新、修复 bug，并让 Electron 对所有人来说更安全、性能更好。我们还有一些令人兴奋的项目正在开发中，非常乐意与社区分享！

变革性的新 API​

Electron 项目中需要达成共识的主要 API 提案，会通过“征求意见”（RFC）流程，由我们的 API 工作组的成员进行审查。

今年，我们推动了两项可能为 Electron 应用解锁新维度能力的重大提案。这些提案仍是高度实验性的，但以下是我们对即将到来的内容的抢先预览！

新的原生插件增强功能 (C API)​

该提案概述了一层新的 Electron C API，它将允许应用程序开发者编写自己的原生 Node 插件，与 Electron 的内部资源进行交互，类似于 Node 自身的 Node-API。有关拟议的新 API 的更多信息 请在此处查看。

示例：使用 Chromium 资源提升应用程序性能​

许多 Electron 应用程序维护着自己的分支，以便直接与 Chromium 内部组件交互，而这些组件在普通（未修改）的 Electron 中是无法访问的。通过在 C API 层公开这些资源，这些代码可以作为原生模块与 Electron 一起存在，从而可能减轻应用程序开发者的维护负担。

暴露 Chromium 的 UI 层 (Views API)​

在底层，Chrome 用户界面（UI）的非网站部分（例如工具栏、标签页或按钮）是使用一个名为 Views 的框架构建的。Views API 提案将该框架的部分内容引入 Electron 中的 JavaScript 类，最终目标是允许开发人员为其 Electron 应用程序创建非 Web UI 元素。这将使应用程序无需拼凑 Web 内容。

使这套新 API 成熟的基础工作正在进行中。以下是我们可以在不久的将来看到的一些首批成果。

示例：使用 WebContentsView 重构窗口模型​

我们计划进行的第一个更改是向 Electron 的 API 表面公开 Chrome 的 WebContentsView，它将是我们现有 BrowserView API 的继任者（尽管名称如此，但 BrowserView API 是 Electron 特有的代码，与 Chromium Views 无关）。通过公开 WebContentsView，我们将拥有一个可重用的 View 对象，可以显示 Web 内容，为使 BrowserWindow 类成为纯 JavaScript 并消除更多代码复杂性打开了大门。

虽然这个更改没有为应用开发者提供太多新功能，但它是一个大型重构，消除了大量的底层代码，简化了 Chromium 升级，并降低了主要版本之间出现新 bug 的风险。

如果您是 Electron 应用开发者，并且正在使用 BrowserViews：请放心，我们没有忘记您！我们计划将现有的 BrowserView 类变成 WebContentsView 的一个包装器，为您向较新的 API 过渡提供缓冲。

参见：electron/electron#35658

示例：使用 ScrollView 实现可滚动的网页内容​

我们的朋友 Stack 正在推动一项倡议，将 Chromium ScrollView 组件暴露给 Electron 的 API。有了这个新的 API，任何子 View 组件都可以水平或垂直滚动。

虽然这个新 API 只实现了单一的小功能，但团队的最终目标是构建一套工具性的 View 组件，可以作为工具包来构建更复杂的非 HTML 界面。

参与其中​

您是对这两个 API 提案感兴趣的 Electron 应用开发者吗？虽然我们还没有准备好接收额外的 RFC，但请继续关注未来更多详情！

Electron Forge v6 稳定版发布​

自框架问世以来，Electron 的构建工具生态系统在很大程度上是社区驱动的，并且由许多小型单一用途的包组成（例如 electron-winstaller、electron-packager、electron-notarize、electron-osx-sign）。尽管这些工具运行良好，但用户需要拼凑一个可用的构建流水线，这让他们望而却步。

为了帮助为 Electron 开发人员构建更友好的体验，我们构建了 Electron Forge，这是一个一体化解决方案，将所有现有工具整合到一个单一的界面中。尽管 Forge 自 2017 年以来一直在开发中，但在过去的几年里该项目一直处于停滞状态。然而，考虑到社区对 Electron 构建工具状态的反馈，我们一直在努力发布下一代 Forge 的稳定主版本。

Electron Forge 6 提供了对 TypeScript 和 Webpack 的一流支持，以及一个可扩展的 API，允许开发者创建自己的插件和安装程序。

敬请期待：公告即将发布​

如果您有兴趣使用 Forge 构建项目，或者使用 Forge 的可扩展第三方 API 构建模板或插件，请在本月晚些时候关注我们关于 Forge v6 稳定版发布的官方公告！

接下来是什么？​

除上述内容外，团队一直在考虑许多探索性项目，以改善应用程序开发者和最终用户的 Electron 体验。更新工具、API 审查流程和增强的文档是我们正在试验的其他一些项目。我们希望在不久的将来分享更多消息！

Electron 21 及更高版本将启用 V8 内存笼，这对一些原生模块有影响。

在 Electron 21 中，我们将启用 V8 沙盒指针，遵循 Chrome 在 Chrome 103 中 做出同样决定的。 这对原生模块有一些影响。 此外，我们之前已经在 Electron 14 中启用了相关技术，指针压缩。 当时我们没有过多讨论，但指针压缩对 V8 堆的最大大小有影响。

这两种技术在启用后，在安全性、性能和内存使用方面都有显著的好处。然而，启用它们也有一些缺点。

启用沙盒指针的主要缺点是，指向外部（“堆外”）内存的 ArrayBuffers 不再被允许。这意味着依赖 V8 中此功能的原生模块需要重构才能在 Electron 20 及更高版本中继续工作。

启用指针压缩的主要缺点是 V8 堆的最大大小限制为 4GB。 细节有点复杂——例如，ArrayBuffers 与 V8 堆的其余部分分开计算，但有其 自己的限制。

Electron 升级工作组 (Electron Upgrades Working Group) 认为指针压缩和 V8 内存笼的优势大于缺点。 这样做有三个主要原因

1. 它使 Electron 更接近 Chromium。Electron 在 V8 配置等复杂内部细节上与 Chromium 的差异越小，我们意外引入错误或安全漏洞的可能性就越小。Chromium 的安全团队实力强大，我们希望确保我们能利用他们的工作。此外，如果一个错误只影响 Chromium 未使用的配置，那么修复它可能不是 Chromium 团队的优先事项。
2. 性能更好。 指针压缩可以将 V8 堆大小减少高达 40%，并提高 CPU 和 GC 性能 5%–10%。 对于绝大多数不会达到 4GB 堆大小限制且不使用需要外部缓冲区的原生模块的 Electron 应用程序，这些都是显著的性能提升。
3. 更安全。 一些 Electron 应用程序运行不受信任的 JavaScript（希望遵循我们的 安全建议！），对于这些应用程序，启用 V8 内存笼可以保护它们免受一大类恶意的 V8 漏洞的影响。

最后，对于确实需要更大堆大小的应用程序，有一些解决方法。 例如，可以将不启用指针压缩的 Node.js 副本包含在您的应用程序中，并将耗内存的工作转移到子进程中。 虽然有点复杂，但也可以构建一个禁用指针压缩的自定义 Electron 版本，如果您决定为您的特定用例想要不同的权衡，也是可以的。 最后，在不久的将来，wasm64 将允许使用 WebAssembly 构建的应用程序，无论是在 Web 上还是在 Electron 中，都可以使用超过 4GB 的内存。

常见问题解答​

我如何知道我的应用程序是否受到此更改的影响？​

尝试使用 ArrayBuffer 包装外部内存将在 Electron 20+ 中导致运行时崩溃。

如果您的应用程序中没有使用任何原生 Node 模块，那么您是安全的——无法从纯 JS 触发此崩溃。此更改仅影响那些在 V8 堆之外分配内存（例如使用 malloc 或 new），然后用 ArrayBuffer 包装外部内存的原生 Node 模块。这是一种相当罕见的用例，但有些模块确实使用了这种技术，并且此类模块需要重构才能与 Electron 20+ 兼容。

我如何测量我的应用程序正在使用的 V8 堆内存量，以了解我是否接近 4GB 的限制？​

在渲染进程中，您可以使用 performance.memory.usedJSHeapSize，它将以字节为单位返回 V8 堆的使用量。 在主进程中，您可以使用 process.memoryUsage().heapUsed，它是可比的。

什么是 V8 内存笼？​

有些文档将其称为“V8 沙盒”，但该术语很容易与 Chromium 中发生的 其他类型的沙盒 混淆，所以我坚持使用“内存笼”这个术语。

有一种相当常见的 V8 漏洞利用方式，大致如下：

1. 在 V8 的 JIT 引擎中发现一个错误。JIT 引擎分析代码，以便能够省略缓慢的运行时类型检查并生成快速机器码。有时逻辑错误意味着它错误地进行了这种分析，并省略了它实际需要的类型检查——例如，它认为 x 是一个字符串，但实际上它是一个对象。
2. 利用这种混淆来覆盖 V8 堆中的某些内存位，例如 ArrayBuffer 开始位置的指针。
3. 现在您拥有一个指向任意位置的 ArrayBuffer，因此您可以读取和写入进程中的任何内存，即使是 V8 通常无法访问的内存。

V8 内存笼是一种旨在从根本上防止这种攻击的技术。 实现方法是不在 V8 堆中存储任何指针。 相反，V8 堆内的所有其他内存的引用都存储为从某个保留区域的开头偏移量。 然后，即使攻击者设法破坏了 ArrayBuffer 的基地址，例如通过利用 V8 中的类型混淆错误，他们所能做的就是读取和写入笼子内的内存，而他们可能已经能够这样做。 关于 V8 内存笼的工作原理还有更多内容可供阅读，因此我不会在此处深入探讨——最好的起点可能是 Chromium 团队的 高级设计文档。

我想重构一个 Node 原生模块以支持 Electron 21+。 我该怎么做？​

有两种方法可以重构原生模块以使其与 V8 内存笼兼容。第一种方法是，在将外部创建的缓冲区传递给 JavaScript 之前，将其**复制**到 V8 内存笼中。这通常是一个简单的重构，但当缓冲区很大时可能会很慢。另一种方法是**使用 V8 的内存分配器**来分配您打算最终传递给 JavaScript 的内存。这有点复杂，但可以避免复制，这意味着对于大缓冲区来说性能更好。

为了使这一点更具体，这里有一个使用外部 ArrayBuffer 的 N-API 模块示例

// Create some externally-allocated buffer.
// |create_external_resource| allocates memory via malloc().
size_t length = 0;
void* data = create_external_resource(&length);
// Wrap it in a Buffer--will fail if the memory cage is enabled!
napi_value result;
napi_create_external_buffer(
    env, length, data,
    finalize_external_resource, NULL, &result);

当启用内存笼时，这会崩溃，因为数据是在笼子外面分配的。重构为复制数据到笼子中，我们得到：

size_t length = 0;
void* data = create_external_resource(&length);
// Create a new Buffer by copying the data into V8-allocated memory
napi_value result;
void* copied_data = NULL;
napi_create_buffer_copy(env, length, data, &copied_data, &result);
// If you need to access the new copy, |copied_data| is a pointer
// to it!

这将数据复制到一个新分配的内存区域，该区域位于 V8 内存笼内。可选地，N-API 还可以提供指向新复制数据的指针，以防您需要在事后修改或引用它。

重构以使用 V8 的内存分配器有点复杂，因为它需要修改 create_external_resource 函数以使用 V8 分配的内存，而不是使用 malloc。 这在您是否控制 create_external_resource 的定义取决于您。 想法是首先使用 V8 创建缓冲区，例如使用 napi_create_buffer，然后将资源初始化到 V8 分配的内存中。 重要的是要保留对 资源生命周期 的 napi_ref 到 Buffer 对象，否则 V8 可能会垃圾回收 Buffer 并可能导致使用已释放内存的错误。

Electron 正在更改其主要的 S3 存储桶，您可能需要更新您的构建脚本

发生了什么？

Electron 的大量构建产物被上传到一个名为 gh-contractor-zcbenz 的 S3 存储桶。作为自 2020 年开始的持续的基础设施/所有权迁移的一部分，我们将把所有使用 gh-contractor-zcbenz 的内容从 S3 中的旧位置迁移到一个托管在 https://artifacts.electronjs.org 的新存储系统中。我们大多数资源使用的路径前缀也会略有改变。下方包含示例

之前： https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/dist/v17.0.0/node.lib 之后： https://artifacts.electronjs.org/headers/dist/v17.0.0/node.lib

这里重要的是 **主机名** 发生了变化，并且 /atom-shell **前缀** 也发生了变化。另一个例子，这次是关于调试符号

之前： https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/symbols/path/to/symbol.pdb 之后： https://artifacts.electronjs.org/symbols/path/to/symbol.pdb

同样，主机名发生了变化，并且 /atom-shell 前缀也被更改了。

这可能会如何影响您？

任何使用标准构建工具（如 electron-rebuild、electron-packager 或 @electron/get）的人都不需要做任何事情。这应该占大多数人。

对于任何直接引用 S3 存储桶的人，您必须更新您的引用，使其指向新的主机名并更新路径。

现有的数据怎么样？

gh-contractor-zcbenz 存储桶中的大部分数据已被克隆到新的存储系统中。 这意味着所有调试符号和所有头文件都已复制。 如果您依赖于该存储桶中尚未复制的一些数据，请在 electron/electron 中提出 issue，并告知我们。

当前的 gh-contractor-zcbenz S3 存储桶不会被主动删除。但是，我们不能保证该存储桶将保留多长时间。我们 **强烈** 建议尽快更新以指向新的存储桶。

Electron 项目将在 2021 年 12 月暂停一个月，然后在 2022 年 1 月恢复全速运行。

来自 GIPHY

12 月会保持不变​

1. 零日和其他重大安全相关发布将根据需要发布。 应该通过 SECURITY.md 报告安全事件。
2. 行为准则 报告和审核将继续进行。

12 月会发生变化​

1. 12 月份不会发布新的 Beta 或 Stable 版本。12 月的最后两周不会发布 Nightly 版本。
2. 除少数例外情况外，不会进行 Pull Request 的审查或合并。
3. 任何代码仓库的 Issue Tracker 都不会有更新。
4. 维护者不会在 Discord 上提供调试帮助。
5. 社交媒体内容将暂停更新。

为什么会发生这种情况？​

简而言之，虽然维护者对项目感到满意并积极参与，但世界已经厌倦了。十二月是大多数公司的一个平静的月份，所以我们希望给我们的维护者一个休息的机会。我们鼓励其他项目考虑类似的措施。

我应该担心 Electron 的未来吗？​

不用担心。我们之所以能采取这一步，是因为项目正处于良好状态。大家都对 2022 年充满期待，我们预计会有美好的事情发生！