Electron 应用分发完整指南：打包、代码签名、商店发布与自动更新

应用进入生产就绪状态后，在真正交付给用户之前，还需要走完一条完整的"发行链路"：将应用资源打包成可执行程序并完成品牌重塑（rebranding）、对产物进行代码签名以通过各操作系统安全校验、把安装包发布到直接下载站点或各系统官方应用商店，以及接入自动更新能力让用户无需手动重装即可获得新版本。本文以 distribution-overview.md 为骨架，系统梳理 Electron 应用从源码走向终端用户的四个关键阶段（打包 → 签名 → 发布 → 更新），并结合本仓库中的 打包指南、代码签名指南、Mac App Store 提审指南、Windows Store 指南、Snapcraft 指南 与 应用更新指南 逐一深入。读完本文，你将能独立规划并执行一次完整的 Electron 桌面应用交付。

分发流程总览：四个必经阶段

从仓库目录 docs/tutorial/ 下的一系列指南可以清楚看到 Electron 官方对"分发"的定义并不局限于生成一个安装包，而是一条完整链路：

1. Packaging（打包）：把应用的全部资源与静态文件打成可执行程序，并完成对 Electron 默认名称与图标的"品牌重塑"。可借助 Electron Forge 等专用工具，也可手工完成，详见 Application Packaging。
2. Code signing（代码签名）：用你的身份为应用做数字签名，避免触发用户操作系统的安全拦截。各系统的签名流程见 Code Signing。
3. Publishing（发布）：将已打包并签名的安装包直接上传供用户下载；若要触达更多用户，可额外上架各系统官方数字分发平台（应用商店），通常需要比直下版多做一次构建步骤，对应 Mac App Store、Windows Store 与 Snapcraft (Linux) 三份指南。
4. Updating（更新）：借助 Electron 的自动更新机制把新版推送给用户，而无需用户手动下载，实现细节见 Updating Applications。

下面按这四个阶段逐一展开。

第一阶段：应用打包

无论使用哪条路线，打包的本质目标一致：把 package.json、主进程脚本与渲染资源组织成 Electron 运行时能够直接加载的结构，然后把"Electron"替换成"你的产品"。

路线一：使用专用工具（推荐）

Electron 官方推荐的打包发布工具是 Electron Forge。它以一条统一、可扩展的命令行界面整合了 Electron 构建工具生态，覆盖三个阶段：

• package：把应用打包为可分发的文件夹；
• make：为各操作系统生成可执行文件与安装器；
• publish：把上述产物上传到在线平台供用户下载。

若你尚未开发完应用，可跟随 tutorial-1-prerequisites.md 起的完整教程从零起步；若应用已在本地跑通、只想立刻进入打包发布环节，可直接从教程第五步 tutorial-5-packaging.md 切入。

Electron Forge 之外，社区还有 electron-builder 这类替代方案，其由社区维护、不含官方支持，并会用自研实现替换 Electron 维护者所用的部分模块（如自动更新），选型时需留意这一差异。

路线二：手工打包

如果倾向手工方式，有两种分发形态可选：使用 预编译二进制（prebuilt binaries），或使用 应用源码归档（asar）。

方式 A：使用预编译二进制

首先从 Electron 的预编译二进制发行物中取得 Electron 运行时。随后把存放应用代码的目录命名为 app，放到 Electron 的 resources 目录下。下方示例中以 electron/ 指代预编译二进制的位置：

macOS 结构：

electron/Electron.app/Contents/Resources/app/
├── package.json
├── main.js
└── index.html

Windows 与 Linux 结构：

electron/resources/app
├── package.json
├── main.js
└── index.html

之后分别执行 Electron.app（macOS）、electron（Linux）或 electron.exe（Windows），Electron 便会以你的应用身份启动。此时整个 electron 目录就是你要交付给用户的分发产物。

方式 B：使用 asar 源码归档

如果尚未使用 Parcel、Webpack 这类打包器，把全部源码打进单个 asar 归档能带来可观的收益：缓解 Windows 上超长路径问题、加快 require 的读取速度、并让源码免于被随意浏览。

