Electron 專案將於 2024 年 12 月暫停，然後於 2025 年 1 月恢復全速運作。

via GIPHY

十二月維持不變的事項​

1. 必要時將發布零日漏洞和其他重大安全性相關的版本。安全事件應透過 SECURITY.md 回報。
2. 行為準則報告和審核將會持續進行。

十二月將會改變的事項​

1. 2024 年最後的年度穩定分支版本，包括 Electron 31、32 和 33，將於 12 月 1 日那一週發布。十二月將不會有額外計畫的版本發布。
2. 十二月最後兩週將不會有 Nightly 和 Alpha 版本發布。
3. 除了少數例外，不會進行 pull request 審核或合併。
4. 任何儲存庫都不會更新 issue tracker。
5. 維護者不會在 Discord 上提供偵錯協助。
6. 不會更新社群媒體內容。

2025 年見！

Electron 專案將於 2023 年 12 月暫停，然後於 2024 年 1 月恢復全速運作。

via GIPHY

十二月維持不變的事項​

1. 必要時將發布零日漏洞和其他重大安全性相關的版本。安全事件應透過 SECURITY.md 回報。
2. 行為準則報告和審核將會持續進行。

十二月將會改變的事項​

1. Electron 28.0.0 將於 12 月 5 日發布。在 Electron 28 之後，十二月將不會有新的穩定版本發布。
2. 十二月最後兩週將不會有 Nightly 和 Alpha 版本發布。
3. 除了少數例外，不會進行 pull request 審核或合併。
4. 任何儲存庫都不會更新 issue tracker。
5. 維護者不會在 Discord 上提供偵錯協助。
6. 不會更新社群媒體內容。

展望未來​

這已是我們第三年進行靜默期實驗，到目前為止，我們在平衡一個月的休息時間與之後維持正常發行節奏方面取得了很大的成功。因此，我們已決定將其作為未來發行日曆的常規部分。我們仍會在每個日曆年的最後一個穩定版本中加入提醒。

2024 年見！

首次提交至 electron/electron 儲存庫是在 2013 年 3 月 13 日¹。

十年後，在 1192 位獨特貢獻者的 27,147 次提交後，Electron 已成為當今最受歡迎的桌面應用程式建構框架之一。這個里程碑是慶祝和反思我們迄今為止的旅程，並分享我們一路走來所學到的知識的絕佳機會。

如果沒有每一位投入時間和精力為專案做出貢獻的人，我們今天就不會在這裡。雖然原始碼提交始終是最顯著的貢獻，但我們也必須感謝那些回報錯誤、維護使用者領域模組、提供文件和翻譯以及參與網路空間中 Electron 社群的人們的努力。作為維護者，每一項貢獻對我們來說都是無價的。

在我們繼續進行部落格文章的其餘部分之前：謝謝您。❤️

我們是如何走到這裡的？​

Atom Shell 是作為 GitHub 的 Atom 編輯器的骨幹而建構的，該編輯器於 2014 年 4 月公開發布 Beta 版。它從頭開始建構，作為當時可用的基於網路的桌面框架（node-webkit 和 Chromium Embedded Framework）的替代方案。它有一個殺手級功能：嵌入 Node.js 和 Chromium，為網路技術提供強大的桌面執行環境。

在一年內，Atom Shell 的功能和受歡迎程度開始呈現巨大成長。大型公司、新創公司和個別開發人員都開始使用它建構應用程式（一些早期採用者包括 Slack、GitKraken 和 WebTorrent），並且該專案被恰如其分地更名為 Electron。

從那時起，Electron 便一帆風順，從未停止。這是我們隨時間推移的每週下載次數，由 npmtrends.com 提供

Electron v1 於 2016 年發布，承諾提高 API 穩定性，並提供更好的文件和工具。Electron v2 於 2018 年發布，並引入了語意化版本控制，使 Electron 開發人員更容易追蹤發行週期。

