Electron 应用报错取证：解包 app.asar 判定锅在谁

背景：弹窗报错，堆栈只给你一个文件行号

我日常在用一款 Electron 写的 AI 桌面客户端，直连一个国内模型服务平台的推理接口。前阵子它开始频繁弹窗报错，用户视角看到的就是这种东西：

Error: 400 developer is not one of ['system','assistant','user','tool','function']
    at ... (/Applications/X.app/Contents/Resources/app.asar/out/main/index.js:28413:22)

堆栈里唯一可用的信息是 app.asar/out/main/index.js:行:列。这句话有三个可能的归属：

1. 应用自己的 bug——客户端代码把请求构造错了；
2. 上游开源项目的已知缺陷——需要去仓库确认有没有人提过、有没有版本修了；
3. 服务端原样抛回——错误文案根本不在应用代码里，是模型网关吐回来的。

只看报错本身没法区分这三者，猜也没有意义。我的做法是：把 app.asar 解包，读它编译后的真实代码，再配合单变量的 HTTP 复现，让证据链说话。这篇文章把整套流程和三个具体坑记下来。

取证流程：先钉版本，再解包，然后搜

第一步永远是钉版本，因为报错归属是按版本判定的，版本没钉死后面全是白工：

plutil -extract CFBundleShortVersionString raw /Applications/X.app/Contents/Info.plist
# 0.37.1

然后解包到暂存目录。Electron 应用的主进程代码全在 Contents/Resources/app.asar 里，用官方的 asar 工具就能展开：

npx --yes @electron/asar extract /Applications/X.app/Contents/Resources/app.asar ./outdir
ls outdir/out/main outdir/out/main/chunks   # 主进程代码在这两处

