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

遵循 Chromium 的弃用策略，Electron 将在 Electron 23 中停止支持 Windows 7、Windows 8 和 Windows 8.1。这与 Microsoft 在 2023 年 1 月 10 日结束对 Windows 7 ESU 和 Windows 8.1 扩展支持 的计划一致。

Electron 22 将是最后一个支持 10 版本以下 Windows 版本的 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，而 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 Forge v6.0.0 现已发布！这是 Forge 自 2018 年以来的第一个主要版本，并将项目从 electron-userland 迁移到 Github 上的主要 electron 组织。

请继续阅读，了解有哪些新功能以及您的应用程序如何采用 Electron Forge！

什么是 Electron Forge？​

Electron Forge 是一个用于打包和分发 Electron 应用程序的工具。它将 Electron 的构建工具生态系统统一到一个可扩展的接口中，让任何人都可以直接上手制作 Electron 应用程序。

主要功能包括

• 📦 应用程序打包和代码签名
• 🚚 在 Windows、macOS 和 Linux 上的可定制安装程序（DMG、deb、MSI、PKG、AppX 等）
• ☁️ 针对云提供商（GitHub、S3、Bitbucket 等）的自动化发布流程
• ⚡️ 易于使用的 webpack 和 TypeScript 模板
• ⚙️ 支持原生 Node.js 模块
• 🔌 可扩展的 JavaScript 插件 API

v6 有哪些新功能？​

完全重写​

从 v1 到 v5，Electron Forge 都基于现已停止维护的 electron-compile 项目。Forge 6 是该项目的完全重写，采用了新的模块化架构，可以扩展以满足任何 Electron 应用程序的需求。

在过去几年中，Forge v6.0.0-beta 已经实现了与 v5 的功能对等，并且代码变动已大幅减缓，使得该工具已准备好被广泛采用。

官方支持​

过去，Electron 的维护者对构建工具没有明确的立场，将这项任务留给了各种社区软件包。然而，随着 Electron 项目的成熟，新的 Electron 开发者越来越难以理解他们需要哪些工具来构建和分发他们的应用程序。

为了帮助 Electron 开发者在分发过程中得到指导，我们决定将 Forge 作为 Electron 官方的、功能完备的构建流程。

在过去一年中，我们一直在将 Forge 逐步整合到官方 Electron 文档中，并且最近已将 Forge 从其旧地址 electron-userland/electron-forge 迁移到 electron/forge 仓库。现在，我们终于准备好向公众发布 Electron Forge 了！

入门​

初始化一个新的 Forge 项目​

可以使用 create-electron-app CLI 脚本来搭建一个新的 Electron Forge 项目。

yarn create electron-app my-app --template=webpack
cd my-app
yarn start

npm init electron-app@latest my-app -- --template=webpack
cd my-app
npm start

该脚本将在 my-app 文件夹中创建一个 Electron 项目，其中包含完整的 JavaScript 打包和预配置的构建流程。

更多信息，请参阅 Forge 文档中的入门指南。

导入现有项目​

Electron Forge CLI 还包含一个用于现有 Electron 项目的导入命令。

cd my-app
yarn add --dev @electron-forge/cli
yarn electron-forge import

cd my-app
npm install --save-dev @electron-forge/cli
npm exec --package=@electron-forge/cli -c "electron-forge import"

当你使用 import 命令时，Electron Forge 将添加一些核心依赖项并创建一个新的 forge.config.js 配置。如果你有任何现有的构建工具（例如 Electron Packager、Electron Builder 或 Forge 5），它将尝试尽可能多地迁移设置。你的一些现有配置可能需要手动迁移。

手动迁移的详细信息可以在 Forge 的 导入文档 中找到。如果你需要帮助，请访问 我们的 Discord 服务器！

为什么要切换到 Forge？​

如果您已经有用于打包和发布 Electron 应用程序的工具，采用 Electron Forge 所带来的好处仍然可能超过初始的转换成本。

我们认为使用 Forge 有两大好处

1. Forge 在 Electron 支持新功能后，会立即获得这些功能以用于应用程序构建。在这种情况下，你无需自己连接新的工具支持，也无需等待其他软件包最终实现该支持后再升级。最近的示例包括 macOS 通用二进制文件 和 ASAR 完整性检查。

