1. 桌面端自动更新的核心痛点与方案选型做过 Electron 桌面应用的人多半都经历过这样一个尴尬时刻用户装的是三个月前的版本某个致命 bug 早就修好了但你就是没办法让他更新。用户不会主动去官网下载新安装包更不会卸载重装于是你只能眼睁睁看着老版本在用户机器上继续跑客服群里每天重复回答同一个问题。electron-vue 软件自动更新这件事本质上解决的就是“如何让已经装在用户电脑上的应用自己悄悄换成新版本”这个需求。我最早接触这个需求是在一个内部工具项目上当时团队只有五六个人觉得手动发安装包也没什么。结果用户量涨到几百之后每次发版都要在群里挨个通知还有人装错版本、装到一半失败、杀毒软件拦截……那段时间我几乎成了专职客服。后来痛定思痛把自动更新这套流程彻底跑通才算把这块石头放下。这篇文章就是把我踩过的坑、验证过的方案、以及那些文档里不会写的细节完整地摊开讲一遍。先说清楚这套东西适合谁看。如果你正在用 electron-vue 做桌面应用已经能正常打包出安装包但还没搞定自动更新那这篇就是给你写的。如果你用的是纯 Electron 或者 electron-react思路完全一样只是脚手架配置略有差异。哪怕你是刚接触桌面端开发的新手只要跟着把每一步的原理搞明白也能自己搭起来。自动更新这件事说穿了就三个核心问题新版本从哪来、怎么判断有新版本、下载完怎么装上去。围绕这三个问题业界主流方案其实就那么几种选错了后面全是坑所以第一部分我先把选型的逻辑讲透。1.1 为什么自动更新不能“想当然”地做很多人第一反应是我在应用启动的时候请求一个接口拿到最新版本号跟本地比一下不一样就弹窗让用户去下载。听起来没毛病但真做起来你会发现一堆问题。用户点了“去下载”之后呢跳浏览器那下载完还得手动安装体验割裂。直接应用内下载那下载到哪个目录、怎么校验完整性、下载中断怎么办、装的时候要不要关掉当前应用这些全是细节。更麻烦的是跨平台差异。Windows 上安装包是 exe 或 msimacOS 上是 dmg 或 zipLinux 上又是另一套。每个平台的安装机制、权限要求、签名校验都不一样。如果自己从零实现等于要维护三套逻辑工作量直接翻三倍。所以成熟的做法一定是借助专门的更新库把平台差异屏蔽掉我们只关心“有新版本就更新”这个业务逻辑。还有一个容易被忽略的点更新过程本身不能影响用户正在做的事。用户可能正在编辑文档、正在导出数据你突然弹个窗说“必须重启更新”人家心态直接崩了。所以好的自动更新应该是静默下载、择机安装下载在后台悄悄进行等用户下次主动关闭应用时再安装或者提示用户“更新已就绪重启即可生效”。这个体验设计比技术实现本身更考验人。1.2 主流方案对比谁更适合 electron-vue目前 Electron 生态里做自动更新绕不开的就是electron-updater这个库。它其实是electron-builder的配套组件而 electron-vue 项目默认的打包工具就是 electron-builder所以两者天然契合。我对比过几种常见方案直接上表格更清楚方案依赖打包工具跨平台支持配置复杂度适用场景electron-updaterelectron-builderWindows/macOS/Linux 全支持中等绝大多数 electron-vue 项目Electron 内置 autoUpdater无强依赖主要支持 macOS/Windows较高需要对接自建更新服务自研 HTTP 轮询 手动安装无需自己实现高特殊定制需求第三方商业更新服务无全平台低但收费企业级、预算充足electron-updater最大的优势是和 electron-builder 的产物无缝对接。你用 electron-builder 打包出来的latest.ymlWindows或latest-mac.ymlmacOS文件里面已经包含了版本号、文件哈希、下载地址等元信息electron-updater 直接读这个文件就能判断有没有新版本不需要你额外维护一套版本接口。这一点对中小团队来说太省事了。提示electron-updater 虽然好用但它对代码签名有要求。Windows 上如果安装包没有签名更新时可能被 SmartScreen 拦截macOS 上没签名的话更新后应用可能无法启动。这是新手最容易翻车的地方后面会专门讲。至于 Electron 内置的autoUpdater它更底层需要你自己搭建更新服务器、自己生成更新元数据灵活但麻烦。除非你有特殊需求比如更新源必须走内网、必须自己控制灰度否则没必要折腾。我个人的建议很直接electron-vue 项目无脑选 electron-updater把精力花在业务和体验上。1.3 更新流程的整体设计思路在动手写代码之前先把整个流程在脑子里过一遍这样后面每一步你都知道自己在干什么。一个完整的自动更新流程大致分这么几个阶段应用启动主进程初始化时创建更新检查器但不要立刻检查稍微延迟几秒避免和启动时的其他网络请求抢资源。检查更新向配置好的更新源请求版本元数据文件对比本地版本号。发现新版本如果有新版本根据配置决定是自动下载还是询问用户。后台下载下载过程中要能拿到进度方便在界面上展示进度条。下载完成校验文件完整性准备安装。安装重启用户确认后退出当前应用并安装新版本然后重新启动。这个流程里主进程负责所有更新逻辑渲染进程只负责展示状态和接收用户操作。为什么这么设计因为更新涉及文件读写、进程退出这些敏感操作放在渲染进程里既不安全也不方便。主进程通过 IPC 把更新状态推给渲染进程渲染进程再更新 UI这是 electron-vue 里最标准的做法。还有一点要提前想清楚更新源放哪里。常见的有几种选择——GitHub Releases、自己的对象存储比如各种云厂商的 OSS、自建静态文件服务器。GitHub Releases 最省事electron-builder 甚至支持一条命令直接发布但国内访问可能不稳定。自建服务器最可控但要自己处理文件上传和 CDN。我一般推荐对象存储 CDN的组合成本低、速度快、配置简单后面会讲具体怎么配。2. 环境搭建与核心依赖配置选型定了接下来就是动手。这一部分我把环境准备、依赖安装、打包配置这些基础工作讲清楚。别看这些是“体力活”配置错一个字段后面更新就是死活不生效而且报错信息往往很模糊排查起来能让人抓狂。所以基础一定要打牢。2.1 依赖安装与版本选择electron-vue 项目本身已经集成了 electron-builder但 electron-updater 需要单独安装。打开项目根目录执行npm install electron-updater --save或者用 yarnyarn add electron-updater这里有个版本匹配的坑要特别注意。electron-updater 的版本要和 electron-builder 的版本大致对应不能差太多。比如 electron-builder 是 24.xelectron-updater 最好也是 6.x 系列。如果版本差太远可能会出现元数据格式不兼容、更新检查失败等问题。我一般会在package.json里把这两个依赖的版本都锁定避免团队成员安装到不一致的版本。{ devDependencies: { electron-builder: ^24.6.4 }, dependencies: { electron-updater: ^6.1.7 } }注意 electron-updater 是运行时依赖要放在dependencies里不能放devDependencies。因为打包后应用运行时需要它如果放错位置打包出来的应用会报“找不到模块”。这个错误我见过太多次了新手特别容易踩。另外electron-vue 的模板比较老有些项目还在用 Electron 2.x 或 3.x这些老版本对 electron-updater 的支持有限。如果你的项目还在用很老的 Electron建议先升级到 13.x 以上否则后面会遇到各种奇怪的兼容问题。升级 Electron 本身也是个坑但那是另一个话题了这里不展开。2.2 electron-builder 打包配置详解自动更新的基础是打包产物要规范。electron-builder 的配置文件通常在package.json的build字段或者单独的electron-builder.yml。我习惯用单独的 yml 文件结构更清晰。下面是一个经过验证的配置示例appId: com.example.myapp productName: MyApp directories: output: dist buildResources: build files: - dist/electron/**/* - package.json win: target: - target: nsis arch: - x64 publish: - provider: generic url: https://your-cdn-domain.com/releases/ channel: latest mac: target: - target: dmg arch: - x64 - arm64 publish: - provider: generic url: https://your-cdn-domain.com/releases/ channel: latest linux: target: - AppImage publish: - provider: generic url: https://your-cdn-domain.com/releases/ channel: latest这里几个关键点逐个解释。appId是应用的唯一标识更新时用来匹配一旦确定就不要改改了会导致老版本认不出新版本。publish字段是核心它告诉 electron-builder 打包时把更新元数据里的下载地址指向哪里。provider: generic表示用普通的静态文件服务器也就是你把打包产物上传到那个 url 对应的目录就行。channel字段用于区分更新通道比如latest是稳定版beta是测试版。如果你想让一部分用户先尝鲜可以给他们发 beta 通道的包互不干扰。这个功能在做灰度发布时特别有用。注意url必须是HTTPS的。electron-updater 默认拒绝从 HTTP 源更新这是安全考虑。如果你的服务器只有 HTTP要么加证书要么在代码里显式允许不推荐。Windows 的nsistarget 是必须的因为 electron-updater 在 Windows 上依赖 NSIS 安装器的特定行为来实现静默更新。如果你打包成 portable 版本自动更新是用不了的。macOS 的dmg也是同理。Linux 的AppImage支持自动更新但 deb/rpm 包不支持这个要提前知道。2.3 更新元数据文件的生成逻辑打包完成后你会在dist目录下看到几个关键文件。Windows 上会生成latest.ymlmacOS 上生成latest-mac.ymlLinux 上生成latest-linux.yml。这些文件就是更新元数据electron-updater 检查更新时读的就是它们。以 Windows 的latest.yml为例内容大概长这样version: 1.2.0 files: - url: MyApp-Setup-1.2.0.exe sha512: xxxxxxxx... size: 78901234 path: MyApp-Setup-1.2.0.exe sha512: xxxxxxxx... releaseDate: 2024-01-15T10:30:00.000Zversion是新版本号files里列出了安装包的文件名、哈希和大小。electron-updater 拿到这个文件后先对比version和本地版本如果更新就根据url去下载安装包下载完用sha512校验完整性。哈希校验这一步非常重要它能防止下载过程中文件损坏或被篡改是更新可靠性的最后一道防线。所以你的发布流程应该是打包 → 把安装包和对应的 yml 文件一起上传到publish.url指定的目录。注意 yml 文件和安装包必须在同一个目录因为 yml 里的url是相对路径electron-updater 会基于 yml 的地址去拼接下载地址。这个细节如果搞错更新时会报 404。我见过有人把安装包放 CDNyml 放另一个地方结果怎么都更新不了。记住yml 和安装包同目录这是铁律。3. 主进程更新逻辑的完整实现基础配置搞定现在进入核心部分——在主进程里写更新逻辑。这部分代码不多但每一行都有讲究我把它拆成几个模块来讲方便你理解每一块在干什么。3.1 创建更新管理器与事件监听在 electron-vue 的主进程入口文件通常是src/main/index.js里引入 electron-updater 并创建更新管理器import { autoUpdater } from electron-updater import log from electron-log // 配置日志方便排查问题 autoUpdater.logger log autoUpdater.logger.transports.file.level info // 关键配置项 autoUpdater.autoDownload false // 先不自动下载等用户确认 autoUpdater.autoInstallOnAppQuit true // 退出时自动安装已下载的更新 autoUpdater.allowDowngrade false // 禁止降级这里有几个配置项需要重点说明。autoDownload设成false是我强烈推荐的因为自动下载会消耗用户流量尤其是安装包几十兆甚至上百兆的时候用户可能正在用手机热点你悄悄下载完人家流量就没了。设成false后发现新版本先问用户用户同意再下载体验更尊重人。autoInstallOnAppQuit设成true是个很聪明的设计。它的意思是如果更新已经下载好了但用户没点“立即重启”那么等用户下次正常关闭应用时自动安装更新。这样用户完全无感下次打开就是新版本了。这个配置能极大提升更新成功率。allowDowngrade设成false防止版本回退。正常情况下我们只往新版本更新如果因为某些原因比如服务器上放了旧版本的 yml导致检测到“新版本”其实是旧版本这个配置能拦住它避免用户被降级。接下来是事件监听这是整个更新逻辑的骨架autoUpdater.on(checking-for-update, () { sendStatusToWindow(checking) }) autoUpdater.on(update-available, (info) { sendStatusToWindow(available, info) }) autoUpdater.on(update-not-available, (info) { sendStatusToWindow(not-available, info) }) autoUpdater.on(download-progress, (progress) { sendStatusToWindow(progress, progress) }) autoUpdater.on(update-downloaded, (info) { sendStatusToWindow(downloaded, info) }) autoUpdater.on(error, (err) { sendStatusToWindow(error, err) })每个事件对应更新流程的一个阶段。checking-for-update是开始检查update-available是发现新版本update-not-available是已是最新download-progress是下载进度update-downloaded是下载完成error是出错了。渲染进程根据这些状态更新界面用户就能看到“正在检查”“发现新版本”“下载中 45%”“更新已就绪”这些提示。sendStatusToWindow是我自己封装的函数负责通过 IPC 把状态发给渲染进程。具体实现后面讲 IPC 通信时会说。3.2 检查更新的时机与触发方式检查更新不能太频繁也不能太懒。太频繁会给服务器压力也浪费用户流量太懒用户就享受不到及时更新。我的经验是应用启动后延迟 10 秒检查一次之后每隔 4 小时检查一次。启动延迟是为了避开应用启动时的资源竞争定时检查是为了让长时间开着的应用也能及时更新。app.on(ready, () { // 启动后延迟检查 setTimeout(() { autoUpdater.checkForUpdates() }, 10000) // 定时检查 setInterval(() { autoUpdater.checkForUpdates() }, 4 * 60 * 60 * 1000) })除了自动检查还要给用户一个手动检查的入口。在设置页面或者关于页面放一个“检查更新”按钮用户点了就立即检查。这个入口很重要因为有些用户就是喜欢手动控制你给他这个权力他反而更信任你的应用。手动检查的代码很简单就是再调一次checkForUpdates()。但要注意防止重复检查如果用户狂点按钮会发起多个请求。加个标志位或者用防抖处理一下let isChecking false function checkForUpdatesManually() { if (isChecking) return isChecking true autoUpdater.checkForUpdates().finally(() { isChecking false }) }实操心得检查更新的接口最好做缓存。如果用户量很大每次启动都请求 yml 文件服务器压力不小。可以在 CDN 层面设置较短的缓存时间比如 5 分钟既能保证及时性又能减轻源站压力。3.3 下载与安装的流程控制发现新版本后如果用户同意更新就调用autoUpdater.downloadUpdate()开始下载。下载过程中会持续触发download-progress事件我们可以拿到percent、bytesPerSecond、transferred、total这些数据在界面上展示进度条和速度。function startDownload() { autoUpdater.downloadUpdate().catch((err) { log.error(下载更新失败, err) }) }下载完成后触发update-downloaded事件。这时候不要立刻安装而是提示用户“更新已下载完成是否立即重启安装”。用户点“立即重启”就调用autoUpdater.quitAndInstall()这个函数会先关闭当前应用然后启动安装程序安装完自动重启。注意quitAndInstall有个参数isSilent和isForceRunAfter默认情况下安装过程是静默的安装完会自动启动应用。如果你想让用户看到安装界面可以传false但一般没必要。这里有个特别容易踩的坑quitAndInstall()在某些情况下会失败比如应用还有未保存的数据、有子进程没退出。所以调用之前最好先做一些清理工作比如关闭所有窗口、停止后台任务。我一般会先发一个事件给渲染进程让渲染进程提示用户保存工作确认后再调用。还有一个坑是开发环境下不能测试自动更新。因为开发环境的应用没有经过打包没有版本元数据checkForUpdates会直接报错。所以测试自动更新必须打包成正式安装包装到虚拟机或者另一台机器上测。这个流程比较麻烦但没办法自动更新就是这么个“打包才能测”的东西。4. 渲染进程交互与用户体验设计主进程的逻辑跑通了但用户看不到主进程他们只跟界面打交道。所以渲染进程这一层决定了用户对自动更新的实际感受。做得好的话用户几乎感觉不到更新的存在做得不好用户会觉得你的应用很烦。4.1 IPC 通信的桥接设计electron-vue 里主进程和渲染进程通过 IPC 通信。主进程用webContents.send发消息渲染进程用ipcRenderer.on接收。为了代码清晰我一般会定义一套状态协议用固定的字符串标识不同状态// 主进程 function sendStatusToWindow(status, data) { const windows BrowserWindow.getAllWindows() windows.forEach((win) { win.webContents.send(update-status, { status, data }) }) }渲染进程接收import { ipcRenderer } from electron ipcRenderer.on(update-status, (event, payload) { const { status, data } payload switch (status) { case checking: this.updateState 正在检查更新... break case available: this.updateState 发现新版本 ${data.version} this.showUpdateDialog true break case progress: this.updateState 下载中 ${Math.floor(data.percent)}% this.progress data.percent break case downloaded: this.updateState 更新已就绪重启即可生效 this.showRestartButton true break case error: this.updateState 更新失败请稍后重试 break } })这套协议的好处是主进程和渲染进程解耦。主进程只管发状态渲染进程只管根据状态渲染两边可以独立开发和测试。如果以后要加新的状态比如“下载暂停”只要在两边各加一个 case 就行不影响其他逻辑。注意IPC 通信的数据必须是可序列化的。Error 对象不能直接传要转成字符串或者普通对象。我一般会把错误信息转成{ message, stack }这样的结构再传。4.2 更新提示的界面设计原则更新提示的界面核心原则是不打扰、不强迫、给选择。我见过一些应用一发现新版本就弹个模态框挡住用户所有操作必须点“更新”才能继续用。这种设计非常招人烦用户会觉得被绑架了。我的做法是发现新版本时在界面角落弹一个非模态的提示条写着“发现新版本 v1.2.0是否更新”旁边有“更新”和“稍后”两个按钮。用户点“稍后”提示条消失过一段时间再提醒点“更新”才开始下载。下载过程中提示条变成进度条用户可以继续正常使用应用不受影响。下载完成后提示条变成“更新已就绪重启应用即可生效”按钮变成“立即重启”和“稍后重启”。用户点“稍后重启”等他下次关闭应用时自动安装。整个过程用户始终有控制权体验就舒服多了。对于强制更新的场景比如修复了严重安全漏洞可以做得更强硬一些比如弹模态框、不允许关闭。但这种情况要慎用一年到头也用不了几次。滥用强制更新会严重损害用户信任。4.3 更新日志与版本说明的展示用户决定要不要更新很大程度上取决于更新了什么。如果只是“修复了一些已知问题”用户可能懒得更新如果是“新增了 XX 功能”用户可能就有兴趣了。所以更新提示里最好带上更新日志。electron-updater 的update-available事件里info对象包含releaseNotes字段这个字段来自你打包时配置的 release notes。可以在electron-builder.yml里配置或者发布时通过命令行传入。渲染进程拿到后展示在提示框里case available: this.updateState 发现新版本 ${data.version} this.releaseNotes data.releaseNotes || 本次更新包含若干优化和修复 this.showUpdateDialog true break更新日志的写法也有讲究。不要写“优化了用户体验”这种空话要具体比如“修复了导出 PDF 时中文乱码的问题”“新增了批量导入功能”。用户看到具体的改进更新的意愿会高很多。5. 发布流程与服务器配置实战代码写完了接下来是发布。自动更新的“最后一公里”其实是发布流程——你得把打包产物正确地传到服务器上让 electron-updater 能读到。这一步如果没做好前面代码写得再漂亮也白搭。5.1 打包产物的组织与上传打包命令很简单npm run buildelectron-vue 项目一般会先编译渲染进程再用 electron-builder 打包。打包完成后dist目录下会有安装包和 yml 文件。以 Windows 为例你会看到MyApp-Setup-1.2.0.exe安装包MyApp-Setup-1.2.0.exe.blockmap增量更新用的块映射文件latest.yml更新元数据这三个文件要一起上传到publish.url对应的目录。.blockmap文件是给增量更新用的electron-updater 支持只下载变化的部分能大幅减少下载量。比如从 1.1.0 更新到 1.2.0如果只有少量代码变化可能只需要下载几兆而不是完整的几十兆。这个功能默认开启前提是 blockmap 文件存在。上传方式取决于你的服务器类型。如果是对象存储用对应的 CLI 工具或者 SDK 上传如果是自建服务器用 scp 或者 rsync。我一般会写一个发布脚本把打包、上传、验证串起来#!/bin/bash set -e VERSION$(node -p require(./package.json).version) echo 开始发布版本 $VERSION # 打包 npm run build # 上传到对象存储以某云 CLI 为例 ossutil cp dist/latest.yml oss://my-bucket/releases/latest.yml ossutil cp dist/*.exe oss://my-bucket/releases/ ossutil cp dist/*.blockmap oss://my-bucket/releases/ echo 发布完成脚本化发布的好处是减少人为失误。手动上传很容易漏文件、传错目录脚本跑一遍就不会错。而且脚本可以纳入 CI/CD打 tag 自动发布效率更高。5.2 更新服务器的目录结构设计服务器上的目录结构我建议按平台 通道来组织releases/ ├── win/ │ ├── latest.yml │ ├── MyApp-Setup-1.2.0.exe │ └── MyApp-Setup-1.2.0.exe.blockmap ├── mac/ │ ├── latest-mac.yml │ └── MyApp-1.2.0.dmg └── linux/ ├── latest-linux.yml └── MyApp-1.2.0.AppImage然后在electron-builder.yml里针对每个平台配置不同的 urlwin: publish: - provider: generic url: https://your-cdn.com/releases/win/ mac: publish: - provider: generic url: https://your-cdn.com/releases/mac/ linux: publish: - provider: generic url: https://your-cdn.com/releases/linux/这样各平台的更新互不干扰也方便单独管理。如果要做 beta 通道再加一层beta/目录代码里通过autoUpdater.channel beta切换。实操心得旧版本的安装包不要急着删。有些用户可能跨了好几个版本才更新electron-updater 的增量更新需要旧版本的 blockmap 文件做对比。如果删了用户就只能全量下载。我一般会保留最近 5 个版本的安装包更早的再清理。5.3 灰度发布与回滚策略新版本发布出去万一有严重 bug 怎么办所以发布不能“一刀切”要有灰度和回滚的能力。灰度发布的思路是先让一小部分用户更新到新版本观察一段时间没问题再全量放开。实现方式有几种。一种是按用户 ID 哈希比如用户 ID 尾号为 0-9 的用户先更新其他用户暂时看不到新版本。这需要在检查更新时做判断如果用户不在灰度范围就返回“已是最新”。另一种更简单的方式是用不同的更新通道。先发一个 beta 通道的包让内部用户或者愿意尝鲜的用户更新稳定后再把同样的包发到 latest 通道。这种方式不需要改代码只靠发布流程控制更灵活。回滚就更简单了如果新版本出问题把服务器上的latest.yml换回旧版本的即可。但要注意allowDowngrade默认是false用户已经更新到新版本后不会自动降级。所以回滚只对还没更新的用户有效。已经更新的用户要么发一个修复版本要么引导他们手动重装。这也是为什么灰度发布很重要——把问题控制在最小范围。6. 常见问题排查与避坑指南自动更新这套东西坑特别多而且报错信息往往很模糊。这一部分我把自己和团队踩过的坑整理出来做成速查表希望能帮你少走弯路。6.1 更新检查失败的典型原因现象可能原因排查方法一直提示“已是最新”版本号没变 / yml 没更新检查 package.json 的 version 和服务器 yml 的 version报 404 错误yml 或安装包路径不对浏览器直接访问 yml 的 url看能否下载报证书错误url 是 HTTP 或证书过期确认 url 是 HTTPS 且证书有效报解析错误yml 格式不对用 yaml 校验工具检查 yml 文件检查超时网络不通或服务器慢用 curl 测试服务器响应时间最常见的就是版本号没变。electron-builder 打包时版本号取自package.json的version字段。如果你改了代码但忘了改版本号打出来的包版本还是旧的electron-updater 一对比发现“一样”就认为没有更新。所以每次发版必须改版本号这是铁律。我一般用npm version patch命令自动改省得忘。另一个高频问题是yml 文件没上传或者上传到了错误的位置。electron-updater 请求的是publish.url加上latest.yml比如https://your-cdn.com/releases/win/latest.yml。如果这个地址访问不到更新就失败。排查时直接用浏览器访问这个地址能下载到 yml 就说明路径对了。6.2 下载中断与安装失败的应对下载过程中断原因可能是网络波动、服务器限速、用户主动取消。electron-updater 本身有重试机制但默认重试次数有限。如果下载失败error事件会触发我们可以在界面上提示用户“下载失败点击重试”然后重新调用downloadUpdate()。安装失败的情况更复杂。Windows 上常见的是权限不足安装程序需要管理员权限但当前用户没有。这种情况 electron-updater 会报错但错误信息不直观。解决办法是在打包时配置 NSIS 的perMachine选项或者提示用户以管理员身份运行。macOS 上安装失败多半是签名问题。如果应用没有正确签名更新后系统会拒绝启动。所以 macOS 应用必须签名这是硬性要求。签名需要苹果开发者账号个人开发者也能申请流程稍微麻烦点但为了自动更新必须做。还有一个隐蔽的坑是杀毒软件拦截。某些杀毒软件会把自动更新行为当成可疑操作拦截安装包的下载或执行。这种情况用户往往不知道发生了什么只觉得“更新没反应”。解决办法是给安装包做代码签名签过名的文件被杀毒软件误报的概率会低很多。6.3 开发环境与生产环境的差异处理前面提过开发环境下不能测试自动更新。但我们可以做一些模拟方便调试界面逻辑。比如在开发环境下手动触发update-available事件让界面显示更新提示这样就能调试 UI 了if (process.env.NODE_ENV development) { // 模拟发现新版本 setTimeout(() { sendStatusToWindow(available, { version: 9.9.9, releaseNotes: 测试更新 }) }, 3000) }这样不用打包就能看到更新提示长什么样调样式很方便。但真正的下载和安装流程还是得打包测试。测试自动更新的标准流程是先装一个旧版本比如 1.0.0然后发布一个新版本1.1.0打开旧版本应用看它能不能检测到并成功更新。这个过程最好在虚拟机里做因为更新会卸载重装在主力机上测容易把环境搞乱。我一般用 Windows 虚拟机测 Windows 更新用 macOS 虚拟机测 macOS 更新互不影响。提示测试时把检查更新的延迟调短一点比如 3 秒不然每次都要等 10 秒才能看到效果效率太低。发布前记得改回来。6.4 增量更新不生效的排查增量更新能大幅减少下载量但有时候会发现它没生效用户还是全量下载。原因通常是blockmap 文件缺失或版本不匹配。electron-updater 做增量更新时需要旧版本的 blockmap和新版本的 blockmap做对比。如果服务器上旧版本的 blockmap 被删了或者新旧版本的 blockmap 对不上就只能全量下载。所以前面说的“保留最近几个版本的安装包”很重要其实保留的是 blockmap 文件。另外如果你在打包时改了compression配置比如从normal改成maximumblockmap 的生成方式会变可能导致增量更新失效。这个配置一旦确定尽量不要改。排查增量更新是否生效可以看下载时的日志。如果日志里出现Downloaded blockmap和Differential download之类的字样说明增量更新生效了如果直接是Downloading完整文件那就是全量。日志级别设成debug能看到更详细的信息。7. 进阶优化与长期维护建议基础功能跑通后还有一些优化能让自动更新更稳、更快、更省心。这一部分分享一些进阶经验适合已经上线、有一定用户量的项目。7.1 更新成功率的监控与统计自动更新最怕的是“悄悄失败”——用户以为更新了其实没有或者更新到一半卡住用户直接卸载了。所以监控更新成功率很重要。我的做法是在关键节点埋点检查更新、开始下载、下载完成、安装成功每个节点上报一次。这样就能算出“检查到更新的用户里有多少成功安装了”。上报数据可以发到自己的统计接口也可以用现成的统计服务。关键是区分平台和版本因为不同平台的失败率可能差很多。比如 Windows 的失败率明显高于 macOS因为 Windows 的权限和杀毒软件问题更多。发现某个平台失败率高就针对性排查。还有一个指标是更新覆盖率也就是有多少用户最终更新到了最新版本。这个指标反映了更新的“渗透力”。如果覆盖率长期偏低说明更新提示不够明显或者用户主动拒绝更新。可以考虑调整提示策略比如把“稍后”按钮做得不那么显眼或者对长期不更新的用户做更强的提醒。7.2 大版本更新的特殊处理小版本更新比如 1.1.0 到 1.1.1通常无感更新就行但大版本更新比如 1.x 到 2.x往往涉及数据结构变化、配置文件格式变化直接更新可能导致用户数据丢失或应用崩溃。这种情况需要特殊处理。我的做法是大版本更新时在应用启动时做数据迁移。检测到是从旧版本升级上来的就把旧格式的数据转换成新格式。迁移逻辑要写得健壮考虑各种边界情况最好有备份机制迁移失败能回滚。另外大版本更新可以做得更“隆重”一些比如弹一个专门的欢迎页介绍新功能引导用户熟悉新界面。这样用户不会因为界面大变而感到困惑反而有新鲜感。7.3 长期维护的版本管理策略项目跑久了版本会越来越多管理起来容易乱。我建议采用语义化版本SemVer也就是主版本.次版本.修订号的格式。主版本号在有不兼容改动时递增次版本号在新增功能时递增修订号在修 bug 时递增。这样用户一看版本号就知道这次更新大概是什么性质。发布节奏上我一般保持每两周一个修订版本每月一个次版本。修订版本只修 bug风险低可以全量推送次版本有新功能先灰度再全量。主版本一年最多一两次提前做好迁移方案。还有一点是更新日志的维护。每次发版都认真写更新日志日积月累就是一份完整的项目历史。用户看更新日志能感受到项目在持续迭代对应用的信任度也会提升。更新日志可以放在应用内的“关于”页面也可以同步到官网一举两得。7.4 安全性与合规性考量自动更新涉及下载和执行外部文件安全性必须重视。HTTPS 是底线防止中间人攻击。哈希校验是必须的electron-updater 默认会校验 sha512不要关掉这个功能。代码签名能进一步保证安装包来源可信Windows 和 macOS 都建议做。另外更新源服务器要做好访问控制防止被恶意利用。虽然更新文件本身是公开的但服务器配置不当可能被当成文件托管服务滥用。设置合理的带宽限制和防盗链策略能避免不必要的成本。从合规角度自动更新涉及用户知情权。发现新版本时应该明确告知用户下载和安装前应该获得用户同意除非是紧急安全更新。更新日志要真实准确不能夸大或隐瞒。这些细节做好了用户才会信任你的更新机制。我个人在实际操作中的体会是自动更新这件事技术实现只占三成剩下七成是流程规范和用户体验。代码写得再漂亮如果发布流程混乱、更新提示烦人用户照样不买账。反过来哪怕技术实现朴素一点只要发布规范、提示友好、更新可靠用户就会觉得你的应用很专业。这套东西搭起来之后后续每次发版都变成一件轻松的事再也不用在群里挨个通知了。