用法很简单：把生成的归档改名为 app.asar 放到 Electron 的 resources 目录下即可，Electron 会读取该归档并从中启动：

electron/Electron.app/Contents/Resources/
└── app.asar

electron/resources/
└── app.asar

从源码看 asar 的加载机理：Electron 之所以能透明地读写 asar 内的文件，是因为它对 Node 的 fs.readFile、require 等 API 施加了特殊补丁，把这些归档当作虚拟目录、其中的文件当作普通文件；页面内通过 file: 协议访问归档文件的 Web API 也遵循同样的虚拟目录语义。本仓库中负责此机制的模块集中在 lib/node/asar-fs-wrapper.ts（Node 侧的 fs 包装）与 lib/browser/guest-view-manager.ts 等浏览器侧路径，更完整的用法与边界（如归档内符号链接、如何让 fs.readdirSync 正常迭代目录）见 asar-archives.md。

提示：打包产物中应剔除非必需的 node_modules 依赖。Windows Store 与 Snapcraft 指南都特别强调这一点——多余模块只会徒增安装包体积。

品牌重塑（Rebranding）

把应用塞进 Electron 后，还需把"Electron"改头换面成你自己的产品再交付：

• Windows：直接把 electron.exe 改成任意名字，再用 rcedit 之类的工具修改其图标与文件信息。

• Linux：把 electron 可执行文件重命名成任意名字即可。

• macOS：把 Electron.app 改成你想要的名称，同时必须修改以下两个文件中的 CFBundleDisplayName、CFBundleIdentifier 与 CFBundleName 字段：

  • Electron.app/Contents/Info.plist
  • Electron.app/Contents/Frameworks/Electron Helper.app/Contents/Info.plist

  若不想在"活动监视器"里看到 Electron Helper，还可以重命名 helper 应用——但务必同步重命名 helper 应用可执行文件的文件名。改名后的典型结构如下：

MyApp.app/Contents
├── Info.plist
├── MacOS/
│   └── MyApp
└── Frameworks/
    └── MyApp Helper.app
        ├── Info.plist
        └── MacOS/
            └── MyApp Helper

还有一种另类的"从源码重塑"：修改 args.gn 中的产品名构建参数（electron_product_name = "YourProductName"）后从源码重新编译 Electron 本体。本仓库的构建配置结构（如 BUILD.gn 与 buildflags/BUILD.gn）即是为这类从源码构建服务的。但官方明确不推荐此路线——搭建从源码编译的环境并不轻松且耗时显著。

第二阶段：代码签名

代码签名是一种用于证明"应用由你创建"的安全技术。若不签名，Windows 和 macOS 都会阻止用户直接运行你的应用——虽然技术上可以发布未签名应用，但用户必须绕过多道繁琐的高级手动步骤才能运行。凡是准备打包并分发的 Electron 应用，都应完成代码签名。

上图为未正确签名/公证时 macOS 用户可能看到的典型警告，来自 code-signing.md。Electron 生态的工具链把签名做成了近乎开箱即用的配置项。

macOS：签名与公证（Notarization）

发布 macOS 应用需要两步：先给应用做代码签名，再上传 Apple 走**公证（notarization）**流程，由自动化系统进一步核验应用是否存在危害用户的行为。

开始前的三项前置条件：

1. 注册 Apple Developer Program（需缴纳年费）；
2. 在 macOS 电脑上安装 Xcode；
3. 生成、下载并安装签名证书。

使用 Electron Forge 签名

Forge 是官方 Electron 工具的组合，底层实际调用的是 @electron/packager、@electron/osx-sign 与 @electron/notarize。使用 Forge 只需在配置中追加少量签名项即可。

使用 Electron Packager 签名

若未使用 Forge 这类一体化构建管线，多半正在直接使用 @electron/packager（其内置 @electron/osx-sign 与 @electron/notarize）。通过 Packager 的 API 传入配置即可同时完成签名与公证：

const packager = require('@electron/packager')

packager({
  dir: '/path/to/my/app',
  osxSign: {},
  osxNotarize: {
    appleId: '[e-mail]',
    appleIdPassword: 'my-apple-id-password'
  }
})