到 Electron v6 時，我們轉變為每 12 週定期發布主要版本，以配合 Chromium 的發行節奏。這個決定是專案心態的轉變，將「擁有最新版本的 Chromium」從錦上添花變為優先事項。這減少了升級之間技術債務的數量，使我們更容易保持 Electron 的更新和安全。

從那時起，我們就成了一部運轉良好的機器，在每個 Chromium 穩定版發布的同一天發布新的 Electron 版本。當 Chromium 在 2021 年將其發行時程加快至 4 週時，我們能夠聳聳肩，並相應地將我們的發行節奏提高到 8 週。

我們現在已發布 Electron v23（並且還在增加），並且仍然致力於為建構跨平台桌面應用程式建構最佳執行環境。即使近年來 JavaScript 開發人員工具蓬勃發展，Electron 仍然是桌面應用程式框架領域中穩定、經過實戰考驗的堅定支柱。如今，Electron 應用程式無處不在：您可以使用 Visual Studio Code 進行程式設計、使用 Figma 進行設計、使用 Slack 進行溝通，以及使用 Notion 進行筆記（以及許多其他用例）。我們為這項成就感到非常自豪，並感謝每一位使其成為可能的人。

我們一路走來學到了什麼？​

通往十年里程碑的道路漫長而曲折。以下是一些關鍵事項，這些事項幫助我們運營一個永續的大型開源專案。

使用治理模型擴展分散式決策制定​

我們必須克服的一個挑戰是，一旦 Electron 首次爆紅，如何處理專案的長期發展方向。我們如何處理成為一個由數十名工程師組成的團隊，這些工程師分佈在不同的公司、國家和時區？

在早期，Electron 的維護者群體依賴非正式協調，這對於較小的專案來說既快速又輕量，但無法擴展到更廣泛的協作。2019 年，我們轉向治理模型，其中不同的工作組有正式的責任領域。這對於簡化流程並將部分專案所有權分配給特定的維護者起到了關鍵作用。如今，每個工作組 (WG) 負責什麼？

• 發布 Electron 版本（發行工作組）
• 升級 Chromium 和 Node.js（升級工作組）
• 監督公共 API 設計（API 工作組）
• 確保 Electron 安全（安全工作組）
• 運行網站、文件和工具（生態系統工作組）
• 社群和企業外展（外展工作組）
• 社群審核（社群與安全工作組）
• 維護我們的建置基礎架構、維護者工具和雲端服務（基礎架構工作組）

大約在我們轉向治理模型的同時，我們也將 Electron 的所有權從 GitHub 轉移到 OpenJS 基金會。雖然最初的核心團隊今天仍在 Microsoft 工作，但他們只是組成 Electron 治理的更大協作者群體的一部分。²

雖然這種模型並不完美，但在全球疫情和持續的總體經濟逆風中，它非常適合我們。展望未來，我們計畫修改治理章程，以指導我們度過 Electron 的第二個十年。

社群​

開源的社群部分很困難，尤其是當您的外展團隊是由十幾位穿著風衣，上面寫著「社群經理」的工程師組成時。也就是說，作為一個大型開源專案，意味著我們有很多使用者，並且利用他們的能量為 Electron 建構使用者領域生態系統，是維持專案健康的關鍵部分。

我們一直在做些什麼來發展我們的社群影響力？

建構虛擬社群​

• 2020 年，我們啟用了我們的社群 Discord 伺服器。我們之前在 Atom 的論壇中設有一個版塊，但決定建立一個更非正式的訊息平台，為維護者和 Electron 開發人員之間的討論以及一般偵錯協助提供空間。
• 2021 年，在 @BlackHole1 的幫助下，我們成立了 Electron China 使用者群組。這個群組對於 Electron 在中國蓬勃發展的科技界使用者中的成長起到了關鍵作用，為他們提供了一個空間，讓他們可以在我們的英語空間之外協作想法和討論 Electron。我們還要感謝 cnpm 為支援 Electron 的每晚版本在其 npm 的中國鏡像中所做的工作。

