Electron 7.0.0 已发布！ 此版本中包含了对 Chromium 78、V8 7.8 和 Node.js 12.8.1 的升级。 我们增加了适用于 Arm 64 的 Windows 版本，更快的 IPC 方法，一个新的 `nativeTheme` API，以及更多！

Electron 团队很高兴地宣布 Electron 7.0.0 的发布！您可以通过 npm install electron@latest 使用 npm 进行安装，或者从我们的 发布网站 下载。此版本包含大量升级、修复和新功能。我们迫不及待地想看到您用它们构建出什么！请继续阅读以获取有关此版本的详细信息，并请分享您的任何反馈！

重要变更​

• 技术栈升级

  技术栈	Electron 6 中的版本	Electron 7 中的版本	新功能
  Chromium	76.0.3809.146	78.0.3905.1	77, 78
  V8	7.6	7.8	7.7, 7.8
  Node.js	12.4.0	12.8.1	12.5, 12.6, 12.7, 12.8, 12.8.1

• 添加了对 ARM (64 位) Windows 的发布支持。#18591，#20112

• 添加了 ipcRenderer.invoke() 和 ipcMain.handle()，用于异步请求/响应式 IPC。强烈建议使用它们，而不是 remote 模块。有关更多信息，请参阅这篇 "Electron 的‘remote’模块被认为是有害的" 博客文章。#18449

• 添加了 nativeTheme API，用于读取和响应操作系统主题和颜色方案的变化。#19758，#20486

• 切换到了新的 TypeScript 定义 生成器。生成的定义更加精确；因此，如果您的 TypeScript 构建失败，这很可能是原因。 #18103

请参阅 7.0.0 版本说明获取更完整的更新列表。

破坏性变更​

关于这些以及未来变更的更多信息，可以在计划中的重大变更页面找到。

• 已移除废弃的 API
  • 现在使用 Promise 的函数的基于回调的版本。 #17907
  • Tray.setHighlightMode() (macOS)。 #18981
  • app.enableMixedSandbox() #17894
  • app.getApplicationMenu(),
  • app.setApplicationMenu(),
  • powerMonitor.querySystemIdleState(),
  • powerMonitor.querySystemIdleTime(),
  • webFrame.setIsolatedWorldContentSecurityPolicy(),
  • webFrame.setIsolatedWorldHumanReadableName(),
  • webFrame.setIsolatedWorldSecurityOrigin() #18159
• Session.clearAuthCache() 不再允许筛选要清除的缓存条目。 #17970
• macOS 上的原生界面（菜单、对话框等）现在会自动匹配用户机器上的暗黑模式设置。 #19226
• 更新了 `electron` 模块以使用 `@electron/get`。 最低支持的 Node 版本现在是 Node 8。 #18413
• 文件 `electron.asar` 已不存在。 任何依赖于其存在的打包脚本都应进行更新。 #18577

结束对 4.x.y 的支持​

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

应用反馈计划​

我们继续使用我们的 应用反馈计划 进行测试。参与此计划的项目会在其应用程序上测试 Electron 的 beta 版本；作为回报，他们发现的新 bug 将会优先修复并包含在稳定版发布中。如果您想参与或了解更多信息，请查看我们关于该计划的博客文章。

下一步计划​

短期内，您可以期待该团队继续专注于跟进 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。尽管我们努力避免对发布日期做出承诺，但我们的计划是大约每季度发布一次包含这些组件新版本的新版 Electron。 暂定的 8.0.0 时间表 概述了 Electron 8 开发生命周期中的关键日期。此外，请参阅我们的版本文档，了解有关 Electron 版本管理的更详细信息。

有关 Electron 未来版本中计划的重大变更信息，请参阅我们的“计划中的重大变更”文档。

Electron 团队很高兴地宣布 Electron 6.0.0 的发布！您可以通过 npm install electron@latest 使用 npm 进行安装，或者从我们的 发布网站 下载。此版本包含大量升级、修复和新功能。我们迫不及待地想看到您用它们构建出什么！请继续阅读以获取有关此版本的详细信息，并请分享您的任何反馈！

新增内容​

今天标志着 Electron 项目的一个里程碑：这是我们第一次在与相应的 Chrome 稳定版发布的同一天发布稳定版 Electron！🎉

