「静默」不是替你点了重启

DevPeek 往往一开就是半天。代理挂着，Mock 和参数转换还在工作，列表里也留着刚才的请求。更新提示偏偏在这时跳出来，问你要不要立即重启。

我们不想做那种发现新版本就催着重启的更新器，也不打算在用户不知情时强制安装。这里说的「静默」很具体：后台检查版本、下载安装包；等一切准备好，再提示一次。只有用户点了「立即更新」，DevPeek 才会退出并替换文件。

重启省不掉，但等待下载的时间可以省掉，也不用让一个进度条占着主窗口。

updater 还在，应用已经不是原来的应用了

上一篇讲过现在的进程结构：Launcher 负责托盘和进程管理，Core 跑代理，Tauri Shell 只负责显示界面。关闭主窗口时，前两个进程仍会留在后台。

Electron 时代用的是 electron-updater，桌面主进程既是应用入口，也是更新入口。换壳后，这个前提不存在了。Tauri 也有 updater，但它解决的是 Tauri 应用自身的更新，没法顺手替我们协调外面的 Launcher 和 Core。

难点其实不在「把安装包下载下来」，而在下载完以后谁来收尾：

所以更新任务最后落到了 Launcher。它本来就在管理 Core 和 Shell，也不会随主窗口一起退出，由它来判断什么时候检查、什么时候通知、什么时候真正安装，进程关系最简单。

Windows 和 macOS 会在启动约一分半后检查一次，之后每隔几小时再检查。发现新版本后，安装包在后台下载并校验，不影响正在经过代理的流量。

包准备好后，托盘会显示「更新就绪」。可以立即安装，也可以关掉提示，等手头的联调结束再说。

点下「立即更新」后，Launcher 才开始停 Core 和 Shell，最后退出自己并启动安装。Windows 不再弹安装向导；macOS 替换应用后重新拉起托盘。这个过程中 DevPeek 会短暂离线，因为正在运行的程序不可能一边占着文件，一边安全地覆盖自己。

我们试过考虑差量更新，最后仍然选择完整安装包。v1.2.1 之后目录结构变化较大，差量补丁省下的流量有限，却会多出版本匹配、文件缺失和跨版本升级的问题。对目前的体量来说，整包更容易验证，也更容易把失败范围控制住。

还有一个只在代理工具里比较明显的问题：DevPeek 自己可能就是当前的系统代理。

如果检查和下载也读取系统代理设置，请求会先绕进 DevPeek，再由 DevPeek 发往更新服务器。平时这么走未必出错，但安装阶段 Core 会退出，这条路径随时会断。更麻烦的是，一旦更新逻辑本身依赖代理，就可能出现「为了更新先关代理，关了代理又下不完更新」的循环。

因此，更新请求会绕开系统代理，直接连接更新源。正式退出前，Launcher 还会先恢复系统代理设置，避免 Core 已经停了，浏览器却仍指向原来的本机端口。这个处理和正常退出时一致，相关设置见代理与 SSL 证书。

这套更新流程会随 1.3.0 提供，覆盖 Windows 和 macOS。

Lite 模式虽然在浏览器里使用界面，只要 Launcher 仍在运行，也能收到「更新就绪」提示。安装动作仍由 Launcher 完成，不是由浏览器更新桌面程序。关于页的手动检查也会继续保留。

版本发布后，如果遇到安装包已经下载完成、点击后却没有更新，或者重启后系统代理没有恢复，可以到 GitHub Discussions 留下系统版本，以及使用的是标准模式还是 Lite 模式。完整改动可查看 1.3.0 更新日志。