參與高知名度的開源計畫​

• 自 2019 年以來，我們每年都在慶祝 Hacktoberfest。Hacktoberfest 是 DigitalOcean 每年組織的開源慶祝活動，每年我們都會收到數十位熱情的貢獻者，希望在開源軟體上留下他們的印記。
• 2020 年，我們參與了 Google 文件季的最初迭代，在那裡我們與 @bandantonio 合作修改了 Electron 的新使用者教學流程。
• 2022 年，我們首次指導了一位 Google 程式之夏的學生。@aryanshridhar 完成了一些很棒的工作，重構了 Electron Fiddle 的核心版本載入邏輯，並將其 bundler 遷移到 webpack。

自動化一切！​

今天，Electron 治理大約有 30 位活躍的維護者。我們中不到一半的人是全職貢獻者，這意味著有很多工作要做。我們保持一切順利運行的訣竅是什麼？我們的座右銘是電腦很便宜，而人類的時間很昂貴。以典型的工程師方式，我們開發了一套自動化支援工具，以使我們的生活更輕鬆。

非 Goma​

核心 Electron 程式碼庫是一個龐大的 C++ 程式碼，建置時間一直是限制我們發布錯誤修復和新功能速度的因素。2020 年，我們部署了 Not Goma，這是 Google 的 Goma 分散式編譯器服務的自訂 Electron 專用後端。Not Goma 處理來自授權使用者機器的編譯請求，並在後端將該過程分佈在數百個核心上。它還快取編譯結果，以便其他人編譯相同檔案時，只需下載預先編譯的結果即可。

自推出 Not Goma 以來，維護者的編譯時間已從數小時縮短到數分鐘。穩定的網路連線成為貢獻者編譯 Electron 的最低要求！

持續性雙重驗證​

持續性雙重驗證 (CFA) 是圍繞 npm 的雙重驗證 (2FA) 系統的一層自動化，我們將其與 semantic-release 結合使用，以管理我們各種 @electron/ npm 套件的安全和自動化發布。

雖然 semantic-release 已經自動化了 npm 套件發布流程，但它需要關閉雙重驗證或傳遞繞過此限制的秘密權杖。

我們建構 CFA 是為了為任意 CI 作業提供 npm 2FA 的基於時間的一次性密碼 (TOTP)，使我們能夠利用 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 標籤將修補程式 cherry-pick 到先前的發行分支，來自動化 Electron 的反向移植流程。
• Roller 自動化了 Electron 的 Chromium 和 Node.js 相依性的滾動升級。
• Cation 是我們用於 electron/electron PR 的狀態檢查機器人。

總而言之，我們的小型機器人家族為我們在開發人員生產力方面帶來了巨大的提升！

接下來是什麼？​

當我們作為一個專案進入第二個十年時，您可能會問：Electron 的下一步是什麼？

我們將與 Chromium 的發行節奏保持同步，每 8 週發布新的 Electron 主要版本，使框架與網路平台和 Node.js 的最新和最棒的功能保持同步，同時保持企業級應用程式的穩定性和安全性。

我們通常在即將推出的計畫變得具體時宣布相關消息。如果您想隨時掌握未來的發行版本、功能和一般專案更新，您可以閱讀 我們的部落格並關注我們的社群媒體個人資料（Twitter 和 Mastodon）！

從 Electron 23 開始，Electron 將終止對 Windows 7、Windows 8 和 Windows 8.1 的支援。

根據 Chromium 的棄用政策，從 Electron 23 開始，Electron 將終止對 Windows 7、Windows 8 和 Windows 8.1 的支援。這與 Microsoft 於 2023 年 1 月 10 日終止對 Windows 7 ESU 和 Windows 8.1 extended 的支援相符。

Electron 22 將是最後一個支援 10 之前 Windows 版本的 Electron 主要版本。Electron 23 及更高版本將不再支援 Windows 7/8/8.1。舊版本的 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 的 Electron 版本，將接受與 Windows 7/8/8.1 相關的新問題。
  • 任何較新的發行行都不會接受新問題。
