8.3 自动更新机制

用户装上了 1.0，本周你修了一个让笔记丢失的严重 bug——怎么让所有用户在一周内用上 1.1？靠公告与下载链接，转化率惨不忍睹；靠自动更新，用户无感升级。本节把 updater 的密钥体系、更新清单、应用内检查安装装完整，顺手把发布流程固化成清单。读完本节，发版从紧张动作变成流水线。

先立密钥：更新体系的地基

updater 的信任模型在 6.4 立过：应用内置公钥，更新包必须带对应私钥的签名——服务器被攻破也推不动伪造更新。一切从生成密钥对开始：

npm run tauri signer generate -w ~/.tauki/travel-notes.key
# 输出两样：私钥文件路径、公钥字符串（记下公钥内容）
# 提示设置私钥口令，发布机用环境变量提供
​

三条保管纪律：私钥只在发布环境存在——CI 的 secrets 或专用的发布机，绝不进代码仓库与个人笔记本；公钥写进应用配置随 1.0 出厂——此后每一版更新都由它验签；私钥丢失不可挽回——丢钥只能换新钥对发新版，老版本用户收不到那次更新（它们只认旧公钥）。密钥生成必须在第一次发布之前完成，这是本节唯一"过期不候"的操作。

配置与清单：两端各一份

应用侧配置 plugins 段（pubkey 填生成时的公钥字符串）：

{
  "plugins": {
    "updater": {
      "endpoints": ["你的更新清单地址，json 形态"],
      "pubkey": "生成密钥时输出的公钥内容"
    }
  }
}
​

服务器侧的更新清单是极简 JSON，按平台给出下载地址与签名：

{
  "version": "1.1.0",
  "platforms": {
    "windows-x86_64": {
      "signature": "更新包签名内容",
      "url": "该平台更新包的下载地址"
    },
    "darwin-aarch64": {
      "signature": "更新包签名内容",
      "url": "该平台更新包的下载地址"
    },
    "linux-x86_64": {
      "signature": "更新包签名内容",
      "url": "该平台更新包的下载地址"
    }
  }
}
​

构建时（8.1 阶段四）每个安装包旁会生成配对的签名文件，发布作业把"包、签名、清单"三件套同步上传——清单里的版本号必须大于线上版本，比较按语义化版本规则。

应用侧：检查、下载、安装

官方 updater 插件的前端 API 三步走：

import { check } from '@tauri-apps/plugin-updater';
import { relaunch } from '@tauri-apps/plugin-process';

export async function checkAndInstall(auto = false) {
  const update = await check(); // 请求清单，比较版本
  if (!update) {
    if (!auto) showTip('已是最新版本');
    return;
  }
  // 非 auto 时先询问用户；auto 是启动时的静默检查
  if (auto || (await confirmUpdate(update.version))) {
    await update.downloadAndInstall((event) => {
      // 进度事件：驱动更新进度条
    });
    await relaunch(); // 安装完重启进新版本
  }
}
​

// Builder 上挂 process 插件（relaunch 依赖）与 updater 插件
tauri::Builder::default()
    .plugin(tauri_plugin_process::init())
    .plugin(tauri_plugin_updater::Builder::new().build())
    .run(tauri::generate_context!())
    .unwrap();
​

体验设计三个决策点：检查时机——启动后延迟静默检查（别拖慢启动，8.4 的启动链路里没有它的一席）加设置页手动检查双入口；询问策略——功能更新问一声再装，安全修复可直装（配合 6.4 的更新签名，直装的风险是有底的）；失败兜底——下载中断、验签失败要给明确提示与重试入口，更新失败的用户是最焦虑的用户。

清单托管与灰度：越简单的越可靠

清单本质是一个静态 JSON 文件，托管选型因此可以极简：对象存储加 CDN、静态站点托管、甚至仓库的发布附件都够用——它不需要服务端逻辑，需要的是永远可访问与版本可回改。唯一要留意的是缓存：CDN 对清单的缓存时间要短（分钟级），否则"包已上传、用户三天拿不到清单"这种事会成为玄学故障；有条件就给清单 URL 带上内容摘要做缓存穿透。

再往上是灰度发布。updater 本身不带灰度，但清单是自己的，做法就灵活：激进方案是双清单双端点——按用户标识把一部分用户指到预发清单，跑一周再全量切换；更常用的简化版是分平台错峰——桌面三平台的清单分三次改，先放 Linux（问题暴露最充分），确认无恙再放 Windows 与 macOS。还有一种特殊更新值得单独立规：强制更新。判据只有两条——数据格式发生不兼容变更（旧版继续跑会写坏数据）、出现正在被利用的安全漏洞；其余更新一律走常规询问。强制更新的实现也朴素：应用启动时拿到清单版本与自己的比较，低于最低可用版本就拒绝进入主界面——这一逻辑要写在芯侧，前端判断可被绕过。

完整的发布流程清单

时序图固化成 checklist：构建产包带签名、上传包与签名、更新清单改版本、线上验证一次真实检查、记录本次版本号。最后一步"线上验证"最常被跳过也最不该省——发版后在自己机器上（或清缓存后）走一遍检查安装，确认清单生效。回滚预案一并想好：清单回指旧版是标准回滚手法——把清单的版本与地址改回上一版，已升级用户不受影响，未升级用户暂停在旧版。

本节要点回顾

• 密钥先行：首次发布前生成密钥对，公钥随 1.0 出厂，私钥只在发布环境；
• 两端各一份：应用配置 endpoints 加 pubkey，服务器清单给版本、地址、签名；
• 三步 API：check 比较、downloadAndInstall 带进度、relaunch 重启；process 插件必挂；
• 体验三决策：延迟静默检查、按更新类型选询问策略、失败给重试入口；
• 发布清单：包与签名与清单同发、线上验证、回滚靠清单回指旧版。

交付循环建好了。最后一关立口碑：启动、内存与包体的性能验收。