若此示例满足不了需求，可查阅 @electron/osx-sign 与 @electron/notarize 提供的更多配置项。

签名 Mac App Store 应用

MAS 渠道的证书体系与签名约束与直下版完全不同，见 Mac App Store Guide（详见第三阶段）。

依赖签名的 macOS API

值得特别提醒：Electron 暴露的若干 macOS API 依赖系统框架（如 Keychain Access 与 Squirrel.Mac），只有应用完成代码签名后这些框架才会正常工作。用未签名或 ad-hoc 签名的应用测试这些 API 时行为可能不稳定，很多貌似 Electron 的 Bug 其实通过正确签名（并公证）即可解决：

• safeStorage：没有稳定一致的签名时，macOS 可能无法识别两次构建出自"同一个应用"，导致 Keychain 在每次更新后都重新向用户弹权限请求。
• app.setLoginItemSettings()：应用未打包、签名、公证时，登录项可能行为异常（如静默注册失败）。
• cookieEncryption fuse：Cookie 加密与 safeStorage 使用同样的 Keychain OS 级访问，因此有相同的签名要求，见 fuses.md 中的 cookieEncryption 条目。
• autoUpdater：Squirrel.Mac 要求应用已签名，否则自动更新完全无法工作。

Windows：使用 Azure Artifact Signing

Azure Artifact Signing（前身 Azure Trusted Signing）是微软的现代云端签名服务，是 Windows 上最廉价的签名选项，能消除 SmartScreen 警告。需要注意：该服务当前仅对特定国家/地区的开发者开放，使用前请查阅 Artifact Signing 的官方前提说明。

身处 Linux/macOS 的开发者可使用 jsign 通过 Azure Artifact Signing 为 Windows 应用签名，示例：

jsign --storetype TRUSTEDSIGNING \
      --keystore https://eus.codesigning.azure.net/ \
      --storepass $AZURE_ACCESS_TOKEN \
      --alias trusted-sign-acct/AppName \
      --tsaurl http://timestamp.acs.microsoft.com/ \
      --tsmode RFC3161 \
      --replace <file>

Electron Forge（推荐的签名方式，可连同 Squirrel.Windows 与 WiX MSI 安装器一起签名）与 Electron Builder 也都有对应的 Azure Artifact Signing 配置文档。

Windows：使用传统证书

采购 EV 证书

与 Apple 不同，微软允许开发者在公开市场购买代码签名证书，通常由同时售卖 HTTPS 证书的公司提供，主流经销商包括 DigiCert、GlobalSign、Sectigo、SSL.com 等。需要特别强调的是：自 2023 年 6 月起，微软要求软件必须使用"扩展验证"（EV）代码签名证书。过去那种更简单廉价的 Authenticode（基于软件的 OV 证书）不再有效——Windows 会把这类签名当作完全未签名处理并弹出同等警告。

EV 证书强制存放于符合 FIPS 140 Level 2、Common Criteria EAL 4+ 或同等标准的硬件安全模块中，即无法把证书直接下载到 CI 基础设施上——这些模块在实际中看起来就像高端的 USB 闪存盘。因此许多证书服务商现在提供"云签名"：签名硬件整体放在其数据中心，开发者远程调用即可，这在 CI（GitHub Actions、CircleCI 等）中尤为便利。Electron 自身的应用目前使用 DigiCert KeyLocker，但任何提供命令行签名工具的供应商都能与 Electron 工具链兼容。

Electron 生态的签名抽象：windowsSign

Electron 生态中的所有工具都基于 @electron/windows-sign，统一通过 windowsSign 属性暴露配置。你可以用它直接签名文件，也可以让同一份 windowsSign 配置横跨 Electron Forge、@electron/packager、electron-winstaller 与 electron-wix-msi 复用。典型用法：

• Electron Packager（非 Forge 一体化管线时）：

const packager = require('@electron/packager')

packager({
  dir: '/path/to/my/app',
  windowsSign: {
    signWithParams: '--my=custom --parameters',
    // If signtool.exe does not work for you, customize!
    signToolPath: 'C:\\Path\\To\\my-custom-tool.exe'
  }
})