• 一旦 Electron 22 達到其支援週期的終點，所有與 Windows 7/8/8.1 相關的現有問題都將被關閉。

接下來是什麼​

如果您有任何問題或疑慮，請隨時寫信給我們：info@electronjs.org。您也可以在我們的官方 Electron Discord 中找到社群支援。

Electron 專案將於 2022 年 12 月暫停，然後於 2023 年 1 月恢復全速運作。

via GIPHY

十二月維持不變的事項​

1. 必要時將發布零日漏洞和其他重大安全性相關的版本。安全事件應透過 SECURITY.md 回報。
2. 行為準則報告和審核將會持續進行。

十二月將會改變的事項​

1. 十二月沒有新的穩定版本發布。十二月最後兩週將不會有 Nightly 和 Alpha 版本發布。
2. 除了少數例外，不會進行 pull request 審核或合併。
3. 任何儲存庫都不會更新 issue tracker。
4. 維護者不會在 Discord 上提供偵錯協助。
5. 不會更新社群媒體內容。

為何會發生這種情況？​

鑑於 2021 年十二月靜默期的成功，我們希望在 2022 年再次舉辦。十二月仍然是大多數公司的靜默期，因此我們希望讓我們的維護者有機會充電。每個人都期待 2023 年，我們期待美好的事物即將到來！我們鼓勵其他專案考慮類似的措施。

上個月，Electron 的維護者群體在加拿大溫哥華聚會，討論 2023 年及以後專案的方向。在會議室的四天裡，核心維護者和受邀的協作者討論了新計畫、維護痛點和一般專案健康狀況。

展望未來，團隊仍將全心投入於發布定期且快速的 Chromium 升級、修復錯誤，並使 Electron 對每個人來說更安全、效能更高。我們還有一些令人興奮的專案正在進行中，我們很樂意與社群分享！

變革性的新 API​

Electron 專案中需要共識的主要 API 提案會經過徵求意見 (RFC) 流程，該流程由我們 API 工作組的成員審核。

今年，我們推進了兩項主要提案，這些提案有可能為 Electron 應用程式解鎖新的功能維度。這些提案具有高度實驗性，但以下是您對未來的期望的搶先看！

全新原生附加元件增強功能 (C API)​

此提案概述了新的 Electron C API 層，該層將允許應用程式開發人員編寫自己的原生 Node 附加元件，這些元件與 Electron 的內部資源介面連接，類似於 Node 自己的 Node-API。有關擬議的新 API 的更多資訊可以在此處找到。

範例：使用 Chromium 資源為應用程式增強功能​

許多 Electron 應用程式維護自己的分支，以便直接與 Chromium 內部構造互動，否則使用 vanilla（未修改）Electron 將無法存取。通過在 C API 層中公開這些資源，此程式碼可以作為原生模組與 Electron 並存，從而可能減輕應用程式開發人員的維護負擔。

公開 Chromium 的 UI 層（Views API）​

在底層，Chrome 使用者介面 (UI) 的非網站部分（例如工具列、標籤頁或按鈕）是使用名為 Views 的框架建構的。Views API 提案將此框架的部分作為 JavaScript 類別引入 Electron，最終目標是允許開發人員為其 Electron 應用程式建立非網路 UI 元素。這將防止應用程式必須拼湊網路內容。

使這組新 API 成為可能的基礎工作目前正在進行中。以下是您在不久的將來可以期待的一些首批事項。

範例：使用 WebContentsView 重構視窗模型​

我們計畫的第一個變更，是將 Chrome 的 WebContentsView 公開到 Electron 的 API 介面，這將會取代我們現有的 BrowserView API（雖然名稱如此，但它是 Electron 特有的程式碼，與 Chromium Views 無關）。透過公開 WebContentsView，我們將擁有一個可重複使用的 View 物件來顯示網頁內容，為將 BrowserWindow 類別變成純 JavaScript 並進一步消除程式碼複雜性開啟了大門。

