[bug] Linux In-app update is not working

快速结论：该报错出现在 Linux（如 Linux Mint）桌面版 LobeChat 点击应用内更新时，表现为下载完成后应用关闭又以旧版本重启，更新实际上从未被安装。优先排查方向是 Linux 下窗口全部关闭触发了进程退出，导致 quitAndInstall() 还没来得及调用。

适用环境：Desktop App (Electron)，操作系统为 Linux（报告者使用 Linux Mint，Issue 归类为 Other Linux），LobeChat 版本 2.2.16，部署平台为 Official Cloud。Issue 中未提供 Python、CUDA、PyTorch、显卡等信息。

最快修复方案：官方已确认这是 Linux 专属代码缺陷并提交 PR #19621 修复，修复版本号 Issue 中未给出。在修复版本可用之前，Issue 中给出的可行替代方案是：从 https://lobehub.com/downloads 下载最新的 .deb 包（Linux Mint 上大概率用的是 deb 包），覆盖安装当前版本可以就地升级并保留数据。

注意事项：覆盖安装 .deb 只能绕过问题，不会让应用内更新按钮恢复可用；PR #19621 同时也修复了 snap、tar.gz 以及未带 runtime 启动的 AppImage 完全无法自更新（检查更新会一直转圈）的问题，以及 Linux 菜单栏读不到更新状态、无法出现“Restart to update”的问题。这些关联修复均依赖新版本发布，Issue 中未给出具体版本号，请以实际发布为准。

问题场景

用户在 Linux（Linux Mint）上使用 LobeChat 桌面版（Electron），版本 2.2.16，通过应用内更新功能升级时触发问题：更新包已下载，但点击安装后应用关闭又重新打开，版本号仍然是旧的，更新没有生效。同样的操作在 Windows 上正常，因此用户误以为是打包或更新源的问题。

报错原文

[bug] Linux In-app update is not working

Issue 中没有贴出崩溃堆栈或终端报错，问题现象本身就是“点击更新后无任何实际安装行为”。

原因分析

维护者在 Issue 中复现并确认：这是 LobeChat 自身代码中 Linux 专属的缺陷，不是打包问题，也不是更新 feed 的问题。

UpdaterManager.installNow() 会先关闭所有窗口，然后用 100ms 的定时器把安装交给 electron-updater：

if (!isWindows) { /* close every window */ }
setTimeout(() => autoUpdater.quitAndInstall(true, true), 100);

关闭最后一个窗口会触发 window-all-closed，而 App.ts 的处理逻辑在 Windows 和 Linux 上都会在此处退出进程。于是 Linux 上进程在定时器触发前就已经消失：quitAndInstall() 从未被调用，下载好的安装包从未被安装，应用只会以旧版本重新启动。

其他平台因不同原因躲过了这个坑，这也解释了为什么 Windows 上一切正常：

Windows — installNow() 完全跳过关闭窗口的循环，window-all-closed 不会触发。
macOS — 该 handler 在 darwin 上不会退出进程，应用能撑到定时器触发。

同时也没有兜底：autoInstallOnAppQuit 为 false，因此 electron-updater 自身的退出安装逻辑也不会在退出时接管安装。

发布侧本身是健康的，不是原因：electron-builder.mjs 会产出 AppImage/deb/rpm，release workflow 会构建 Linux，v2.2.16 已发布的 latest-linux.yml 中列出了这三种产物。

环境排查

确认客户端类型为 Desktop App (Electron)，而不是浏览器访问的 Web 版。
确认操作系统为 Linux，并确认实际使用的安装包格式是 .deb、AppImage 还是 snap —— 这决定能否用覆盖安装方式绕过。
确认 LobeChat 版本：Issue 报告版本为 2.2.16，该版本确认存在此问题。
确认安装包来源：是否从 https://lobehub.com/downloads 等官方渠道获取，便于后续覆盖安装。
Issue 未涉及 Python、CUDA、PyTorch、显卡等依赖，无需排查这些项。

解决步骤

先观察现象以便定位：点击安装更新后，应用是“关闭后以同一版本重新打开”，还是“完全没有任何反应”。前者与本次诊断完全吻合；后者可能指向另一个独立问题，Issue 中维护者也在向报告者确认这一点。
在修复版本发布前，采用覆盖安装方式绕过：从 https://lobehub.com/downloads 下载最新的 .deb 包（Linux Mint 上大概率使用 deb 包）。
在现有安装之上安装该 .deb，实现就地升级，用户数据会被保留。
修复版本发布后，直接升级到包含 PR #19621 的版本，届时应用内更新应该可以正常工作。修复内容包含：新增 App.isInstallingUpdate 标志，在更新安装进行中时抑制 window-all-closed 的退出行为；外加 60 秒的保底退出，避免安装交接失败（缺少安装器路径、没有包管理器、pkexec/sudo 提示被拒绝）后留下一个无窗口的残留进程；同时补齐了两个 Linux 相关缺口。
若使用的是 snap、tar.gz 归档，或未带 runtime 启动的 AppImage，这些格式原本就没有 electron-updater 实现，checkForUpdates() 会返回 null 且不发出任何事件，导致“检查更新”一直转圈；修复后会明确提示该安装格式无法自更新，并给出下载页面链接。

验证方法

完成覆盖安装后，确认版本号已变为下载到的新版本，并且原有会话/配置数据仍然存在，即说明绕过方案生效。若升级到包含 PR #19621 的版本后再次点击应用内更新，预期应用能够正常完成安装并重启为新版本，Linux 下“检查更新”也不应再无限转圈，菜单栏中应能出现“Restart to update”入口。