【Bug】桌面版启动崩溃：profile package.json 含 UTF-8 BOM 时 JSON 解析失败（readProfileManifest）

[wyyainie]

环境

• DSH Desktop 0.12.1 / harness 0.2.1-rc.3，Windows 10 22H2 (19045)
• Profile: desktop

现象

~/.dsh/profiles/desktop/package.json 含 UTF-8 BOM（EF BB BF）时，重启 DSH Desktop 直接启动崩溃，无法进入界面：

DesktopHostFatalError: Unexpected token '', "{

崩溃日志：%APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-<ts>-host.log

复现步骤

1. 用 Windows PowerShell 5.1 的 Set-Content -Encoding UTF8 写 ~/.dsh/profiles/desktop/package.json（该编码会在文件头写入 BOM）；
2. 重启 DSH Desktop；
3. 启动失败，进程退出。

期望

正常启动；或至少给出「profile manifest 含 BOM，请移除」这类可读错误，而不是直接崩掉。

根因

启动时 readProfileManifest 直接对文件内容调用 JSON.parse，未剥离 UTF-8 BOM。BOM 是合法的字节序标记，但 JSON.parse 会把它当非法字符抛异常，导致初始化失败。

不止手改文件会触发：PowerShell 5.1、部分编辑器「另存为 UTF-8」、以及某些第三方插件/安装脚本都会写出带 BOM 的 JSON，用户很难自查。

建议修复

1. 读取后先剥离 BOM：text.replace(/^\uFEFF/, '')，或使用 BOM-aware 读取方式；
2. 解析失败时输出可读错误（含文件路径 + 修复方式），不要 fatal；
3. 写侧（plugin manager / 设置 / 安装器）统一输出 UTF-8 without BOM；
4. 加单测：带 BOM 的 profile manifest 能正常加载。

临时规避

备份后去掉文件头 3 字节 EF BB BF，用无 BOM UTF-8 重写即可恢复：

$p = "$env:USERPROFILE\.dsh\profiles\desktop\package.json"
$t = [System.IO.File]::ReadAllText($p).TrimStart([char]0xFEFF)
[System.IO.File]::WriteAllText($p, $t, (New-Object System.Text.UTF8Encoding($false)))

[cjnoy520]

这是我问gpt修复的办法，我已经修好了

操作前请完全退出 DeepSeek Harness。

1. 按 Win + R，输入 powershell，按回车。
2. 复制下面整段命令，粘贴后按回车。

$p = Join-Path $env:USERPROFILE ".dsh\profiles\desktop\package.json"

if (-not (Test-Path $p)) {
Write-Host "未找到配置文件：$p"
} else {
$t = [System.IO.File]::ReadAllText($p)
$t = $t.TrimStart([char]0xFEFF)

try {
    $null = ConvertFrom-Json -InputObject $t -ErrorAction Stop

    $backup = "$p.bak-$(Get-Date -Format yyyyMMddHHmmss)"
    Copy-Item $p $backup

    [System.IO.File]::WriteAllText(
        $p, $t,
        [System.Text.UTF8Encoding]::new($false)
    )

    Write-Host "修复完成，原文件备份在：$backup"
} catch {
    Write-Host "JSON 校验失败，未修改原文件：$_"
}

}

3. 如果提示“修复完成”，重新打开 DeepSeek Harness。

注意：如果提示未找到配置文件，不要随意新建文件或删除整个 .dsh 文件夹，如果 JSON 校验失败，也不要覆盖原文件。

[wyyainie]

补充：这个可以直接修，不用每次清文件

给维护者一个更省事的路径：根因在读取函数，补三层就够。

定位

profile manifest 的读取函数 readProfileManifest（就是 loadProfileDirectory / createRuntimeResolution 所在的那个模块）里：

raw = readFileSync(path, "utf8");
const parsed = JSON.parse(raw);   // ← BOM 在这里炸

readFileSync(..., "utf8") 会保留开头的 U+FEFF，JSON.parse 把它当非法字符抛异常，于是整个初始化 fatal。

建议补丁（约 8 行）

raw = readFileSync(path, "utf8");
const text = raw.charCodeAt(0) === 0xFEFF ? raw.slice(1) : raw;
let parsed;
try {
  parsed = JSON.parse(text);
} catch (error) {
  throw new Error(
    `${binName}: profile manifest ${path} is not valid JSON (${String(error)}). ` +
    `If the file begins with a UTF-8 BOM (EF BB BF), rewrite it as UTF-8 without BOM.`,
  );
}
if (parsed === null || typeof parsed !== "object" || Array.isArray(parsed)) {
  throw new Error(`${binName}: profile manifest ${path} must hold a JSON object`);
}

最小复现

1. 用 PowerShell 5.1 执行 Set-Content -Path "$env:USERPROFILE\.dsh\profiles\desktop\package.json" -Value $json -Encoding UTF8（该编码会写入 BOM）；
2. 重启 DSH Desktop；
3. 启动即崩，无界面。

建议补的单测

• 带 BOM 的 profile manifest 能正常加载（不抛异常）；
• manifest 有语法错误时抛出带文件路径的可读错误，而不是 fatal。

为什么只清文件不够

上面那条清理脚本只能救已经损坏的文件；只要写侧（PowerShell 脚本、部分编辑器"另存为 UTF-8"、第三方安装脚本）再来一次带 BOM 写入，同一个崩溃就会复现——用户很难自查到是 BOM 的问题。