儘管此變更沒有為應用程式開發人員提供許多新功能，但這是一個大型的重構，消除了底層的許多程式碼，簡化了 Chromium 升級，並降低了主要版本之間出現新錯誤的風險。

如果您是應用程式中使用了 BrowserView 的 Electron 開發人員：請別擔心，我們沒有忘記您！我們計畫將現有的 BrowserView 類別作為 WebContentsView 的墊片 (shim)，以便在您轉換到較新 API 時提供緩衝期。

請參閱：electron/electron#35658

範例：使用 ScrollView 的可捲動網頁內容​

我們在 Stack 的朋友們一直在推動將 Chromium ScrollView 元件公開到 Electron 的 API。有了這個新的 API，任何子 View 元件都可以水平或垂直捲動。

雖然這個新 API 僅實現了一個較小的功能，但團隊的最終目標是建立一套實用的 View 元件，可以作為工具包來建構更複雜的非 HTML 介面。

參與貢獻​

您是 Electron 應用程式開發人員，並且對這些 API 提案中的任何一個感興趣嗎？雖然我們尚未完全準備好接收額外的 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 記憶體隔離區 (Memory Cage)，這對某些原生模組產生影響。

在 Electron 21 中，我們將在 Electron 中啟用 V8 沙箱指標 (sandboxed pointers)，遵循 Chrome 在 Chrome 103 中也這樣做的決定。這對原生模組有一些影響。此外，我們先前在 Electron 14 中啟用了一項相關技術，指標壓縮 (pointer compression)。當時我們沒有太多討論它，但指標壓縮對 V8 堆積 (heap) 的最大大小有影響。

當啟用這兩項技術時，它們對於安全性、效能和記憶體使用量都非常有利。但是，啟用它們也有一些缺點。

啟用沙箱指標的主要缺點是，不再允許指向外部（「堆積外」）記憶體的 ArrayBuffer。這表示依賴 V8 中此功能的原生模組將需要重構，才能繼續在 Electron 20 及更高版本中運作。

啟用指標壓縮的主要缺點是，V8 堆積的最大大小限制為 4GB。確切的細節有點複雜 — 例如，ArrayBuffer 與 V8 堆積的其餘部分分開計算，但有其 自身的限制。

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 將允許在 Web 和 Electron 上使用 WebAssembly 建構的應用程式使用遠遠超過 4GB 的記憶體。

常見問題解答 (FAQ)​

我如何知道我的應用程式是否受到此變更的影響？​

在 Electron 20+ 中，嘗試使用 ArrayBuffer 包裝外部記憶體將在執行時崩潰。

如果您在應用程式中沒有使用任何原生 Node 模組，那麼您是安全的 — 無法從純 JS 觸發此崩潰。此變更僅影響分配 V8 堆積外部記憶體（例如使用 malloc 或 new），然後使用 ArrayBuffer 包裝外部記憶體的原生 Node 模組。這是一個相當罕見的用例，但某些模組確實使用了這種技術，並且這些模組需要重構才能與 Electron 20+ 相容。

我如何測量我的應用程式正在使用的 V8 堆積記憶體量，以了解我是否接近 4GB 限制？​

在渲染器程序 (renderer process) 中，您可以使用 performance.memory.usedJSHeapSize，它將以位元組為單位傳回 V8 堆積使用量。在主程序 (main process) 中，您可以使用 process.memoryUsage().heapUsed，這是可比較的。

什麼是 V8 記憶體隔離區？​

有些文件將其稱為「V8 沙箱 (sandbox)」，但該術語很容易與 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 的記憶體。這有點複雜，但可以讓您避免複製，這意味著大型緩衝區的效能更好。

為了使這更具體，以下是一個使用外部陣列緩衝區的 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 正在變更其主要 S3 儲存桶，您可能需要更新您的建置腳本

發生了什麼事？

大量的 Electron 建置產物 (build artifacts) 都上傳到一個名為 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

