profile 清单被写入 UTF-8 BOM 后加载器解析即崩，且恢复流程会再次写坏，无法自救

[Chen0407-en]

DSH 0.2.1-rc.3（Windows x64，Electron 44.7.0）在某些写入路径下会给 profiles/<name>/package.json 加上 UTF-8 BOM（EF BB BF）；加载器 readProfileManifest 直接 JSON.parse、不剥离 BOM，启动即抛 Unexpected token '' 崩掉；崩溃弹窗的「恢复重启」又会走同一条坏路径，形成无法自救的崩溃循环（实测连续 9 次，16:09–16:31 UTC）。
证据四条：

1. 0:13 的备份（950 字节）首三字节就是 efbbbf；更早的历史备份（466/344 字节）全是 7b0a20 —— BOM 是后来某次写入才引入的。
2. 0:26 生成了 cordis.patch.yml.bak-1793378185239（正是「back up profile patch」的痕迹），0:27 立刻复崩 —— 恢复动作确实执行过，且没校验就重启。
3. 已排除第三方插件与外部工具：profile 下所有已装插件没有 Set-Content/Out-File/utf8-sig 这类写法；PowerShell Operational 日志（enabled）在崩溃窗口内检索 package.json 命中 0 条。
4. 对照组：今天 12:41 应用自己重写清单（1108 字节）首三字节为 7b0a20，此后 21 小时零崩溃 —— 不是「写清单一律加 BOM」，是某条特定路径（失败/恢复流程）才加。
   按 RFC 8259 §8.1：写入方 MUST NOT 加 BOM，解析方 MAY 忽略 BOM。这里是写侧违规、读侧又把可选容错做成了致命失败。
   建议修复（按优先级）：
5. 读侧止血（P0）：配置读取收口到统一函数，解析前剥离 BOM，兼容 UTF-16 BOM。
6. 恢复侧兜底（P0）：坏文件先隔离为 .bad-<ts> → 从 last-known-good 恢复 → 用同一加载器校验能 parse 再启动；加崩溃循环检测与安全模式。
7. 写侧根因（P1）：定位并改掉带 BOM 的写入路径，改原子写（临时文件 + rename），写完回读校验。
   另附一条：插件安装子进程未继承用户级 PATH，pnpm 解析 GitHub 依赖时报 'git' 不是内部或外部命令（git 实际已安装可用）。建议 spawn 时继承完整 PATH，或允许配置 git 路径。
   本问题由用户在日常使用中发现，证据按时间线整理；已知此前有若干同类报告（【Bug】桌面版启动崩溃：profile package.json 含 UTF-8 BOM 时 JSON 解析失败（readProfileManifest） #11182、[Bug] 0.2.1-rc.3 Windows 启动必崩：profile 清单带 U+FEFF，JSON.parse 直接失败 #10883、[Bug] 桌面端启动即崩：profile manifest 的 UTF-8 BOM 未被容忍；dsh plugin add 中断后无法自愈 #10159、Two desktop-app (0.2.0-rc.2) bugs: BOM written into profile package.json crashes boot; turn resume after interrupted tool call crashes with 'prepare' undefined #8837），本条补充的是「恢复流程会再次写坏、形成无法自救的崩溃循环」这一段。
   证据2-插件安装失败日志.log
   证据1-BOM坏掉的配置文件.json

[PerryLink]

先把 package.json 开头的 BOM 去掉，启动就能过。PowerShell：

$p = "$env:USERPROFILE\.dsh\profiles\desktop\package.json"
$t = [IO.File]::ReadAllText($p).TrimStart([char]0xFEFF)
[IO.File]::WriteAllText($p, $t, (New-Object System.Text.UTF8Encoding($false)))
[BitConverter]::ToString([IO.File]::ReadAllBytes($p)[0..2])   # 期望 7B-0A-20

读侧的位置和你说的对得上：packages/boot/app-boot/src/profile.ts:552 是 readFileSync(path, 'utf8')，:557 直接 JSON.parse(raw)，中间没有剥 BOM。

有一句要改。「恢复流程会再次写坏」不成立：packages/boot/app-boot/src/profile-sanitize.ts:19 是先读同一个清单，清单解析不了就在 :27 的 renameSync 之前抛，packages/boot/app-boot/README.md:71 写的就是 "Invalid profile JSON fails before mutation"。所以那个恢复按钮救不了你，但也没有重写清单。

这条证据反过来有用：你在 0:26 看到了 cordis.patch.yml.bak-...，说明那一刻清单是能 parse 的。要么 BOM 是 0:26 之后才进去的，要么带 BOM 的那个 950 字节文件不是 profiles/desktop/package.json。看一眼那个 .bak 同目录的 package.json 修改时间就能分开。