Electron 的大部分功能由 Chromium、Node.js 和 V8 的核心组件提供。Electron 会与这些项目保持同步，以便为用户提供新的 JavaScript 功能、性能改进和安全修复。这些软件包中的每一个在 Electron 6 中都有一个主版本号的更新。

• Chromium 76.0.3809.88
  • 74 版本新增
  • 75 版本新增
  • 76 版本新增
• Node.js 12.4.0
  • Node 12.4.0 博客文章
• V8 7.6.303.22
  • V8 7.6 博客文章

本次发布还包括对 Electron API 的改进。发布说明中有更完整的列表，但以下是亮点：

Promises 化​

Electron 6.0 继续了 5.0 版本开始的 现代化 计划，以改进 Promise 支持。

这些函数现在返回 Promises，并且仍然支持旧的基于回调的调用方式。

• contentTracing.getCategories() #16583
• contentTracing.getCategories() #16583
• contentTracing.getTraceBufferUsage() #16600
• contents.executeJavaScript() #17312
• cookies.flushStore() #16464
• cookies.get() #16464
• cookies.remove() #16464
• cookies.set() #16464
• dialog.showCertificateTrustDialog() #17181
• inAppPurchase.getProducts() #17355
• inAppPurchase.purchaseProduct()#17355
• netLog.stopLogging() #16862
• session.clearAuthCache() #17259
• session.clearCache() #17185
• session.clearHostResolverCache() #17229
• session.clearStorageData() #17249
• session.getBlobData() #17303
• session.getCacheSize() #17185
• session.resolveProxy() #17222
• session.setProxy() #17222
• webContents.hasServiceWorker() #16535
• webContents.printToPDF() #16795
• webContents.savePage() #16742
• webFrame.executeJavaScript() #17312
• webFrame.executeJavaScriptInIsolatedWorld() #17312
• webviewTag.executeJavaScript() #17312

这些函数现在有两种形式：同步和基于 Promise 的异步。

• dialog.showMessageBox()/dialog.showMessageBoxSync() #17298
• dialog.showOpenDialog()/dialog.showOpenDialogSync() #16973
• dialog.showSaveDialog()/dialog.showSaveDialogSync() #17054

这些函数现在返回 Promises。

• app.dock.show() #16904

Electron Helper (Renderer).app、Electron Helper (GPU).app 和 Electron Helper (Plugin).app​

为了启用 硬化运行时（它会限制可写可执行内存和加载由不同 Team ID 签名的代码等），必须授予 Helper 特殊的代码签名权限。

为了将这些权限范围限定在需要它们的过程中，Chromium 添加了 三个新的 Helper 应用程序变体：一个用于渲染器（Electron Helper (Renderer).app），一个用于 GPU 进程（Electron Helper (GPU).app），以及一个用于插件（Electron Helper (Plugin).app）。

使用 electron-osx-sign 为其 Electron 应用程序进行代码签名的开发者应该不需要对其构建逻辑进行任何更改。如果您使用自定义脚本对您的应用程序进行代码签名，则应确保这三个新的 Helper 应用程序已正确进行代码签名。

为了正确打包您的应用程序以及这些新的 Helper，您需要使用 electron-packager@14.0.4 或更高版本。如果您正在使用 electron-builder，您应该关注 此问题 以跟踪对这些新 Helper 的支持。

破坏性变更​

• 此版本开始为未来在渲染进程中加载的原生 Node 模块必须是 N-API 或 上下文感知 的要求奠定基础。此更改的原因是更高的性能、更强的安全性以及减少的维护工作量。请阅读 此问题 中的详细信息，包括拟议的时间表。此更改预计将在 Electron v11 中完成。

• net.IncomingMessage 头的 结构略有改变，以更密切地匹配 Node.js 的行为，特别是 set-cookie 的值以及重复头的处理方式。#17517。

• shell.showItemInFolder() 现在返回 void 并且是一个异步调用。#17121

• 应用程序现在必须在使用 app.getPath('log') 之前，通过调用新的函数 app.setAppLogPath() 来显式设置日志路径。#17841

3.x.y 版本停止支持​

