sidecar崩溃后前端怎么续命 重启策略与状态保留chayuan-desktop 桌面单机版的前端是 React 跑在 Tauri webview 里后端是 Python sidecar 跑在另一个进程。两个进程通过本地 HTTP 通信。sidecar 这一边万一崩了前端要怎么活下来不让用户重开应用是 免费开源的AI软件 做得稳的关键之一。这一篇讲 chayuan-desktop 的崩溃处理策略。先看 sidecar 崩溃的几种典型原因。第一种是模型权重文件被破坏加载时抛异常第二种是 SQLite 文件锁冲突长事务死锁第三种是依赖的第三方服务比如外部 Milvus、外部 LLM 厂商连接失败导致内部异常未捕获第四种是用户上传一份特殊格式文件解析逻辑没覆盖该格式触发异常第五种是 OOM单机版内存吃光导致 OS 杀进程第六种是被外部杀毒软件干掉。第一道防线在 sidecar 内部。FastAPI 的全局异常处理 hook 会捕获所有未处理异常转成 5xx 响应返回给客户端避免进程整体崩溃。常见的业务异常会被识别出来转成具体的错误码比如 RAG 入库失败、模型调用失败、KB 不存在等前端能据此给用户友好提示。第二道防线在 Tauri 主进程。如果 sidecar 真的退出了Tauri 心跳监控会在几秒内发现启动重启逻辑。重启之前先检查上次崩溃原因看 server.log 最后几行如果是 OOM 或 segfault 这种系统级问题先告知用户再询问是否重启。一般业务异常会自动重启不打扰用户。重启过程中前端怎么处理。React 应用接到 fetch 请求失败识别出是 sidecar 不可用进入降级模式把当前对话框的输入禁用顶部显示一个状态条 后端正在恢复请稍候同时启动一个轮询每秒检查 /health 是否回来。sidecar 重启完成后状态条变绿输入恢复正在打字的内容不会丢。状态保留是这一步的关键。前端的核心状态在两个地方当前对话的消息列表包括已发送和正在流式接收的、用户的输入草稿。这两份状态都在 React 应用内存里崩溃恢复时不会清。流式接收中的回答如果中途断掉会标记为 中断给用户一个 重试 按钮重新发起同一条请求即可。数据层的状态保留。sidecar 崩溃时正在写的对话历史可能有部分丢失。SQLite 默认开了 WAL 模式写入是先写日志再 checkpoint崩溃后启动会自动 recover已 commit 的写入不丢。未 commit 的比如流式回答还没结束会丢但前端已经在内存里有副本下次发送时会重新落库。外部依赖的崩溃隔离。模型供应商失败、外部向量库失败、外部 SQL 数据库失败这些都不应该让 sidecar 整体崩溃。chayuan-desktop 在每个 adapter 内部做了超时和 try-catch单一外部源失败只会让对应的查询返回 error整个流程其他源继续正常工作。比如多 KB 查询里某个外部 Milvus 挂了其他 sqlite-vec 库的结果照样返回。文件锁冲突的特别处理。OneDrive、坚果云这种同步软件会偶尔锁住 SQLite 文件触发崩溃。chayuan-desktop 检测到这种特定异常会重试三次仍失败的话给用户一个提示 数据目录被外部进程锁定建议把 CHAYUAN_ROOT 移到不被同步的目录。崩溃日志的可观测性。每次崩溃都会写一段 crash 日志到 CHAYUAN_ROOT/logs/crash-YYYYMMDD-HHMMSS.log包括 traceback、当时的请求上下文、内存快照。这个文件用户可以贴给社区或者发反馈。日志默认保留最近 10 份超过自动清理。WPS AI 插件 chayuan-wps 在 sidecar 崩溃时同样会失效。加载项侧也实现了类似的降级模式发起请求失败后显示 后端连接中断 状态等 sidecar 恢复后自动重连。这样在 WPS 文字里不会因为后端崩溃而中断写作流程。国产化支持下的特殊场景。麒麟 UOS 上偶尔出现 sidecar 因为系统休眠唤醒后端口绑定失败的情况对应处理是唤醒后做一次端口探测重启。loongarch64 平台上 PyInstaller 二进制启动慢重启时间需要更长容忍度。崩溃恢复机制不是设计出来给用户看的而是用户压根不应该感知它的存在。chayuan-desktop 在这件事上的目标是sidecar 偶尔崩了用户继续打字几秒之后又能正常工作对话历史不丢模型钥匙不丢。这才是 免费开源的AI软件 桌面单机版应有的稳态。