• electron-winstaller（Squirrel.Windows）：生成 Squirrel.Windows 安装器的包（也是 Forge Squirrel.Windows Maker 的底层实现），支持同样的 windowsSign 配置：

const electronInstaller = require('electron-winstaller')
// NB: Use this syntax within an async function, Node does not have support for
//     top-level await as of Node 12.
try {
  await electronInstaller.createWindowsInstaller({
    appDirectory: '/tmp/build/my-app-64',
    outputDirectory: '/tmp/build/installer64',
    authors: 'My App Inc.',
    exe: 'myapp.exe',
    windowsSign: {
      signWithParams: '--my=custom --parameters',
      // If signtool.exe does not work for you, customize!
      signToolPath: 'C:\\Path\\To\\my-custom-tool.exe'
    }
  })
  console.log('It worked!')
} catch (e) {
  console.log(`No dice: ${e.message}`)
}

• electron-wix-msi（WiX MSI）：生成 MSI 安装器的包（Forge MSI Maker 的底层实现），同样复用 windowsSign。除常规配置外，它还能让你在 compile() 之前对 support binaries 逐一补签：

import { MSICreator } from 'electron-wix-msi'

// Step 1: Instantiate the MSICreator
const msiCreator = new MSICreator({
  appDirectory: '/path/to/built/app',
  description: 'My amazing Kitten simulator',
  exe: 'kittens',
  name: 'Kittens',
  manufacturer: 'Kitten Technologies',
  version: '1.1.2',
  outputDirectory: '/path/to/output/folder',
  windowsSign: {
    signWithParams: '--my=custom --parameters',
    // If signtool.exe does not work for you, customize!
    signToolPath: 'C:\\Path\\To\\my-custom-tool.exe'
  }
})

// Step 2: Create a .wxs template file
const supportBinaries = await msiCreator.create()

// 🆕 Step 2a: optionally sign support binaries if you
// sign your binaries as part of your packaging script
for (const binary of supportBinaries) {
  // Binaries are the new stub executable and optionally
  // the Squirrel auto updater.
  await signFile(binary)
}

// Step 3: Compile the template to a .msi file
await msiCreator.compile()

• Electron Builder：自带一套自定义签名方案，参见其代码签名文档。

签名 Windows Store 应用的附加要求见 Windows Store Guide。

第三阶段：发布到各平台分发渠道

应用打包签名完毕后，最直接的方式是把安装包上传到线上供用户下载。若想触达更多用户，还可上架三大系统各自的应用商店——相比直下版，每个商店都额外需要一次构建步骤。

Mac App Store

MAS 提审指南 完整覆盖了签名与提审两条线。其核心差异在于证书类型决定产物去向：

• "Apple Development" 证书：用于在已注册设备上开发测试签名，不能提交 Mac App Store；
• "Apple Distribution" 证书：专用于提审，但用它所签应用在未从 App Store 下载前无法直接运行；
• "Developer ID Application" 证书：用于 Mac App Store 之外的直下分发，无沙盒限制。

沙盒是硬约束：以 "Apple Development"/"Apple Distribution" 签名的应用只能在 App Sandbox 下运行，因此必须使用 Electron 的 MAS 专用构建——标准 darwin 构建在沙盒下会启动失败。使用 @electron/osx-sign 签名时它会自动注入所需 entitlements；若不使用该工具，则需在应用 bundle entitlements 中至少声明 com.apple.security.app-sandbox 与 com.apple.security.application-groups，给 bundle 内所有可执行文件注入含 com.apple.security.app-sandbox 与 com.apple.security.inherit 的子 entitlement，并在 Info.plist 中写入 ElectronTeamID 键。本地真机测试还需把 provisioning profile 内嵌到 YourApp.app/Contents/embedded.provisionprofile。

MAS 构建的受限能力：为满足沙盒要求，MAS 构建关闭了 crashReporter 与 autoUpdater，并存在如下行为差异——部分机器上视频采集可能失效、部分辅助功能不可用、应用无法感知 DNS 变化。另外沙盒严格限制了应用可访问的资源范围。若应用用到网络、打开/保存对话框等能力，还需按 API 补充相应 entitlements（如 com.apple.security.network.client/.server、com.apple.security.files.user-selected.read-only/.read-write），并可通过 optionsForFile 为不同文件指定不同 entitlements。