根据我们的 支持政策，3.x.y 已达到生命周期终点。鼓励开发者和应用程序升级到更新版本的 Electron。

应用反馈计划​

我们继续使用我们的 应用反馈计划 进行测试。参与此计划的项目会在其应用程序上测试 Electron 的 beta 版本；作为回报，他们发现的新 bug 将会优先修复并包含在稳定版发布中。如果您想参与或了解更多信息，请查看我们关于该计划的博客文章。

下一步计划​

短期内，您可以期待该团队继续专注于跟进 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。尽管我们努力避免对发布日期做出承诺，但我们的计划是大约每季度发布一次包含这些组件新版本的新版 Electron。 暂定的 7.0.0 时间表 概述了 Electron 7 开发生命周期中的关键日期。此外，请参阅我们的版本文档，了解有关 Electron 版本管理的更详细信息。

有关 Electron 未来版本中计划的重大变更信息，请参阅我们的“计划中的重大变更”文档。

🎉 Electron 将转为每 12 周发布一个新的主稳定版本！🎉

⚡️ 哇，好快！但为什么呢？​

简而言之，Chromium 不会停止发布，所以 Electron 也不会放慢脚步。

Chromium 以稳定的 6 周 周期 发布。为了在 Electron 中提供最新版本的 Chromium，我们的发布周期需要与其保持一致。有关 Chromium 发布周期的更多信息，请在此处 找到。

🚀 为什么是每 12 周？​

每 6 周，就会发布一个新的 Chromium 版本，其中包含新功能、错误修复/安全修复以及 V8 的改进。Electron 用户一直强烈要求及时获得这些更改，因此我们调整了稳定版的发布日期，以匹配每隔一次的 Chromium 稳定版发布。首先，Electron v6.0.0 将包含 M76，并计划于 2019 年 7 月 30 日稳定发布，与 Chromium M76 是同一发布日。

🚧 这对我或我的 Electron 应用意味着什么？​

您将比以前更快地获得新的 Chromium 和 V8 的功能与修复。重要的是，您还将知道这些新变更何时到来，从而能够根据更准确的信息进行规划。

Electron 团队将 继续支持 最新的三个主要版本。例如，当 v6.0.0 于 2019 年 7 月 30 日稳定发布时，我们将支持 v6.x、v5.x 和 v4.x，而 v3.x 将达到生命周期终点。

💬 应用反馈计划​

请考虑加入我们的 应用反馈计划，以帮助我们测试 beta 版本和稳定化。参与此计划的项目会在其应用程序上测试 Electron 的 beta 版本；作为回报，他们发现的新 bug 将会优先修复并包含在稳定版发布中。

📝 Electron 发布简史​

v3.0.0 之前的稳定版本发布并未遵循计划。我们为 v3.0.0 和 v4.0.0 版本添加了内部计划。今年早些时候，我们决定首次公开 Electron v5.0.0 的稳定发布日期，请参阅 Electron v5.0.0 时间线。宣布稳定发布日期总体上受到好评，我们很高兴能在未来的版本中继续这样做。

为了更好地精简这些与升级相关的努力，我们在 治理体系内成立了 升级 和 发布 工作组。它们使我们能够更好地确定这些工作的优先级并委派工作，我们希望这将在后续的每个版本中更加明显。

以下是我们的新周期与 Chromium 周期的对比情况

📨 如果您有任何问题，请发送邮件至 info@electronjs.org。

Electron 团队很高兴地宣布 Electron 5.0.0 的发布！您可以通过 npm install electron@latest 使用 npm 进行安装，或从 我们的发布页面 下载 tarball。此版本包含大量升级、修复和新功能。我们迫不及待地想看到您用它们构建出什么！请继续阅读以获取有关此版本的详细信息，并请分享您的任何反馈！

有什么新内容？​

Electron 的大部分功能由 Chromium、Node.js 和 V8 的核心组件提供。Electron 会与这些项目保持同步，以便为用户提供新的 JavaScript 功能、性能改进和安全修复。这些软件包中的每一个在 Electron 5 中都有一个主版本号的更新。

• Chromium 73.0.3683.119
  • 70 版本中的新内容
  • 71 版本中的新内容
  • 72 版本中的新内容
  • 73 版本中的新内容
