時間表： Electron 44 已於 2026 年 8 月 25 日正式發布，版本日期可由官方發布公告核對。本週建議：先不要把所有工作搬到 Mac；保留 Windows 或 Linux 處理日常開發，另設一個真實 Mac 節點完成 macOS 最終打包、代碼簽名、公證、票據裝訂與安裝驗證。
這就是 Electron 44 macOS 打包的判斷標準：產生一個檔案，不等於產生可交付的 macOS 版本。若目標是讓使用者安裝、通過 Gatekeeper 檢查並持續更新，最後一段發布鏈路應在真實 Mac 上執行。
本文適合主要在 Windows 或 Linux 開發 Electron 桌面程式、首次準備發布 macOS 版本的工程師。需要把 Electron Forge、簽名與公證接入自動化流水線的 DevOps、發布工程師，以及正在評估購買 Mac、短期租用遠端 Mac 或保留專用節點的技術負責人，也可以直接依照本文驗收。
產物與可交付版本的分界
Electron 官方把分發流程拆成建置、代碼簽名、公證與使用者端驗證等不同責任。可先在 Windows 或 Linux 產生未簽名測試檔案，但這只能回答「程式有沒有被打包」，不能回答「使用者能否安心安裝」。完整分發流程可參考Electron 分發總覽。
我們在值班時先把流程分成以下幾層：
| 流程層 | Windows / Linux 節點 | 真實 Mac 發布節點 | 驗收結果 |
|---|---|---|---|
| 原始碼與通用測試 | 編碼、Lint、單元測試 | 可讀取固定提交版本 | 測試結果與提交識別碼一致 |
| macOS 打包 | 可作有限度的跨平台嘗試 | 依目標架構重新打包 | 產物含正確平台資源 |
| 代碼簽名 | 不承載發布私密金鑰 | 使用受控鑰匙圈與簽名身份 | 簽名資訊可被驗證 |
| 公證與票據裝訂 | 不作最終判斷 | 提交、等待、裝訂、離線檢查 | 可交付安裝包 |
| 安裝與更新 | 可做通用測試 | 以乾淨使用者帳戶驗證 | 安裝及更新路徑可重現 |
Electron 44 專案能否在 Windows 上「生成 macOS 安裝包」，取決於工具與專案內容；但若要公開發布，判斷不能停在跨平台建置成功。
純 JavaScript 與原生依賴的差異
純 JavaScript 專案通常較容易先在非 Mac 節點完成通用建置。問題會在加入 Node 原生模組、輔助二進位檔、系統擴充功能或平台專用資源後放大。這些依賴可能只提供 darwin-arm64、darwin-x64，或另外提供通用二進位檔；不能把 win32 或 linux 的安裝結果直接視為 macOS 結果。
Electron 的平台與架構安裝說明應與每個依賴的發行檔清單一併核對。實務上，我們會要求每次發布記錄：
- 鎖定檔與提交識別碼。
- 原生模組實際解析到的目標架構。
- 全新安裝依賴後的重新建置結果。
- 在乾淨 Mac 工作區載入模組的結果。
- Apple Silicon 與 Intel 目標是否有明確分流。
遠端 Mac 的第一項職責不是把其他系統產生的 dist 目錄複製過來，而是重新驗證真實目標架構。若只在開發機保留快取，CI 可能通過，使用者啟動時才在原生模組載入階段失敗。
簽名身份與公證憑據
面向 macOS 使用者分發時，Electron 建議對應用程式進行代碼簽名；相關限制可在Electron 代碼簽名文件核對。這裡至少涉及 Developer ID、Hardened Runtime、entitlements、Keychain 私密金鑰與執行帳戶。
Electron Forge 的 macOS 指南把簽名設定接到建置流程中；其設定與 @electron/osx-sign 的欄位可分別參考Forge macOS 簽名指南與@electron/osx-sign 類型說明。這些文件不是叫我們把所有憑據寫入 CI 變數，而是提醒發布環境需要清楚管理身份和權限。
我們會採用以下邊界：
- 建置帳戶與發布帳戶分開。
- 私密金鑰只進入受控鑰匙圈，不放在一般工作目錄。
- Team ID、Bundle ID、證書名稱與密鑰檔名使用 CI 秘密變數或受控檔案注入。
entitlements放在版本控制中，但不把私密金鑰放入倉庫。- 任務完成後清理暫存憑據，保留可追蹤的簽名輸出與日誌。
Keychain、登入項和自動更新是否正常，往往與簽名身份的持續性有關。這也是為什麼「在開發者電腦手動簽過一次」不能取代可重現的發布節點。
公證、票據與安裝驗證
簽名完成後，仍要處理公證。Apple 說明可透過公證服務處理 macOS 軟體分發，並可使用 notarytool 或 Notary API；流程細節見Apple 公證工作流說明及Notary API 文件。
這幾個狀態必須分開記錄：
- 上傳請求已建立。
- 公證服務回覆成功或失敗。
- 使用提交識別碼取得結果。
- 對通過的產物執行票據裝訂。
- 在沒有網路的情況下驗證裝訂狀態。
- 以全新使用者帳戶安裝並啟動。
- 執行實際自動更新流程。
上傳成功不代表公證通過。公證通過也不代表票據已裝訂，更不代表下載後的安裝包能在乾淨帳戶正常啟動。認證資訊、Team ID、密鑰檔案、Bundle ID、提交識別碼、主機名稱與路徑，都應使用 CI 變數或 <PLACEHOLDER> 形式，避免把真實憑據寫進範例和日誌。
混合 CI 與發布節點隔離
我們建議把流水線拆成兩段。Windows 或 Linux 節點執行 Lint、單元測試、通用建置與測試報告；遠端 Mac 只接收固定版本的原始碼或已驗證製品，然後執行 macOS 打包、簽名、公證、票據裝訂與冒煙測試。
傳遞內容至少包含提交識別碼、鎖定檔雜湊、輸入檔案校驗值和上游測試結果。Mac 節點不應在任務中隨意重新抓取分支，否則兩個節點可能使用不同版本的原始碼。Forge 的建置生命週期文件可用來對照各階段責任。
| 節點方案 | 適合情況 | 主要風險 | 我們的建議 |
|---|---|---|---|
| 短期遠端 Mac | 低頻發布、首次導入、驗證流程 | 每次需重建環境與檢查憑據 | 先跑通一條完整發布鏈 |
| 長期專用 Mac | 固定發布、需保留快取與排程 | 節點與憑據成為長期資產 | 加入重啟恢復與權限稽核 |
| 共享 Mac Runner | 任務量不穩定、團隊共用 | 工作目錄、鑰匙圈與任務互相污染 | 只有在隔離機制清楚時採用 |
| 雙軌發布 | 關鍵產品、需要回退能力 | 維護兩套設定 | 保留另一條可切換路徑 |
發布節點不必為每個通用測試長時間佔用。Electron macOS 發布節點是否需要長期運行，應由發布頻率、憑據風險、排程需求和回滾要求決定，而不是由「有沒有 Mac」單獨決定。
生產制品驗收表
購買、租用或自建前，先用同一份驗收條件測試。CI Job 顯示成功，只能算流程訊號，不能算生產制品合格。
| 驗收項目 | 必查內容 | 通過條件 |
|---|---|---|
| 全新工作區 | 重新取得固定提交版本與鎖定檔 | 不依賴開發者本機快取 |
| 原生模組 | 安裝、重新建置、啟動載入 | 目標架構與執行平台一致 |
| 簽名 | 身份、entitlements、Hardened Runtime | 簽名驗證無錯誤 |
| 公證 | 提交結果與原始日誌 | 成功狀態可由提交識別碼追查 |
| 票據 | 裝訂後離線檢查 | 下載後仍能驗證 |
| 乾淨安裝 | 新使用者帳戶、首次啟動 | 不依賴開發者設定 |
| 自動更新 | 上一版到新版本的實際流程 | 更新、重啟與回滾路徑清楚 |
| 重啟恢復 | 鑰匙圈、帳戶、常駐任務 | 節點重啟後能依文件恢復 |
我們也會保留上一個可發布制品作為回滾入口。重啟後要重新檢查鑰匙圈解鎖狀態、建置帳戶、常駐任務和工作目錄權限。若這些項目沒有記錄，即使第一次簽名成功，下一次節點重啟後仍可能中斷發布。
方案選擇與遠端 Mac 導入
| 決策條件 | 優先方案 | 原因 |
|---|---|---|
| 只需首次發布或低頻更新 | 短期遠端 Mac | 先驗證真實簽名、公證與安裝結果 |
| 發布頻率固定且有排程 | 長期專用節點 | 鎖定環境、權限與恢復程序 |
| 通用測試量大、Mac 任務少 | 混合 CI | 避免 Mac 被 Lint 和單元測試佔用 |
| 憑據風險高、產品不能停發 | 雙軌方案 | 一條路徑失效時仍可切換 |
| 需要實體 USB 或特殊周邊 | 本地或專用 Mac | 遠端節點未必能提供所需介面 |
若團隊正在評估遠端節點，可先查看 MESHLAUNCH 的遠端 Mac 方案，再以自己的 Electron 專案跑完整驗收，不要只依照規格表做結論。需要固定的 Apple Silicon 測試環境時，也可對照 Mac mini M4 遠端訂購方案；實際可用性仍應以當下頁面與驗收結果為準。
常見問題
Windows 上能否先產生 macOS 安裝包？
可以產生部分未簽名產物，但「能產生」和「能發布」是兩件事。若專案含原生模組、平台資源或自動更新，仍應在真實 Mac 上重新確認目標架構、簽名、公證、票據及乾淨安裝。
macOS 代碼簽名為什麼通常要在 Mac 上做？
因為發布會牽涉 macOS 安全工具、鑰匙圈、Developer ID 憑證與 entitlements。真正的風險不是命令能否被呼叫，而是私密金鑰是否受控、執行帳戶是否隔離，以及重啟後流程能否重現。
CI 裡怎樣串接 Electron Forge 與 Apple 公證？
可先由 Forge 完成打包和簽名，再在受控 Mac 階段呼叫 Apple 的公證工具或服務介面。流水線必須等待結果、保存提交識別碼，接著完成票據裝訂、離線驗證和乾淨帳戶安裝測試；不能只檢查上傳命令的退出狀態。
Windows 開發 Electron 程式要怎樣發布 Mac 版本？
把 Windows 的責任限於編碼、Lint、單元測試和通用建置，再將固定提交版本交給 Mac 節點。Mac 節點執行目標架構打包、簽名、公證、安裝與更新測試，並回傳可追溯制品。
Electron macOS 發布節點需要長期運行嗎？
低頻發布不需要立即維持長期節點；短期遠端 Mac 足以先跑通一次生產鏈路。若發布有固定排程、需要快取或必須持續保留簽名環境，才值得配置專用節點，並同時建立重啟恢復程序。
本週的發布決定
如果目前方案只有 Windows 或 Linux，直接把所有任務搬到一台長期 Mac，會增加節點維護、鑰匙圈保護和閒置成本；只靠跨平台打包，則會留下原生模組、簽名、公證和 Gatekeeper 驗證缺口。較穩妥的做法，是先租用 MESHLAUNCH 的遠端 Mac，從乾淨工作區跑完一次 Electron 44 的簽名、公證、安裝與更新驗收，再按發布頻率決定是否保留長期專用節點。需要臨時算力或測試環境時，這比立即購買硬體更容易回退；若是長期高頻重負載或必須使用實體介面，則應評估自有 Mac 與備用發布路徑。