各国合规提示：视发布国别，可能需要申报软件所用加密算法；mac-app-store-submission-guide.md 末尾列出了一份涵盖 AES、HMAC、ECDSA、RSA、SHA 等算法的清单，可据此准备出口合规材料。

Windows Store（AppX）

Windows Store 指南 介绍的是把 Electron 应用编译为 .appx 包（Microsoft 提供的 electron-windows-store 工具），从而接入 UWP 应用模型的安装与更新机制。原理是：Windows 10"周年更新版"通过在 Windows Container 中运行安装器，为 win32 .exe 配上一套虚拟化文件系统与注册表，从而支持一键安装/卸载。

环境要求：Windows 10 Anniversary Update（2016-08-02 发布）、Windows 10 SDK、Node 4+，然后全局安装 CLI：

npm install -g electron-windows-store

操作分三步：

1. 打包应用：用 @electron/packager 产出（并剔除无用 node_modules），典型输出形如 Ghost.exe + 各 .dll/.pak/icudtl.dat + resources/app.asar；
2. 生成 AppX：在"以管理员身份运行"的 PowerShell 中执行：

electron-windows-store `
    --input-directory C:\myelectronapp `
    --output-directory C:\output\myelectronapp `
    --package-version 1.0.0.0 `
    --package-name myelectronapp

工具内部会先压平 node_modules、把应用归档为 app.zip，再借助安装器与 Windows Container 产出"展开式"AppX（含 AppXManifest.xml 与虚拟文件系统/注册表），随后用 MakeAppx.exe 打包为单文件 AppX，最后创建可信证书完成签名并可自动安装。

3. 使用 AppX 包：用户端需 Windows 10 Anniversary Update；与纯 UWP 应用不同，此类打包应用当前需走手动验证流程。在受管环境（如企业）中可用 Add-AppxPackage PowerShell Cmdlet 自动化安装。另一关键限制是：AppX 内仍是 win32 可执行文件，无法运行于 Xbox、HoloLens 或手机。

指南还提供了两个可选增强：通过不可见的 UWP 后台任务（BackgroundTask）接入推送通知、Cortana、动态磁贴等 UWP 能力；以及在需要自定义安装器时，用 Desktop App Converter 走 Container 虚拟化编译路线（首次需用 DesktopAppConverter.ps1 -Setup -BaseImage .\BaseImage-14316.wim 做一次性安装）。

Snapcraft（Linux）

Snapcraft 指南 面向 Ubuntu 软件中心等 Snapcraft 环境。Snap 是容器化软件包，自带依赖、支持自动更新、无需改动系统即可跑在所有主流 Linux 发行版上。生成 .snap 有三种途径：

1. 使用 Electron Forge 或 electron-builder（内置 snap 支持，最省事）；
2. 使用 electron-installer-snap（以 @electron/packager 产物为输入）；
3. 使用现成的 .deb 包转换。

途径二（electron-installer-snap）：先用 @electron/packager 打包出 dist/app-linux-x64 形态的目录，然后在含 snapcraft 的终端中执行：

npx electron-installer-snap --src=out/myappname-linux-x64

也可在构建管线中编程调用 snap(options).then(snapPath => ...)。

手写 snapcraft.yaml 的推荐姿势（snap/snapcraft.yaml）：注意 base: core22、confinement: strict，app 命令追加 --no-sandbox，并通过 environment 把 TMPDIR 指向 $XDG_RUNTIME_DIR 以修正 Chromium/Electron 对 libappindicator 资源的读取；parts 内用 override-build 在构建期安装依赖并调用 npx electron-packager 产出应用。构建后依次执行 snapcraft、sudo snap install ... --dangerous（本地安装未发布包需此标志）即可运行。

途径三（.deb 转换）：在 snapcraft.yaml 中用 plugin: dump + source-type: deb 引入 .deb，并通过 electron-launch 包装脚本启动应用；若采用 strict 约束也可改用 desktop-launch 命令。