• Node.js 12.0.0
  • Node 12 博客文章
• V8 7.3.492.27。
  • 新的 JavaScript 功能

Electron 5 还包含对 Electron 特有 API 的改进。以下是主要变化的摘要；有关完整更改列表，请查看 Electron v5.0.0 发布说明。

Promises 化​

Electron 5 继续 Promisification initiative 计划，将 Electron 的基于回调的 API 转换为使用 Promises。这些 API 已在 Electron 5 中转换。

• app.getFileIcon
• contentTracing.getCategories
• contentTracing.startRecording
• contentTracing.stopRecording
• debugger.sendCommand
• Cookies API
• shell.openExternal
• webContents.loadFile
• webContents.loadURL
• webContents.zoomLevel
• webContents.zoomFactor
• win.capturePage

macOS 系统颜色访问​

以下函数已更改或添加到 systemPreferences 中，用于访问 macOS 系统的颜色：

• systemPreferences.getAccentColor
• systemPreferences.getColor
• systemPreferences.getSystemColor

进程内存信息​

已添加 process.getProcessMemoryInfo 函数，用于获取当前进程的内存使用情况统计信息。

远程 API 的附加过滤​

为了提高 remote API 的安全性，已添加新的远程事件，以便可以 过滤 remote.getBuiltin、remote.getCurrentWindow、remote.getCurrentWebContents 和 <webview>.getWebContents。

BrowserWindow 上的多个 BrowserViews​

BrowserWindow 现在支持在同一个 BrowserWindow 中管理多个 BrowserViews。

破坏性变更​

打包应用程序的默认设置​

打包应用程序现在将与默认应用程序的行为相同：将创建一个默认的应用程序菜单，除非应用程序已有菜单并且 window-all-closed 事件将被自动处理，除非应用程序已处理该事件。

混合沙箱​

混合沙箱模式现在默认启用。使用 sandbox: true 启动的渲染器现在将真正进行沙箱化，而以前只有在启用混合沙箱模式时才会进行沙箱化。

安全改进​

为了提高安全性，nodeIntegration 和 webviewTag 的默认值现在为 false。

拼写检查器现在是异步的​

SpellCheck API 已更改为提供 异步结果。

弃用​

以下 API 在 Electron 5.0.0 中已弃用，并计划在 6.0.0 中移除：

arm 和 arm64 的 Mksnapshot 二进制文件​

arm 和 arm64 的 mksnapshot 原生二进制文件已弃用，并将于 6.0.0 中移除。可以使用 x64 二进制文件为 arm 和 arm64 创建快照。

WebContents 上的 ServiceWorker API​

为准备移除，WebContents 上的 ServiceWorker API 已弃用。

• webContents.hasServiceWorker
• webContents.unregisterServiceWorker

自动模块与沙盒 WebContents​

为了提高安全性，以下模块通过 require 直接使用的行为已被弃用，在沙箱化的 WebContents 中需要通过 remote.require 来包含：

• electron.screen
• child_process
• fs
• os
• path

webFrame 隔离世界 API​

webFrame.setIsolatedWorldContentSecurityPolicy、webFrame.setIsolatedWorldHumanReadableName、webFrame.setIsolatedWorldSecurityOrigin 已弃用，改用 webFrame.setIsolatedWorldInfo。

混合沙箱​

enableMixedSandbox 和命令行开关 --enable-mixed-sandbox 仍然存在以兼容，但它们已被弃用且无效。

停止支持 2.0.x​

根据我们的 支持版本策略，2.0.x 已达到生命周期终点。

应用反馈计划​

我们继续使用我们的 应用反馈计划 进行测试。参与此计划的项目会在其应用程序上测试 Electron 的 beta 版本；作为回报，他们发现的新 bug 将会优先修复并包含在稳定版发布中。如果您想参与或了解更多信息，请查看我们关于该计划的博客文章。

下一步计划​

短期内，您可以期待该团队继续专注于跟进 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。尽管我们努力避免对发布日期做出承诺，但我们的计划是大约每季度发布一次包含这些组件新版本的新版 Electron。 暂定的 6.0.0 时间表 概述了 Electron 6 开发生命周期中的关键日期。此外，请参阅我们的版本文档，了解有关 Electron 版本管理的更详细信息。

