四安装完点启动应用却没反应背后是 sidecar 的冷启动预算与杀软博弈承接系列前两篇。如果你把一个壳 sidecar 子进程的桌面应用打包出去很可能会撞上我这个真实翻车第一次装完勾选启动应用窗口迟迟不出来甚至报错但你关掉重开它又好好的。这篇讲清楚根因、修法以及它牵引出的跨平台打包与安装快不快的取舍。现象安装后自启失败快捷方式却正常安装向导勾选完成后启动 → 报错有时是sidecar did not start体验很糟之后手动双击快捷方式 → 一切正常。外壳看起来像玄学。其实两条路径用的是同一套代码、同一个绝对路径区别只在时机刚装完的那一下正是最坏的冷启动场景。根因冷启动预算设太紧了sidecar 是一个独立进程壳要等它就绪才能loadURL窗口。就绪靠健康探测轮询POST /api/host.describe直到返回 2xx。它有一个超时预算——超时就判定失败、弹错误框。最初我给打包模式设了 30 秒constPROBE_TIMEOUT_MS_PACKAGED30_000而 dev 模式因为要经 tsx 把整个 profile 跑凉给的是 120 秒。结果真实机器打了我脸刚安装的那一刻杀毒软件正在实时扫描整个 sidecar 载荷几万个小文件 一个 Node 运行时冷启动完整 web 配置远超过 30 秒。于是它输给了预算——报错。等你手动再开文件已被杀软扫描/缓存过冷启动顺利跑进 30 秒内。修法就一行——把打包模式预算拉到和 dev 一致constPROBE_TIMEOUT_MS_DEV120_000constPROBE_TIMEOUT_MS_PACKAGED120_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传参。win:{target:[nsis]}mac:{target:[dmg]}linux:{target:[AppImage,deb]}怎么系统地不再翻车打包前的验证清单与其靠试不如把三类验证事前做成脚本载荷冒烟用载荷自带的 Node 跑入口--version验证运行时 依赖图 入口三者一致否则装完启动必然失败工作区复原deploy 会污染开发环境fail-safe 复原配置校验electron-builder加载配置就报错别等装完才发现。小结安装后第一次打不开、重开就好的真相三句话预算太紧、时机最差、路径相同。它教会我两件事——给子进程就绪足够宽的预算并且把敢假设成配置项而非魔法数字以及把慢拆成『错误』和『体量』分别处理错误要修、体量要谈取舍。如果你也遇到过第一次启动超时、第二次就好那大概率不是玄学。欢迎在评论区分享你的超时预算是多少、以及你有没有踩过arch数组的坑。
四安装完点启动应用却没反应背后是 sidecar 的冷启动预算与杀软博弈承接系列前两篇。如果你把一个壳 sidecar 子进程的桌面应用打包出去很可能会撞上我这个真实翻车第一次装完勾选启动应用窗口迟迟不出来甚至报错但你关掉重开它又好好的。这篇讲清楚根因、修法以及它牵引出的跨平台打包与安装快不快的取舍。现象安装后自启失败快捷方式却正常安装向导勾选完成后启动 → 报错有时是sidecar did not start体验很糟之后手动双击快捷方式 → 一切正常。外壳看起来像玄学。其实两条路径用的是同一套代码、同一个绝对路径区别只在时机刚装完的那一下正是最坏的冷启动场景。根因冷启动预算设太紧了sidecar 是一个独立进程壳要等它就绪才能loadURL窗口。就绪靠健康探测轮询POST /api/host.describe直到返回 2xx。它有一个超时预算——超时就判定失败、弹错误框。最初我给打包模式设了 30 秒constPROBE_TIMEOUT_MS_PACKAGED30_000而 dev 模式因为要经 tsx 把整个 profile 跑凉给的是 120 秒。结果真实机器打了我脸刚安装的那一刻杀毒软件正在实时扫描整个 sidecar 载荷几万个小文件 一个 Node 运行时冷启动完整 web 配置远超过 30 秒。于是它输给了预算——报错。等你手动再开文件已被杀软扫描/缓存过冷启动顺利跑进 30 秒内。修法就一行——把打包模式预算拉到和 dev 一致constPROBE_TIMEOUT_MS_DEV120_000constPROBE_TIMEOUT_MS_PACKAGED120_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传参。win:{target:[nsis]}mac:{target:[dmg]}linux:{target:[AppImage,deb]}怎么系统地不再翻车打包前的验证清单与其靠试不如把三类验证事前做成脚本载荷冒烟用载荷自带的 Node 跑入口--version验证运行时 依赖图 入口三者一致否则装完启动必然失败工作区复原deploy 会污染开发环境fail-safe 复原配置校验electron-builder加载配置就报错别等装完才发现。小结安装后第一次打不开、重开就好的真相三句话预算太紧、时机最差、路径相同。它教会我两件事——给子进程就绪足够宽的预算并且把敢假设成配置项而非魔法数字以及把慢拆成『错误』和『体量』分别处理错误要修、体量要谈取舍。如果你也遇到过第一次启动超时、第二次就好那大概率不是玄学。欢迎在评论区分享你的超时预算是多少、以及你有没有踩过arch数组的坑。