Wayland/PipeWire 桌面采集（可选）：部分采用 Wayland 协议的 Linux 配置需要 PipeWire 库才能采集桌面。将 base 设为 core22 或更新，然后新增名为 pipewire 的 part（build-packages: [libpipewire-0.3-dev]、stage-packages: [pipewire]，并对 usr/lib/*/pipewire-*、spa-* 等路径做 prime 收纳），再在应用 environment 中注入 SPA_PLUGIN_DIR、PIPEWIRE_CONFIG_NAME 与 PIPEWIRE_MODULE_DIR 三个变量。

第四阶段：自动更新

发布之后，如何让既有用户平滑升级？应用更新指南 提供了从"无服务器静态存储"到"自建更新服务端"的完整梯度方案，其共同底座是内置的 Squirrel 框架与 Electron 的 autoUpdater 模块。从本仓库源码看，autoUpdater 在 lib/browser/api/auto-updater/ 下按平台拆分为多个实现：auto-updater-win.ts/squirrel-update-win.ts 走 Squirrel.Windows 的 RELEASES 协议，auto-updater-native.ts 用于 macOS 的 Squirrel.Mac，另有面向 MSIX 包的 auto-updater-msix.ts 与 msix-update-win.ts——这也印证了"更新元数据格式因平台而异"的结论。无论走哪条路线，应用都需要先 打包。

方案一：云对象存储（无服务器）

autoUpdater 可以指向一个存放最新版本元数据的静态存储 URL 完成更新检查。发布元数据的格式 macOS 与 Windows 不同：

• macOS 端 Squirrel.Mac 读取 RELEASES.json（在 Forge 中通过 ZIP Maker 的 macUpdateManifestBaseUrl 配置发布），其 JSON 含 currentRelease 与 releases[]，每条 release 的 updateTo 描述 version、pub_date、notes、name 与 url；
• Windows 端 Squirrel.Windows 读取构建期生成的 RELEASES 文件，它描述要更新到的 .nupkg delta 包，例如：

B0892F3C7AC91D72A6271FF36905FEF8FE993520 electron-fiddle-0.36.3-full.nupkg 103298365

这些元数据文件应与发布产物同目录，并按"平台 + 架构"组织目录，形如 my-app-updates/darwin/{x64,arm64}/…zip + RELEASES.json 与 my-app-updates/win32/x64/…nupkg + RELEASES。

消费元数据最简单的方式是安装 update-electron-app 模块，并把 updateSource.baseUrl 指向元数据所在目录：

const { updateElectronApp, UpdateSourceType } = require('update-electron-app')

updateElectronApp({
  updateSource: {
    type: UpdateSourceType.StaticStorage,
    baseUrl: `https://my-bucket.s3.amazonaws.com/my-app-updates/${process.platform}/${process.arch}`
  }
})

方案二：update.electronjs.org

Electron 团队维护着免费开源的 update.electronjs.org Web 服务用于自助更新，适用前提是：应用运行于 macOS 或 Windows、拥有公开 GitHub 仓库、构建产物发布到 GitHub Releases、macOS 构建已代码签名。

使用方式是先安装依赖再在主进程文件顶部调用：

npm install update-electron-app

require('update-electron-app')()

默认行为：应用启动时检查一次，此后每十分钟检查一次；发现更新后自动后台下载，下载完成弹出对话框询问是否重启。需要定制时可向 update-electron-app 传参或直接使用底层更新服务。

方案三：自建更新服务器

私有应用或不走 GitHub Releases 时，可自建更新服务端，常用选型有：

• Hazel——私有或开源应用皆可，可免费部署于 Vercel，数据源自 GitHub Releases，借助 GitHub CDN；
• Nuts——同样基于 GitHub Releases，但会在磁盘缓存更新并支持私有仓库；
• electron-release-server——带发布管理仪表盘，不要求发布物来自 GitHub；
• Nucleus——Atlassian 维护的完整更新服务器，支持多应用多渠道，用静态文件存储摊薄成本。

服务端就绪后，在应用侧用 autoUpdater 三步接入：

Step 1：主进程中引入所需模块。⚠️ 务必确认以下代码只在打包后的应用中执行而非开发环境，可用 app.isPackaged（见 app.md）判断：

const { app, autoUpdater, dialog } = require('electron')

Step 2：构造更新 feed URL 并交给 autoUpdater，随后定时检查（示例每分钟一次）：

const server = 'https://your-deployment-url.com'
const url = `${server}/update/${process.platform}/${app.getVersion()}`

autoUpdater.setFeedURL({ url })

setInterval(() => {
  autoUpdater.checkForUpdates()
}, 60000)

此后每发布一个新的 GitHub Release，打包过的应用就会收到一次更新。

Step 3：通过 autoUpdater 事件 通知用户并处理错误：

autoUpdater.on('update-downloaded', (event, releaseNotes, releaseName) => {
  const dialogOpts = {
    type: 'info',
    buttons: ['Restart', 'Later'],
    title: 'Application Update',
    message: process.platform === 'win32' ? releaseNotes : releaseName,
    detail:
      'A new version has been downloaded. Restart the application to apply the updates.'
  }

  dialog.showMessageBox(dialogOpts).then((returnValue) => {
    if (returnValue.response === 0) autoUpdater.quitAndInstall()
  })
})

autoUpdater.on('error', (message) => {
  console.error('There was a problem updating the application')
  console.error(message)
})

另注：setFeedURL 的 url 字段支持 file:// 协议。若更新服务器置于认证之后等难以直接控制请求的场景，可以从本地目录加载更新，从而绕过服务器通信环节。

更新服务器协议规范（进阶）

有灰度发布、多发布渠道、认证保护等高级需求时，可自行实现 Squirrel 兼容更新服务器。Squirrel.Windows 与 Squirrel.Mac 客户端要求的响应格式不同，但可让同一服务端根据 process.platform 分发到不同端点，例如把 feed URL 构造为 ${server}/update/${process.platform}/${app.getVersion()}。

• Windows：客户端期望在端点 /RELEASES 子路径拿到最新构建的 RELEASES 产物。若 feed URL 为 https://your-deployment-url.com/update/win32/1.2.3，则该 URL 的 /RELEASES 端点应返回你希望下发版本的 RELEASES 内容。版本比较由 Squirrel.Windows 自行完成，因此即使无可用更新也应返回响应：

B0892F3C7AC91D72A6271FF36905FEF8FE993520 https://your-static.storage/your-app-1.2.3-full.nupkg 103298365

• macOS：有更新时，Squirrel.Mac 期望 feed URL 端点返回 JSON，其中 url 是必填项、映射到应用更新的 ZIP 归档，其余属性（name、notes、pub_date）均可选：

{
    "url": "https://your-static.storage/your-app-1.2.3-darwin.zip",
    "name": "1.2.3",
    "notes": "These are some release notes innit",
    "pub_date": "2024-09-18T12:29:53+01:00"
}

无更新可用时服务端应返回 HTTP 204 No Content。

小结：构建你的发布流水线

把四阶段串起来看，一条典型的生产发布流水线是：用 @electron/packager 或 Electron Forge 打包应用 → 产物以 app 目录或 app.asar 形式挂入 Electron 资源目录并完成品牌重塑 → 在 CI 中用 @electron/osx-sign（macOS）+ @electron/windows-sign（Windows）签名并公证/防 SmartScreen → 直下渠道直接上传安装包，商店渠道则分别按 MAS（沙盒 + MAS 专用构建）、AppX（electron-windows-store）、Snap（snapcraft）的差异化要求产出 → 最后配合静态存储、update.electronjs.org 或自建服务器把 RELEASES/releases.json 元数据与新版产物同步发布，让 autoUpdater 完成"检查—下载—提示重启"的闭环。

每个环节的更多细节都可以在本仓库 docs/tutorial/ 目录中找到对应专题文档，并配合 docs/api/auto-updater.md、docs/api/safe-storage.md 等 API 参考与 lib/browser/api/auto-updater/ 下的平台实现源码对照阅读。