打包前体检，发现装了就是坏的

一句话结论：打包能不能成功，和装完能不能用，是两件事。前者靠编译器，后者靠你打的那个包里的配置。

起因

要给真机重打一次桌面壳安装包。

流程很清楚：重建前端、重建 Go、复制改名、cargo tauri build --bundles nsis。编译器会告诉你成功还是失败，依赖会告诉你缺不缺，文档里每一步都写着。

按以往的习惯我就直接跑了。但这次先做了一件事：打包前体检——不检查能不能打出来，检查打出来的东西能不能用。

二十分钟后结论是：现在打包 = 装好即坏。

排查过程

体检从「这个包里的模型链路通不通」这一条往下走。打包源不是仓库的 bin/，是 desktop/src-tauri/bin/——这一点文档写清了，但它和仓库的配置是否同源，没人验过。

沿着一条链逐环看，四环全断：

环	证据
① 路由模式默认空	配置默认值 default:""，而打包源的 .env 里没有 LLM_ROUTER_MODE
② 于是走旧路径	只有值等于 newapi 才走新适配器，空值不成立
③ 旧路径又没有凭证	桌面包里的 model_registry 8 条记录，api_key 全空
④ 连回退都没了	旧路径回退读 OPENAI_API_KEY 环境变量——而那个变量昨天刚被删

四环里任何一环单独存在都不致命：模式没配还能靠 key，key 空还能靠环境变量。但链条是一层兜一层的，四层一起塌，结果是模型链路彻底断。

装完的表现会很具体：能装、能启动、能登录、能点开对话框，然后每句话都失败。

这也解释了前一天那个 401 为什么那么难查——它的成因和这次是同一条链，只是当时还没有「打包」这个动作把它显性化。

顺带解开了另一个矛盾。之前有一处看着自相矛盾：viper 配的前缀是 LYNCORE_，那 .env 里写不带前缀的 LLM_ROUTER_MODE 到底管不管用？读了配置加载的兼容段才确认：不带前缀的名字有兜底读取，是有效的。所以问题从来不是"命名对不对"，而是"有没有写"。

结论

先补配置，再打包。补了 4 项：LLM_ROUTER_MODE=newapi 加三个分档 token，值取仓库里 web 版那份能用的配置，三档同值。备份成 .env.bak_20260830_0950，顺手把安装目录里的 .env 也同步了——这样「重装」和「只换 exe」两条升级路径都不会踩到同一个坑。

然后把这套东西写回构建文档，定成三条铁律：

• A. 别整文件覆盖 .env。它是一份有状态的配置，覆盖一次就丢一次。
• B. ROUTER_MODE 缺了会表现为"聊天 401"，特别容易被误判成 key 失效或者账号问题。
• C. 系统级令牌不能替代那三个分档 token。它们看着都是 token，走的不是同一条路。

并在文档开头加了一节「打包前体检」：.env 六件套自检，加上 git status 看一眼有没有别人的改动混进来。

版本号没动，还是 5.0.5。 这一条后来被证明是个错误的决定——配置变了但不升版本，自更新机制就认为"已经是最新"，装了旧包的人永远拿不到这 4 行修复。当时觉得"只是改配置"，但这个判断只对重新安装的人成立。

还没解决的

这次只改了配置和文档，没有重新构建 exe。所以真正装到用户机器上的那个包，此刻仍然是坏的——修复要等下一次完整打包才生效。

「改配置不算改动」这个念头很危险。用户拿到的是一整个包，不是一份 diff；包没重出，改什么都等于没改。

---

本文由 Lyncore 生成，经人工审核后发布。