這裡重要的是 Hostname 變更了，並且 /atom-shell 前綴也變更了。另一個範例，這次是針對偵錯符號 (debug symbols)：

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

同樣，hostname 變更了，並且 /atom-shell 前綴也變更了。

這可能會對您產生什麼影響？

任何使用標準建置工具（例如 electron-rebuild、electron-packager 或 @electron/get）的人都不需要做任何事情。這應該是大多數人。

對於任何直接引用 S3 儲存桶的人，您必須更新您的引用以指向新的 hostname 並更新路徑。

現有資料呢？

gh-contractor-zcbenz 儲存桶上存在的大多數資料都已複製到新的儲存系統中。這表示所有偵錯符號和所有標頭 (headers) 都已複製。如果您依賴該儲存桶中尚未複製過來的某些資料，請在 electron/electron 中提出 issue 並告知我們。

目前的 gh-contractor-zcbenz S3 儲存桶不會被主動刪除。但是，我們無法保證該儲存桶將保持存活多久。我們強烈建議盡快更新以指向新的儲存桶。

Electron 專案將在 2021 年 12 月暫停一個月，然後在 2022 年 1 月恢復全速運作。

via GIPHY

十二月維持不變的事項​

1. 必要時將發布零日漏洞和其他重大安全性相關的版本。安全事件應透過 SECURITY.md 回報。
2. 行為準則報告和審核將會持續進行。

十二月將會改變的事項​

1. 12 月沒有新的 Beta 或 Stable 版本發布。12 月的最後兩週沒有 Nightly 版本發布。
2. 除了少數例外，不會進行 pull request 審核或合併。
3. 任何儲存庫都不會更新 issue tracker。
4. 維護者不會在 Discord 上提供偵錯協助。
5. 不會更新社群媒體內容。

為何會發生這種情況？​

簡而言之，雖然維護者對該專案感到高興和投入，但世界已經疲憊不堪。12 月是大多數公司的淡季，因此我們希望讓我們的維護者有機會充電。我們鼓勵其他專案考慮類似的措施。

我應該擔心 Electron 的未來嗎？​

不用擔心。我們能夠採取這一步驟是因為該專案狀況良好。每個人都期待 2022 年，我們預期會有好事發生！

從 2021 年 9 月開始，Electron 將每 8 週發布一個新的主要穩定版本。

在 2019 年，Electron 轉為 12 週發布週期，以符合 Chromium 的 6 週發布週期。最近，Chrome 和 Microsoft 都宣布了變更，這讓我們重新考慮 Electron 目前的發布週期：

1. Chromium 計畫每 4 週發布一個新的里程碑版本，從 2021 年 9 月 21 日的 Chrome 94 開始。此發布週期還增加了每 8 週一個新的 Extended Stable 選項，其中將包含所有更新的安全性修復。

2. Microsoft Store 將要求基於 Chromium 的應用程式不得超過 2 個主要版本。例如，如果最新發布的 Chromium 主要版本是 85，則任何基於 Chromium 的瀏覽器都必須至少使用 Chromium 版本 83 或更高版本。此規則包括 Electron 應用程式。

從 2021 年 9 月開始，Electron 將每 8 週發布一個新的主要穩定版本，以符合 Chromium 的 8 週 Extended Stable 版本。

我們第一個使用 Chromium Extended Stable 的版本將是 Electron 15，於 2021 年 9 月 21 日發布。

我們知道發布週期變更將影響其他下游應用程式，因此我們希望盡快讓我們的開發人員社群知道。請繼續閱讀以了解有關我們 2021 年發布時間表的更多詳細資訊。

Electron 15：臨時 Alpha 版本​

鑑於我們最初的 Electron 15 版本目標是非 Extended Stable 版本（Chromium 的 Extended Stable 版本基於其偶數版本），我們需要變更我們最初的目標發布日期。但是，Electron 應用程式必須使用最新的 2 個主要 Chromium 版本才能被 Microsoft Store 接受，這使得等待兩個 Chromium 版本是不可行的。