有关 Electron 未来版本中计划的重大变更信息，请参阅我们的“计划中的重大变更”文档。

Electron 中用 C++ 或 Objective-C 编写的功能是如何被暴露给 JavaScript，从而可供最终用户使用的？

背景​

Electron 是一个 JavaScript 平台，其主要目的是降低开发人员构建健壮的桌面应用程序的门槛，而无需担心平台特定的实现。然而，Electron 本身的核心仍然需要在给定的系统语言中编写平台特定的功能。

实际上，Electron 会为你处理原生代码，这样你就可以专注于单一的 JavaScript API。

但这又是如何工作的呢？Electron 中用 C++ 或 Objective-C 编写的功能是如何被暴露给 JavaScript，从而可供最终用户使用的？

要追踪这个路径，让我们从 app 模块开始。

通过打开我们 lib/ 目录中的 app.ts 文件，您会发现靠近顶部的以下代码行：

const binding = process.electronBinding('app');

这行代码直接指向 Electron 将其 C++/Objective-C 模块绑定到 JavaScript 以供开发人员使用的机制。此函数由 ElectronBindings 类的头文件和 实现文件 创建。

process.electronBinding​

这些文件添加了 process.electronBinding 函数，其功能类似于 Node.js 的 process.binding。process.binding 是 Node.js require() 方法的一个低级实现，不同之处在于它允许用户 require 原生代码而不是其他用 JS 编写的代码。这个自定义的 process.electronBinding 函数赋予了从 Electron 加载原生代码的能力。

当一个顶层 JavaScript 模块（如 app）需要这个原生代码时，该原生代码的状态是如何确定的和设置的？方法是如何暴露给 JavaScript 的？属性呢？

native_mate​

目前，这个问题可以用 native_mate 来解答：它是 Chromium 的 gin 库 的一个分支，使得在 C++ 和 JavaScript 之间传递类型更加容易。

在 native_mate/native_mate 内部有一个 object_template_builder 的头文件和实现文件。这允许我们以原生代码的形式构建模块，其结构符合 JavaScript 开发者的预期。

mate::ObjectTemplateBuilder​

如果我们把每个 Electron 模块看作一个 object，那么就更容易理解为什么我们要使用 object_template_builder 来构造它们。这个类建立在 V8 公开的一个类之上，V8 是 Google 用 C++ 编写的高性能 JavaScript 和 WebAssembly 引擎。V8 实现 JavaScript (ECMAScript) 规范，因此它的原生功能实现可以直接与 JavaScript 中的实现相关联。例如，v8::ObjectTemplate 为我们提供了没有专用构造函数和原型的 JavaScript 对象。它使用 Object[.prototype]，在 JavaScript 中等同于 Object.create()。

为了在实践中看到这一点，请查看 app 模块的实现文件 atom_api_app.cc。在底部有以下内容：

mate::ObjectTemplateBuilder(isolate, prototype->PrototypeTemplate())
    .SetMethod("getGPUInfo", &App::GetGPUInfo)

在上面的行中，在 mate::ObjectTemplateBuilder 上调用了 .SetMethod。.SetMethod 可以在 ObjectTemplateBuilder 类的任何实例上调用，以在 JavaScript 的 Object 原型 上设置方法，语法如下：

.SetMethod("method_name", &function_to_bind)

这是 JavaScript 中等价于

function App{}
App.prototype.getGPUInfo = function () {
  // implementation here
}

这个类还包含用于在模块上设置属性的函数

.SetProperty("property_name", &getter_function_to_bind)

或

.SetProperty("property_name", &getter_function_to_bind, &setter_function_to_bind)

这些将反过来是 Object.defineProperty 的 JavaScript 实现

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
  get() {
    return _myProperty
  }
})

和

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
  get() {
    return _myProperty
  }
  set(newPropertyValue) {
    _myProperty = newPropertyValue
  }
})

可以创建由原型和属性组成的 JavaScript 对象，就像开发者期望的那样，并且可以更清晰地推理出在这个较低系统级别实现的功能和属性！

关于在哪里实现任何给定模块方法的决定本身是一个复杂且常常是非确定性的问题，我们将在未来的帖子中介绍。