2. Forge 的多软件包架构使其易于理解和扩展。由于 Forge 由许多职责明确的小型软件包组成，因此更容易理解代码流程。此外，Forge 的可扩展 API 设计意味着你可以编写自己的附加构建逻辑，与提供的配置选项分开，以用于高级用例。有关编写自定义 Forge 插件、创建器和发布器的更多详细信息，请参阅文档的 扩展 Electron Forge 部分。

破坏性变更​

Forge 6 已经经历了很长的测试阶段，其发布节奏也逐渐放缓。然而，我们在 2022 年下半年加快了开发速度，并利用最后几个版本推出了 v6.0.0 稳定版之前的一些最终破坏性更改。

如果你是 Electron Forge 6 Beta 用户，请参阅 v6.0.0 GitHub 发布说明，了解最近 Beta 版（>=6.0.0-beta.65）中进行的破坏性更改列表。

完整的更改和提交列表可以在仓库的 CHANGELOG.md 中找到。

提交您的反馈！​

告诉我们您的需求！Electron Forge 团队一直致力于改进项目，以更好地满足用户的需求。

你可以通过提交功能请求、发布 问题，或者只是告诉我们你的反馈来帮助我们改进 Electron Forge！你还可以加入 官方 Electron Discord 服务器，其中有一个专门用于 Electron Forge 讨论的频道。

如果你想对 https://electronforge.cn 上的 Forge 文档提供任何反馈，我们有一个 GitBook 实例，它已同步到 electron-forge/electron-forge-docs 仓库。

上个月，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 进行可滚动 Web 内容​

我们 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.0.0 已发布！ 它包括升级到 Chromium 106、V8 10.6 和 Node.js 16.16.0。 阅读下文了解更多详情！

Electron 团队很高兴地宣布发布 Electron 21.0.0！您可以通过 npm install electron@latest 命令使用 npm 安装它，或者从我们的发布网站下载。请继续阅读以了解此版本的详细信息。

如果您有任何反馈，请在 Twitter 上与我们分享，或加入我们的社区 Discord！Bug 和功能请求可以在 Electron 的问题跟踪器中报告。

重要变更​

技术栈变更​

• Chromium 106
  • Chrome 106 中的新功能
  • Chrome 105 中的新功能
  • DevTools 106 中的新功能
  • DevTools 105 中的新功能
• Node.js 16.16.0
  • Node 16.16.0 博客文章
• V8 10.6

新特性​

• 添加了 webFrameMain.origin。#35534
• 添加了新的 WebContents.ipc 和 WebFrameMain.ipc API。#35231
• 添加了对面板式行为的支持。 窗口可以浮动在全屏应用程序之上。#34388
• 添加了对 macOS 应用程序来自 APNs 的推送通知的支持。#33574

破坏性与 API 变更​

以下是 Electron 21 中引入的重大变更。

V8 内存笼已启用​

Electron 21 启用了V8 沙箱指针，遵循 Chrome 在Chrome 103 中做出相同决定的做法。这会对原生模块产生一些影响。此功能具有性能和安全优势，但同时也对原生模块施加了一些新的限制，例如使用指向外部（“堆外”）内存的 ArrayBuffers。请参阅这篇博文了解更多信息。#34724

重构了 webContents.printToPDF​

重构了 webContents.printToPDF 以与 Chromium 的无头实现保持一致。 有关更多信息，请参阅#33654。

有关这些和未来更改的更多信息，请访问计划中的重大更改页面。

停止支持 18.x.y​

根据项目的支持策略，Electron 18.x.y 已停止支持。鼓励开发者和应用程序升级到更新版本的 Electron。

下一步计划​

短期内，您可以预期团队将继续专注于跟进构成 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。

您可以在此处找到 Electron 的公开时间线。

有关未来变更的更多信息，请参阅计划中的破坏性变更页面。

Electron 20.0.0 现已发布！此版本升级到了 Chromium 104、V8 10.4 和 Node.js 16.15.0。请阅读下文了解更多详情！

Electron 团队很高兴地宣布 Electron 20.0.0 的发布！您可以通过 npm install electron@latest 使用 npm 进行安装，或从我们的 发布网站 下载。请继续阅读以了解此版本详情，并请分享您的任何反馈！

重要变更​

新特性​