有了這兩個要求，我們的團隊面臨著時間上的困境。將 Electron 15 移至包含 Chromium M94 將允許應用程式開發人員使用第一個 Extended Stable 版本的 Chromium；但是，這也會將 beta 到 stable 的週期縮短到僅 3 週。

為了幫助進行此切換，Electron 將為 Electron 15 版本提供臨時的 alpha 建置版本。此 alpha 建置版本將為開發人員提供更多時間來測試和規劃 Electron 15 版本，其建置版本將比我們目前的 nightly 版本更穩定。

alpha 頻道建置版本將於 2021 年 7 月 20 日為 Electron 15 發布。它將於 2021 年 9 月 1 日過渡到 beta 版本，穩定版本目標發布日期為 2021 年 9 月 21 日。後續的 Electron 版本將不會有 alpha 版本。

2021 年發布計畫​

以下是我們目前 2021 年的發布時間表：

新增 alpha 頻道將 Electron 15 發布前的開發時間從 3 週延長到 9 週 — 更接近我們新的 8 週週期，同時仍滿足 Windows Store 提交的要求。

為了進一步幫助應用程式開發人員，在 2021 年剩餘時間至 2022 年 5 月期間，我們還將把我們支援的版本政策從最新的 3 個版本擴展到最新的 4 個 Electron 版本。 這表示即使您無法立即更改您的升級時間表，較舊版本的 Electron 仍將收到安全性更新和修復。

解決疑慮​

我們發布這篇文章是有原因的，而且是在此發布週期變更排程之前很久就發布了。我們知道更快的發布週期將對 Electron 應用程式產生實際影響 — 其中一些應用程式可能已經覺得我們的主要版本發布週期過於頻繁。

我們已嘗試解決以下常見疑慮：

❓ 為什麼要進行此變更？為什麼不維持 12 週的發布週期？​

為了在 Electron 中交付最新版本的 Chromium，我們的時間表需要追蹤他們的時間表。有關 Chromium 發布週期的更多資訊，請參閱此處。

此外，目前的 12 週發布週期對於 Microsoft Store 的新提交要求來說是不可行的。即使是最新穩定版本的 Electron 上的應用程式，也可能會經歷大約兩週的時間，其應用程式可能會在新安全要求下被拒絕。

每個新的 Chromium 版本都包含新功能、錯誤修復/安全性修復和 V8 效能改進。我們希望您（作為應用程式開發人員）能夠及時獲得這些變更，因此我們的穩定版本發布日期將繼續與每隔一個 Chromium 穩定版本發布日期保持一致。作為應用程式開發人員，您將比以前更快地存取新的 Chromium 和 V8 功能和修復。

❓ 現有的 12 週發布時間表已經移動很快了。團隊正在採取哪些步驟來簡化升級？​

更頻繁發布的優點之一是擁有更小的版本。我們了解升級 Electron 的主要版本可能很困難。我們希望較小的版本將在每個版本中引入更少的 Chromium 和 Node 主要變更，以及更少的重大變更 (breaking changes)。

❓ 未來的 Electron 版本是否會有 alpha 版本可用？​

目前沒有計畫支援永久的 alpha 版本。此 alpha 版本僅適用於 Electron 15，作為幫助開發人員在縮短的發布週期內更輕鬆升級的一種方式。

❓ Electron 是否會擴展支援的版本數量？​

我們將把我們支援的版本政策從最新的三個版本擴展到最新的四個 Electron 版本，直到 2022 年 5 月，隨著 Electron 19 的發布。在 Electron 19 發布後，我們將恢復支援最新的三個主要版本，以及 beta 和 nightly 版本。

問題？​

📨 如果您有任何問題或疑慮，請發送郵件至 info@electronjs.org 或 加入我們的 Discord。我們知道這項變更將影響許多應用程式和開發人員，您的回饋對我們非常重要。我們想聽取您的意見！