解出来会看到 out/main/index.js 加一堆 out/main/chunks/*.js——堆栈里那个 index.js:28413 就直接对应这个文件；out/renderer 下多是 UI 噪音，排查后端逻辑时基本不用看。如果只想抽一个文件，不必全解：npx --yes @electron/asar extract-file app.asar out/main/index.js。

接着拿报错原文去主进程代码里搜。grep 必须加 --include='*.js'：

grep -rn 'developer is not one of' out/main --include='*.js'

不加这个限定，*.mjs.map 里的 base64 sourcemap 会把几万字符的垃圾灌进输出，真正有价值的两三行命中直接被淹没。搜某个函数名同理：

grep -rln 'supportsDeveloperRole' out/main          # 先定位命中在哪个 chunk
grep -oE '.{200}supportsDeveloperRole.{200}' out/renderer/assets/*.js   # 看 UI 有没有暴露这个开关

这里有个关键的推理规则：主进程全文 0 命中 = 这句文案不在应用里，大概率是服务端原样抛回的（内容审核、网关错误这类），应该停止怀疑应用、转去验证服务端行为，不要给应用仓库提 issue。反过来，有命中才值得继续读码。

还有一个跨版本对比的坑。release 构建的函数名每版都被 minifier 重排，按函数名或整文件 diff 得到的是几千块改名噪音。正确做法是先用函数体内的字符串字面量锚定函数，花括号配平把函数体整个抠出来，新旧版本各取一份，只 diff 函数体：

import re
src = open('out/main/index.js', encoding='utf-8', errors='replace').read()
m = re.search(r'function \w+\(e,t\)\{', src)   # 或用已知字面量锚定，如 '"developer"'
i = m.start(); d = 0; k = src.find('{', i)
while True:
    if src[k] == '{': d += 1
    elif src[k] == '}':
        d -= 1
        if d == 0: break
    k += 1
body = src[i:k+1]

diff 时再按语句切分降噪，只留语义增量：

import re, difflib
def seg(s): return re.split(r'(?<=[;}])', s)
diff = difflib.unified_diff(seg(a), seg(b), n=0, lineterm='')
for line in diff:
    if line[:1] in '+-' and any(k in line for k in ('supportsDeveloperRole', 'reasoning')):
        print(line[:300])

或者更省事：同名 chunk 两版本字节级相同，就说明修复不在这个 chunk 里。我实测有一次两个版本的关键 chunk 只差一行 require 路径，真正的改动在 index.js 的模型信息构造逻辑里——不读码根本想不到。

最后一条铁律：代码结论必须配真实复现。同 key、同模型、同端点，一次只翻一个可疑参数（role、thinking、header、长度上限），HTTP 直调坐实因果后才下结论。下面三个坑全按这套流程走。

坑一：developer is not one of [...]——应用旧版把角色发错了

现象。就是开头那条报错，HTTP 400，服务端拒绝 developer 角色：

400 developer is not one of ['system','assistant','user','tool','function']

排查。按上面的流程解包、搜错误串。服务端这句校验文案在主进程 0 命中，但搜 developer 能看到应用自己拼角色的逻辑：compatible 通道下，客户端用模型名匹配 /qwen|qwq/i 判断"推理模型"，是推理模型且目标服务不在"非标准端点黑名单"里，就把 system prompt 发成 OpenAI 新规范的 developer 角色。而这个服务平台只接受 system/assistant/user/tool/function。也就是说 400 文案来自服务端，但触发它的错误请求是应用构造的。

再坐实一步，单变量复现，同 key 同模型只翻 role 这一个参数：

BASE="https://<平台端点>/compatible-mode/v1/chat/completions"
curl -sS -X POST "$BASE" -H "Authorization: Bearer $KEY" -H 'content-type: application/json' \
  -d '{"model":"qwen3.8-flash","messages":[{"role":"developer","content":"reply ok"},{"role":"user","content":"hi"}]}'
# 把 role 换回 system 再打一次

结果 developer 必 400、system 必 200，因果闭环：不是 key、不是配额、不是内容，就是角色。

判定归属。应用侧 bug（旧版本行为），不是服务端故障。查上游仓库三查确认：gh search issues --repo <org>/<repo> 'developer is not one of'、gh issue list --state open、gh release view v<ver> --json body——changelog 写明新版本已修（qwen + completions 端点强制用 system）。照规矩，官方声称"已修"也要验证：用花括号配平在新旧两版 asar 里 diff 那段角色构造代码，确认修复点存在、且覆盖我实际走的这条分支，才向使用者转述。

解法。升级到修复版本；暂时不能升级的，走平台 CLI 直连（没有角色交换这一层）。有个看似 tempting 的捷径是"图快改走 Anthropic 兼容通道绕开角色问题"——千万别，会直接踩进坑二。

复盘。同一条报错，文案在谁手里和触发在谁手里是两回事。服务端原样抛回的 400 不等于"服务端的锅"；解包读到构造逻辑，才知道该修的是客户端。

坑二：Model did not return a JSON object——thinking 吃光 max_tokens 的伪装

现象。换了 Anthropic 兼容通道后，客户端报：

Model did not return a JSON object

诡异的是它只在长输入时出现，短输入偶尔能过，看起来"时好时坏"，很容易误判成网络或服务端抖动。

排查。先搜错误串——这句在 out/main 里有命中，是客户端自己的 JSON 解析器抛的。顺着读它的 anthropic 分支：解析逻辑硬编码 reasoning: false，等于请求里整个不带 thinking 参数。而这个平台的 /apps/anthropic 端点对这类模型默认开 thinking。于是长输入下推理块把 max_tokens 全部吃光，SSE 流里只有 thinking、零 text 内容，stop_reason=max_tokens，客户端对着空文本解析 JSON 就炸了。短输入下剩余 token 侥幸够输出，才显得"时好时坏"。

复现同样单变量：同 key 同模型同端点，长输入跑一次、加不加 "thinking":{"type":"disabled"} 各跑一次，对比流里 stop_reason 和有没有 text 块。报错在 SSE 流内 error 事件和 HTTP 400 两种方式下都可能出现，两种都要抓。

判定归属。应用侧未修 bug（错误文案与触发逻辑都在应用里），但它被服务端的默认行为放大了——归属判定看"谁构造了这个错误请求形态"，这里是客户端。

解法。改回 compatible 通道；等平台/客户端把 thinking 参数处理对齐再切。换通道前我先用同 key 对新通道打了一次 curl 确认可用，并读码确认新通道不会把同一个坑换个形式再犯一遍。

复盘。两点。第一，"时好时坏的报错"往往是长度、状态这类隐藏变量在起作用，别先怀疑网络。第二，这个应用里同一功能在"交互式对话"和"后台任务"可能走不同的模型构造分支（对话链路的 thinking 档位会强制 reasoning:false），一处验证正常不代表另一处正常，排查时要分开验。

坑三：Input data may contain inappropriate content——0 命中，锅根本不在应用

现象。分析较长会话内容时弹出：

Error: Input data may contain inappropriate content
(code: data_inspection_failed, HTTP 400 / 也可能以 SSE 流内 error 事件出现)

排查。按流程搜：

grep -rn 'inappropriate' out/main --include='*.js'
# 0 hits

主进程全文 0 命中——这句文案不在应用里，是服务端内容审核原样抛回的（输入、输出各查一遍）。为了排除"文案被拆分拼接"的可能，连 data_inspection、inspect 等子串都搜了，仍然零命中。再复现：输入版用敏感内容必炸；输出版要模型真的产出被拦内容才报错，模型自己拒答时不报，别误判为"通道没问题"——长输入加上要求逐字引用原文，最容易触发输出版。

判定归属。服务端平台侧（内容审核机制），不是应用 bug，不给应用提 issue——上游仓库三查也确认没有对应的已知问题，提了也是白提。顺带查了下关闭审核的官方姿势：请求头 X-<平台名>-DataInspection: {"input":"disable","output":"disable"}，实测多数账号无权限，直接 403 access_denied，需要走平台白名单开通；而且这个客户端也没有注入自定义 header 的入口。

解法。出路都在平台侧或用法侧：提工单申请豁免；开平台的"AI 安全护栏"忽略词库；敏感会话换审核更宽松的端点；实在不行，这类数据就不做 AI 分析。不要热补丁 app.asar——改包破坏签名、应用一升级就打回原形，永远优先考虑改用户配置目录 ~/.<app>/ 里的 JSON，或换配置里已支持的另一条通道。

改配置时又踩出两个隐藏坑：

• 这类桌面应用常在退出时把内存配置回写覆盖磁盘。编辑 JSON 前必须确认进程已退（pgrep -x <App>），没退就先 Cmd+Q，改完再启动，否则改动会被静默吞掉。
• 配置文件里的鉴权是间接引用：主配置只存 authProfile 名字，真 key 在另一个 profiles 文件里。解析时按名字精确命中，失配会静默回落到 provider 字段相同的第一个 profile。复制配置换通道时，必须新建或改名 profile 并保证其 provider 与新配置一致，否则会悄悄用错 key，报出一堆看似无关的鉴权错误。

复盘。0 命中本身就是最强证据，但它的价值在于阻止你做错事：阻止你给应用仓库提无关 issue，阻止你去 diff 一个根本没有改动的客户端。先证明"不在哪"，再证明"在哪"。

收尾：一条可复用的取证链

回头看，三个坑共用同一条链路，只是分岔在三处：

1. plutil 钉版本 → npx @electron/asar extract 解包 → grep --include='*.js' 搜错误串；
2. 主进程 0 命中 → 文案在服务端 → 单变量 curl 验证服务端行为（坑三：审核，不提 issue）；
3. 主进程 有命中 → 文案是应用自己抛的 → 花括号配平抠函数体 → 跨版本 diff 找真实逻辑增量 → 单变量 curl 坐实因果（坑一：旧版角色 bug 已修；坑二：未修的 thinking 分支）。

整条链路上没有一步是"看报错猜归属"，每一步的结论都挂着可回放的证据：搜索命中的文件行、单变量对照的两条 curl、新旧函数体的 diff。向用户报告根因时给的是这条证据链，而不是结论猜测——这也是我愿意花时间解包的全部理由。

另记一笔：暂存目录里的解包产物会被定期清理，跨会话要复核时重新 extract 一遍就行，命令都在上面，不用心疼。