• 在 Windows 上增加了沉浸式暗黑模式。#34549
• 增加了对类似面板行为的支持。窗口可以浮动在全屏应用程序之上。#34665
• 更新了 Windows 控件覆盖按钮，使其在 Windows 11 上的外观和感觉更原生。#34888
• 除非指定了 nodeIntegration: true 或 sandbox: false，否则渲染器现在默认是沙盒化的。#35125
• 在使用 nan 构建原生模块时增加了安全保障。#35160

技术栈变更​

• Chromium 104
  • Chrome 104 新特性
  • Chrome 103 新特性
  • DevTools 新特性
• Node.js 16.15.0
  • Node 16.15.0 博客文章
• V8 10.4

破坏性与 API 变更​

以下是 Electron 20 中引入的破坏性变更。有关这些变更及未来变更的更多信息，请参阅 计划中的破坏性变更 页面。

默认更改：没有 nodeIntegration: true 的渲染器默认已沙盒化​

以前，指定了预加载脚本的渲染器默认未沙盒化。这意味着默认情况下，预加载脚本可以访问 Node.js。在 Electron 20 中，此默认设置已更改。从 Electron 20 开始，除非指定了 nodeIntegration: true 或 sandbox: false，否则渲染器默认将已沙盒化。

如果您的预加载脚本不依赖于 Node，则无需任何操作。如果您的预加载脚本确实依赖于 Node，那么要么重构它们以从渲染器中移除 Node 的使用，要么为相关渲染器明确指定 sandbox: false。

已修复：nan 原生模块中的自发崩溃​

在 Electron 20 中，我们更改了两个与原生模块相关的项目：

1. V8 头文件现在默认使用 c++17。这个标志已添加到 electron-rebuild 中。
2. 我们修复了一个问题，即一个缺失的 include 会导致依赖 nan 的原生模块发生自发性崩溃。

为获得最佳稳定性，我们建议在重新构建原生模块（尤其是依赖 nan 的模块）时使用 node-gyp >=8.4.0 和 electron-rebuild >=3.2.9。有关更多信息，请参阅 electron #35160 和 node-gyp #2497。

已移除：Linux 上的 .skipTaskbar​

在 X11 上，skipTaskbar 会向 X11 窗口管理器发送一个 _NET_WM_STATE_SKIP_TASKBAR 消息。Wayland 没有直接的等效项，并且已知的解决方法存在不可接受的权衡（例如，GNOME 中的 Window.is_skip_taskbar 需要不安全模式），因此 Electron 无法在 Linux 上支持此功能。

终止对 17.x.y 的支持​

根据项目的 支持策略，Electron 17.x.y 已停止支持。我们鼓励开发者和应用程序升级到更新版本的 Electron。

下一步计划​

短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。 尽管我们谨慎地不承诺发布日期，但我们的计划是大约每 2 个月发布包含这些组件新版本的新 Electron 主要版本。

您可以在此处找到 Electron 的公开时间线。

有关未来变更的更多信息，请参阅计划中的破坏性变更页面。

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

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

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

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

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

Electron 升级工作组 认为指针压缩和 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 分配的内存中。重要的是要为 资源的生命周期 保留对 Buffer 对象的 napi_ref，否则 V8 可能会垃圾回收 Buffer，并可能导致 use-after-free 错误。

Electron 19.0.0 现已发布！ 它包含了对 Chromium 102、V8 10.2 和 Node.js 16.14.2 的升级。 请继续阅读以获取更多细节！

Electron 团队很高兴地宣布 Electron 19.0.0 发布！ 您可以通过 npm 使用 npm install electron@latest 进行安装，或从我们的发布网站下载。 请继续阅读此版本的详细信息，并分享您的任何反馈！

重要变更​

Electron 发布节奏变更​

项目正在恢复其早期支持最新三个主要版本的策略。请参阅我们的版本控制文档，了解有关 Electron 版本控制和支持的更详细信息。 这曾暂时是四个主要版本，以帮助用户适应从 Electron 15 开始的新发布节奏。 您可以在此处阅读完整详细信息。

技术栈变更​

• Chromium 102
  • Chrome 102 的新特性
  • Chrome 101 的新特性
• Node.js 16.14.2
  • Node 16.14.2 博客文章
• V8 10.2

破坏性与 API 变更​

