deepseek-harness跨平台桌面端二开项目（四）安装完点“启动应用“却没反应？背后是 sidecar 的冷启动预算与杀软博弈

（四）安装完点"启动应用"却没反应？背后是 sidecar 的冷启动预算与杀软博弈

承接系列前两篇。如果你把一个"壳 + sidecar 子进程"的桌面应用打包出去，很可能会撞上我这个真实翻车：第一次装完勾选"启动应用"，窗口迟迟不出来甚至报错；但你关掉重开，它又好好的。这篇讲清楚根因、修法，以及它牵引出的跨平台打包与"安装快不快"的取舍。

现象：安装后自启失败，快捷方式却正常

安装向导勾选"完成后启动" → 报错（有时是"sidecar did not start"），体验很糟；
之后手动双击快捷方式 → 一切正常。

外壳看起来像玄学。其实两条路径用的是同一套代码、同一个绝对路径 ，区别只在时机：刚装完的那一下，正是最坏的冷启动场景。

根因：冷启动预算设太紧了

sidecar 是一个独立进程，壳要等它就绪才能 loadURL 窗口。就绪靠健康探测 ：轮询 POST /api/host.describe 直到返回 2xx。它有一个超时预算------超时就判定失败、弹错误框。

最初我给打包模式设了 30 秒：

ts 复制代码

const PROBE_TIMEOUT_MS_PACKAGED = 30_000

而 dev 模式因为要经 tsx 把整个 profile 跑凉，给的是 120 秒。结果真实机器打了我脸：刚安装的那一刻，杀毒软件正在实时扫描整个 sidecar 载荷（几万个小文件 + 一个 Node 运行时），冷启动完整 web 配置远超过 30 秒。于是它输给了预算------报错。等你手动再开，文件已被杀软扫描/缓存过，冷启动顺利跑进 30 秒内。

修法就一行------把打包模式预算拉到和 dev 一致：

ts 复制代码

const PROBE_TIMEOUT_MS_DEV = 120_000
const PROBE_TIMEOUT_MS_PACKAGED = 120_000

调预算的同时，注释也要跟着说清楚"为什么"，否则后来人会改回来重蹈覆辙：冷启动可能远超 30 秒------源码侧要跑热整个 profile，刚装好的打包载荷还要过一遍实时杀软。

这里的"慢"其实有两层

顺着"安装体验"往下想，你会发现两个不同的"慢"要分开治：

探测超时慢（错误）：上面已经修好------给足预算而不是压时间。
安装本身慢（体量） ：安装包 180 MB、解压约 3.4 万个小文件，安装确实要花时间。这是体量结构决定的，不是配置 bug。真要根治就得改成"安装只写一个归档、首次启动再解压"，但那是把安装的慢挪到首次启动，且要重写解压/进度/容错逻辑------是取舍，不是免费午餐。

引出的一课：跨平台打包的架构绑定

"打包模式"的探活预算只是冰山一角。跨平台打包时切记一个反直觉的硬约束：sidecar 的原生模块按主机构架编译。所以：

arm64 安装包必须在 arm64 机器上重新组装载荷再打包；
不能指望在一台 x64 上 --x64 --arm64 一把梭------那个只对壳有效，原生模块还是 x64 的。

另一个配置层面的坑：每个平台下的 arch 字段是 defaultArch，只接受单个字符串 。一开始我把 arch: [x64, arm64] 数组写进去，electron-builder 直接 schema 校验失败并报"should be one of these: null"------多架构要改用命令行 --x64 --arm64 传参。

yaml 复制代码

win:   { target: [nsis] }
mac:   { target: [dmg] }
linux: { target: [AppImage, deb] }

怎么系统地"不再翻车"：打包前的验证清单

与其靠"试"，不如把三类验证事前做成脚本：

载荷冒烟 ：用载荷自带的 Node 跑入口 --version，验证运行时 + 依赖图 + 入口三者一致（否则装完启动必然失败）；
工作区复原：deploy 会污染开发环境，fail-safe 复原；
配置校验 ：electron-builder 加载配置就报错，别等装完才发现。

小结

"安装后第一次打不开、重开就好"的真相，三句话：预算太紧、时机最差、路径相同 。它教会我两件事------给子进程就绪足够宽的预算，并且把敢假设成配置项而非魔法数字 ；以及把"慢"拆成『错误』和『体量』分别处理，错误要修、体量要谈取舍。

如果你也遇到过"第一次启动超时、第二次就好"，那大概率不是玄学。欢迎在评论区分享你的超时预算是多少、以及你有没有踩过 arch 数组的坑。