写侧也别在 DSH 里找：profile.ts:569-571 的 writeProfileManifest 是 JSON.stringify(..., 2) + '\n'，不写 BOM。我按 FEFF|ufeff|utf8-sig 搜过 packages 和 apps，主动写 BOM 的只有 packages/util/native-command/src/file-applications-windows.ts:268（给 Windows 脚本用的），其余命中都是解析前剥掉或拒绝。所以这个 BOM 来自 DSH 之外——编辑器、PowerShell 5.1 的 Out-File/Set-Content，或者某次手工改。

修法形状：读侧 JSON.parse 前剥 BOM（顺带 UTF-16 BOM）；恢复路径先隔离坏文件再重启，别让同一个坏文件把恢复也卡住。

去掉 BOM 后如果还崩，把 Unexpected token 那行的原文和当时的文件前 8 字节贴上来，那就不是 BOM 这一条了。

只读了 master ce7073d5 的源码，没在你的机器上跑过。

[Chen0407-en]

谢谢 @PerryLink。按你给的命令去掉 BOM 了，机器现在能起；profiles/desktop/package.json 1108 B，前三字节 7B 0A 20。

先认一句：「恢复流程会再次写坏」我收回。 你说得对，profile-sanitize 第一步就 readProfileManifest，解析不了在 renameSync 之前抛，走不到写清单那一步；我这边翻发出包也得到同样结论，只是原来那句写得比证据硬，已经改掉。

但由此留下的东西反而更值得修：这条恢复路径对「清单不可解析」没有出路——它读同一个坏文件、失败即抛，没有隔离坏文件、没有回退上一次可用备份、也没有任何命令行入口。UI 里本来就有「恢复失败」的文案，说明这在预期内，可失败之后用户手里什么都没有，只能像我一样去外部工具里改字节。

按你说的，把时间点分开（本机 profiles/desktop/ 实测，UTC+8）：

• 10-31 00:13:45　package.json.bom-backup（当晚 cp 出来的原样副本）950 B，前三字节 EF BB BF
• 10-31 00:26:46　cordis.patch.yml.bak-1793378185239（profile patch 备份成功，说明那一刻清单能 parse）
• 10-31 00:27:41 / 00:27:46　renderer / host 各崩一次
• 10-31 00:31:03　当时清单的 hexdump：efbb bf7b 0a20 2022 —— BOM 又回到开头，后面紧跟 { + LF + 两空格
• 10-31 12:41:40　package.json（pnpm 安装重写）1108 B，7B 0A 20

所以状态是：00:26:46 能 parse → 四分钟内连崩两次 → 00:31:03 再看，开头又是 ef bb bf。

我不主张「是 DSH 写的」：你说得对，writeProfileManifest 是 JSON.stringify(...,2)+"\n"、不写 BOM；我在发出包（182 MB）上全量搜 FEFF，30 处全在 yaml / ajv / yaml-ast / eventsource / devtools，主动写 BOM 的只有 native-command 里给 Windows 临时脚本那一处，跟你搜 packages 的结论一致。所以「谁写进去的那三个字节」我标成未定，只把这几个时间点交给你判断：如果来源只能是外部编辑器 / PS 5.1 / 手工，那 00:26:46 到 00:31:03 之间这份文件的变化，需要另一个解释（那十六分钟里我没有找到任何写文件的命令）。

两处旁证，供参考，不当主张：

1. 同一时刻的 workspace-policy.json.bom-backup：27 B，EF BB BF + { "policy": "always" } + CRLF；而清单那份行尾是 LF。两份形态不同，可能不是同一支笔。
2. 崩溃框里「禁用第三方插件」按下去，会把 bundles 从 8 条砍到 2 条（本机实测）。用更大的损失换一次重启，这个行为是预期内的吗？

三条建议（要不要修、怎么修听你们的；我不提 PR，只把现象和字节交上来）：

1. 读侧：JSON.parse 前剥 BOM，顺带 UTF-16 BOM（你提到的修法形状）；
2. 恢复侧：坏文件先改名隔离 → 回退 last-known-good → 用同一加载器校验通过再启动，避免同一个坏文件把恢复也卡死；
3. 给一个不依赖 GUI 的入口（启动参数 / 安全模式），让起不来的人能在里面重置清单、禁用插件。

最后交代一句限制：我只在 0.2.1-rc.3 的发出包上验证（行号和你读的 master 不同），没有源码环境，也没改一行代码；上面全是字节、时间戳和我自己的操作记录。

[Chen0407-en]

附件-BOM字节证据.txt
前 8 字节：efbb bf7b 0a20 2022（BOM + { + LF + 两空格，即 JSON.stringify(x, void 0, 2) 的形态），完整内容见附件。