以下是 Electron 19 中引入的重大变更。有关这些变更和未来变更的更多信息，请参阅计划的重大变更页面。

在 Linux 上不再支持：.skipTaskbar​

BrowserWindow 构造函数选项 skipTaskbar 在 Linux 上已不再支持。 变更于 #33226

移除了 WebPreferences.preloadURL​

半文档化的 preloadURL 属性已从 WebPreferences 中移除。#33228。 应改用 WebPreferences.preload。

停止对 15.x.y 和 16.x.y 的支持​

Electron 14.x.y 和 15.x.y 都已达到支持结束。这使 Electron 恢复其现有策略，即支持最新的三个主要版本。 鼓励开发人员和应用程序升级到更新的 Electron 版本。

下一步计划​

短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。 尽管我们谨慎地不承诺发布日期，但我们的计划是大约每 2 个月发布包含这些组件新版本的新 Electron 主要版本。

您可以在此处找到 Electron 的公开时间线。

有关未来变更的更多信息，请参阅计划中的破坏性变更页面。

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 18.0.0 已发布！它包含了对 Chromium 100、V8 10.0 和 Node.js 16.13.2 的升级。请阅读下文了解更多详情！

Electron 团队很高兴地宣布 Electron 18.0.0 的发布！您可以通过 npm install electron@latest 使用 npm 安装它，或者从我们的 发布网站 下载。请继续阅读以了解此版本详情，并请随时分享您的反馈！

重要变更​

Electron 发布节奏变更​

从 Electron 15 开始，Electron 将每 8 周发布一个新的主要稳定版本。您可以在此处阅读完整详情。

此外，在 2022 年 5 月之前，Electron 的支持版本已从最新的三个版本更改为最新的四个版本。请参阅我们的版本控制文档，了解有关 Electron 中版本控制的更详细信息。2022 年 5 月之后，我们将恢复支持最新的三个版本。

技术栈变更​

• Chromium 100
  • Chrome 100 的新特性
• Node.js 16.13.2
  • Node 16.13.2 博客文章
• V8 10.0

亮点功能​

• 添加了 ses.setCodeCachePath() API 用于设置代码缓存目录。#33286
• 移除了 window.open 基于旧 BrowserWindowProxy 的实现。这也移除了 webPreferences 中的 nativeWindowOpen 选项。 #29405
• 为 WebContents 添加了 'focus' 和 'blur' 事件。#25873
• 在 macOS 上增加了替换菜单角色：showSubstitutions、toggleSmartQuotes、toggleSmartDashes、toggleTextReplacement。 #32024
• 在 app.requestSingleInstanceLock() 流程中增加了 first-instance-ack 事件，允许用户将数据从第一个实例无缝传输到第二个实例。 #31460
• 在 setBackgroundColor 中增加了对更多颜色格式的支持。#33364

有关新功能和更改的完整列表，请参阅 18.0.0 发行说明。

破坏性与 API 变更​

以下是 Electron 18 中引入的重大更改。有关这些更改和未来更改的更多信息，请访问 计划中的重大更改 页面。

已移除：nativeWindowOpen​

在 Electron 15 之前，window.open 默认使用 BrowserWindowProxy 进行模拟。这意味着 window.open('about:blank') 无法打开可同步脚本编写的子窗口，以及其他不兼容之处。自 Electron 15 起，nativeWindowOpen 已默认启用。

有关 window.open 的更多详细信息，请参阅 Electron 中 window.open 的文档。在 #29405 中移除。

终止对 14.x.y 的支持​

根据项目的支持策略，Electron 14.x.y 已结束支持。我们鼓励开发者和应用程序升级到更新版本的 Electron。

自 Electron 15 起，在 Electron 19 之前，我们已将支持版本从最新的三个版本更改为最新的四个版本，直到 2022 年 5 月。在 Electron 19 之后，我们将恢复支持最新的三个版本。此次版本支持的更改是我们新的发布周期更改的一部分。请在此处查看我们的博客文章以获取完整详细信息。

下一步计划​

短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。 尽管我们谨慎地不承诺发布日期，但我们的计划是大约每 2 个月发布包含这些组件新版本的新 Electron 主要版本。

您可以在此处找到 Electron 的公开时间线。

有关未来变更的更多信息，请参阅计划中的破坏性变更页面。