6.3 自动更新策略与 electron-updater 实现

6.3 自动更新策略与 electron-updater 实现

本节摘要：自动更新是 Electron 应用"远程下发可执行代码"的最高权限能力，工程上要同时做好体验（静默检查、差量下载、平滑重启）与安全（更新源可信、签名校验、传输加密）。本节讲 electron-updater 的完整接入、更新流程的生命周期管理、差量更新与回滚策略，以及一条必须守住的安全红线。

先想清楚：更新即远程执行

第四章辛苦建立的安全体系，防的是"攻击者在渲染进程执行代码"。而自动更新天然是"从网络下载可执行内容并在用户机器上运行"——它就是那个最高权限通道，只不过钥匙在你手里。所以更新通道的安全设计原则只有一条：确保通道里流动的永远是你签过名的内容。具体拆成三道保证：更新元数据走加密传输；下载的安装包验过签名才允许安装；更新源（静态服务器或发布渠道）的账号与凭证按生产密钥规格保管。三道缺一，第四章的所有防线都可以被一次伪造更新绕过。

electron-updater 的接入

以最常见的"静态服务器 + 更新元数据文件"模式为例，接入分三步。第一步，打包时开启更新元数据生成（6.1 节的 builder 配置会随产物吐出元数据文件与最新版本描述文件）。第二步，主进程集成检查逻辑。第三步，处理更新事件流与界面反馈：

// 主进程：自动更新的核心流程
const { autoUpdater } = require('electron-updater');
const { ipcMain, BrowserWindow } = require('electron');

function setupAutoUpdater(win) {
  autoUpdater.autoDownload = true;              // 检测到新版自动下载
  autoUpdater.autoInstallOnAppQuit = true;      // 退出时安装，不打断工作

  autoUpdater.on('update-available', (info) => {
    win.webContents.send('update:available', info.version);
  });
  autoUpdater.on('download-progress', (p) => {
    win.webContents.send('update:progress', Math.round(p.percent)); // 页面进度条
  });
  autoUpdater.on('update-downloaded', (info) => {
    win.webContents.send('update:ready', info.version);
  });
  autoUpdater.on('error', (err) => {
    console.warn('更新出错（不影响使用）:', err.message); // 更新失败静默降级
  });

  // 启动后延迟检查 + 定时复查
  setTimeout(() => autoUpdater.checkForUpdates(), 30_000);
  setInterval(() => autoUpdater.checkForUpdates(), 4 * 60 * 60_000);
}

// 页面请求"立即重启安装"的通道
ipcMain.handle('update:install', () => autoUpdater.quitAndInstall());
​

// 页面侧：更新提示的界面逻辑（经 preload 桥调用）
async function checkUpdateUI() {
  await bridge.onUpdateReady((version) => {
    showToast(`新版本 ${version} 已就绪`, {
      action: '立即重启',
      onClick: () => bridge.installUpdate()   // 用户主动选择时机
    });
  });
}
​

几处工程细节值得强调。检查时机要错峰：启动后延迟半分钟再查（别跟 5.2 节的启动优化抢时间），之后定时复查。失败要静默降级：更新是后台服务，失败绝不该打断用户，静默记录、下次再试。安装时机尊重用户：下载完不强制重启，等用户自己退出应用时装上（autoInstallOnAppQuit 的意义），急迫的安全修复才用更强硬的提示。

差量与回滚

全量更新的安装包上百兆，对自家带宽与用户流量都是负担。差量更新只下载新旧版本的差异部分，在用户机器上合成新包——体积经常能压到全量的几分之一，配合高频发版节奏收益显著。builder 系工具链对差量有原生支持，服务端要多存一份差量文件供按版本跳跃下载。

回滚是更新的另一面：新版本出了严重问题，最短的止损路径是什么？没有回滚机制时，只能紧急发新版、等用户再走一遍更新——慢半拍。基础回滚可以这样做：更新元数据里永远保留上个稳定版本的下载地址，服务端一个开关即可把"最新版"指回去；配合灰度发布（新版本先放给一小部分用户），问题在面扩大之前就被挡住。

案例：一次翻车后的更新体系重建

背景：一个工具应用早期图省事，更新包放在未加密的静态地址、也没做版本灰度。一次新版引入了数据迁移缺陷，全量推送后大量用户升级即丢配置，客服爆炸，而团队毫无回滚手段，只能紧急修复再全量推新版——二次翻车的边缘。

操作：重建分四项。更新地址全站换加密传输并接入 CDN；更新包签名校验设为硬门槛（验签失败拒绝安装并上报）；发布流程加灰度：新版本先推给百分之五的内测通道用户，观察一整天核心指标无异常再放量；元数据保留上一个稳定版，运营侧一个配置即可回切。

结果：体系运转后的两次事故里，灰度阶段就发现了问题，回滚开关分钟级生效，大众用户无感知。客服侧从此再没发生过"更新即事故"。

解读：这个案例说明更新体系的成熟度标志不是"能更新"，而是**"坏了能多快收回来"**。灰度加回滚的成本很低，缺的往往是事前想象——没人愿意在事故复盘会上第一次思考回滚。变式：对数据迁移类的高危变更，还可以在应用内做迁移前备份（升级前把用户数据复制一份），把"更新安全"延伸到数据层。

本节要点回顾

• 定位：更新是最高权限通道，安全红线是"通道里只有自家签名内容"；
• 接入三步：元数据生成、主进程集成、事件流接界面；
• 节奏设计：错峰检查、失败静默、安装时机尊重用户；
• 差量与回滚：差量省带宽，回滚止损，灰度让问题死在小池子里；
• 成熟度标志：不是能更新，而是坏了能多快收回来。

更新通道建好，最后一节解决分发环节的物理约束：安装包体积——ASAR 归档与瘦身清单。