随着 Electron 在桌面应用程序中的普及，开发它的人员也在不断增长：我们有更多全职维护者，他们来自不同的公司，生活在不同的时区，并且有不同的兴趣。我们正在引入一种治理结构，以便能够平稳地发展。

为什么会发生改变？​

Electron 项目中的人们在全球时区协调，与志愿者、全职维护者以及依赖 Electron 的多家公司合作。到目前为止，我们一直通过非正式的协调取得成功；但随着团队的壮大，我们发现这种方法无法扩展。我们也希望让新贡献者更容易在项目中找到一个归属感。

工作组​

Electron 的治理结构包含了负责项目不同部分的工作组。我们首先设立了七个小组：

• 社区与安全 (Community & Safety)：处理行为准则相关问题。
• 文档和工具：负责外部关注的工具（例如 Fiddle、Forge）和 Electron 文档。
• 外联 (Outreach)：帮助发展 Electron 社区。
• 发布 (Releases)：确保版本发布稳定且准时。
• 安全 (Security)：进行安全测试并响应安全问题。
• 升级 (Upgrades)：整合上游更新，例如新版本的 V8、Chromium 和 Node。
• 网站 (Website)：维护和改进 Electron 网站。

这些小组会相互协调，但它们各自有自己的会议安排和议程，以便独立地开展工作。有关这些小组的更多详细信息，请访问 治理仓库。

这会改变 Electron 项目的方向吗？​

这不应对 Electron 的方向产生任何直接影响。如果我们的策略成功，工作组将使新贡献者更容易找到他们感兴趣的主题，并通过将与日常工作无关的讨论转移到其他组来简化维护者的生活。如果发生这种情况，可能会通过让更多未受阻碍的人们协同工作来间接影响事物。

我可以在哪里了解更多信息？​

• 治理 仓库和 章程 包含有关新治理结构的信息。
• 每个工作组都有自己的页面：社区、文档和工具、外展、发布、安全、升级 和 网站。
• 您可以通过 打开一个 issue 或发送邮件至 info@electronjs.org 联系维护者。

Chromium 中发现了一个高危漏洞，该漏洞影响包括 Electron 在内的所有基于 Chromium 的软件。

此漏洞已被分配 CVE-2019-5786。您可以在 Chrome 博客文章 中阅读更多相关信息。

请注意，Chrome 已收到此漏洞在野外被利用的报告，因此强烈建议您尽快升级 Electron。

范围​

这会影响任何可能运行第三方或不受信任的 JavaScript 的 Electron 应用程序。

缓解措施​

受影响的应用应升级到已修复的 Electron 版本。

我们已发布新版本的 Electron，其中包含此漏洞的修复程序。

• 4.0.8
• 3.1.6
• 3.0.16
• 2.0.18

Electron 5 的最新测试版已跟随 Chromium 73，因此已得到修复。

• 5.0.0-beta.5

进一步信息​

此漏洞是由 Google 威胁分析小组的 Clement Lecigne 发现的，并报告给了 Chrome 团队。Chrome 博客文章 在此处。

要了解有关保护您的 Electron 应用安全的最佳实践，请参阅我们的安全教程。

如果您希望报告 Electron 的漏洞，请发送电子邮件至 security@electronjs.org。

Electron 团队将从 Electron v4.0 开始停止支持 32 位 Linux (ia32 / i386)。最后支持 32 位 Linux 安装的 Electron 版本是 Electron v3.1，它将收到支持版本直到 Electron v6 发布。对 64 位 Linux 和 armv7l 的支持将保持不变。

Electron 不再支持什么？​

您可能在您的电脑上见过“64 位”和“32 位”的标签，或者在下载软件时看到过这些选项。这个术语用于描述特定的计算机架构。20 世纪 90 年代和 21 世纪初制造的大多数计算机都基于 32 位架构的 CPU，而之后制造的大多数计算机都基于更新、更强大的 64 位架构。任天堂 64（懂了吧？）和 PlayStation 2 是首批广泛普及的消费设备，配备了新架构，2010 年之后销售的电脑几乎完全采用了 64 位处理器。因此，支持正在缩小：Google 于 2016 年 3 月停止发布 Chrome for 32-bit Linux，Canonical 于 2017 年停止提供 32 位桌面镜像，并在 Ubuntu 18.10 中完全放弃了对 32 位支持。Arch Linux、elementary OS 和其他主要的 Linux 发行版已经放弃了对老旧处理器架构的支持。

到目前为止，Electron 一直提供并支持可在旧 32 位架构上运行的构建。从 v4.0 版本开始，Electron 团队将不再为 32 位 Linux 提供二进制文件或支持。

Electron 一直是一个充满活力的开源项目，我们将继续支持并鼓励有兴趣为特定架构构建 Electron 的开发者。

这对开发者意味着什么？​

如果您目前不为 Linux 提供您应用程序的 32 位分发版，则无需采取任何操作。

发布 32 位 Linux Electron 应用程序的项目将需要决定如何进行。Electron 3 将支持 32 位 Linux，直到 Electron 6 发布，这为做出决策和计划提供了一些时间。直到。

这对用户意味着什么？​

如果您是 Linux 用户，不确定您当前是否运行的是 64 位系统，那么您很可能运行的是 64 位架构。要确保这一点，您可以在终端中运行 lscpu 或 uname -m 命令。任一命令都会显示您当前的架构。

如果您在 32 位处理器上使用 Linux，您可能已经遇到在操作系统上查找最近发布的软件的困难。Electron 团队与 Linux 社区中的其他重要成员一起，建议您升级到 64 位架构。

发现了一个代码漏洞，允许在子窗口中重新启用 Node。

使用 sandbox: true 或 nativeWindowOpen: true 和 nodeIntegration: false 打开 BrowserView 会导致一个 webContents，其中可以调用 window.open，新打开的子窗口将启用 nodeIntegration。此漏洞会影响所有受支持的 Electron 版本。

缓解措施​

我们发布了新的 Electron 版本，其中包含此漏洞的修复程序：2.0.17、3.0.15、3.1.3、4.0.4 和 5.0.0-beta.2。我们鼓励所有 Electron 开发者立即将其应用程序更新到最新的稳定版本。

如果出于某种原因无法升级 Electron 版本，可以通过禁用所有子 webContents 来缓解此问题。

view.webContents.on('-add-new-contents', (e) => e.preventDefault());

进一步信息​

此漏洞由 PalmerAL 发现并负责任地报告给 Electron 项目。

要了解有关保护您的 Electron 应用安全的最佳实践，请参阅我们的安全教程。

如果您希望报告 Electron 的漏洞，请发送电子邮件至 security@electronjs.org。

如果您在使用 Electron 5.0 的原生 Node.js 插件时遇到问题，那可能是因为该插件需要更新才能与最新版本的 V8 兼容。

告别 v8::Handle，迎接 v8::Local​

在 2014 年，V8 团队弃用了 v8::Handle，转而使用 v8::Local 作为局部句柄。Electron 5.0 包含一个 V8 版本，该版本最终彻底移除了 v8::Handle，仍然使用它的原生 Node.js 插件在与 Electron 5.0 一起使用之前需要更新。

所需的代码更改很小，但所有仍然使用 v8::Handle 的原生 Node 模块都将无法使用 Electron 5.0 进行构建，并且需要进行修改。好消息是，Node.js v12 也将包含此 V8 更改，因此任何使用 v8::Handle 的模块无论如何都需要更新才能与即将推出的 Node 版本一起使用。

我维护一个原生插件，我该如何提供帮助？​

如果您维护 Node.js 的原生插件，请确保将所有 v8::Handle 的出现替换为 v8::Local。前者只是后者的一个别名，因此无需对其他内容进行更改即可解决此特定问题。

您可能也有兴趣了解 N-API，它与 V8 分开维护，是 Node.js 本身的一部分，旨在使原生插件免受底层 JavaScript 引擎更改的影响。您可以在 Node.js 网站上的 N-API 文档 中找到更多信息。

救命！我在应用程序中使用了原生插件，但它无法正常工作！​

如果您在应用程序中使用了 Node.js 的原生插件，并且该原生插件由于此问题无法构建，请与插件作者联系，看看他们是否已发布新版本来修复此问题。如果没有，联系作者（或 打开一个 Pull Request！）可能是您最好的选择。