DeepSeek Harness 桌面端启动异常：没有窗口、启动崩溃、EMFILE 与 80 秒单核满载

DeepSeek Harness（DSH）桌面端的启动期有三种典型故障，而且它们的「可见症状」都不指向真因：宿主没进入就绪状态时应用只剩托盘图标**（窗口在等一个没有截止时间的信号）；插件把配置导出成空值让设置描述整体失败，最终只留一句 desktop welcome: Web RPC failed（真实错误在上层被丢弃）；会话缓存目录文件数过多导致启动期打开文件数超限，留下一个零字节的凭据锁文件，此后每次启动都失败（只能靠手工删锁启动一次）。** 另有一条不失败但很吵的：启动后约 80 秒里 CPU 单核满载、磁盘读取接近 900 MB，来自「设置描述每次调用都重算整个 profile 组合」（#9610、#9044、#9609、#9710）。

DeepSeek Harness 只剩托盘、没有窗口：就绪等待没有截止时间

一句话结论：主窗口是在宿主进入就绪状态之后才显示的，而这个等待没有截止时间**；同时托盘与「打开」两个入口共用同一个抢前台函数，而该函数在「还没进入工作区」时提前返回——于是启动期点托盘等于什么都不做，界面看起来像「应用没起来」。** 症状是只有托盘图标、无任何窗口，点托盘「Open」无效（#9610）。

DSH插件 判据与三步临时处置

1. 确认判据：托盘图标还在、宿主进程也活着，但你点托盘「Open」没有任何反应，也没有任何窗口；报告者从产物里定位到等待逻辑，并指出停滞时不写任何日志——没有日志本身就是线索（#9610）。
2. 临时处置一：如果你只是想把活先干完，可以改用 dsh web 形态（浏览器访问），桌面端稍后再重启（#9610）。
3. 临时处置二：结束残留的桌面端进程后重启——宿主可能卡在启动阶段，重启让就绪信号重新走一遍（#9610）。
4. 注意一个连带分支：讨论里还指出「保存凭据后自动进入」这条路径即使成功也不显示窗口——所以「凭据保存成功但仍看不到窗口」并不是矛盾（#9610）。
5. 修复方向：立刻显示启动态界面、给就绪等待加截止时间、放开托盘守卫、并在停滞时写日志（#9610）。

DeepSeek Harness 启动即失败：真实错误被一句通用文案替代

一句话结论：某个插件把配置对象导出成空值**，而设置模块的形状检查只挡住了「未定义」、没挡住「空值」，于是设置描述整体失败、欢迎流程第一步即抛错，上层只留一句通用文案——所以日志里看不到真因。** 报错形态是 desktop welcome: Web RPC failed（#9044）。

DeepSeek Harness 三步定位（由外到内）

1. 确认「能靠禁用插件启动」：你可以先用界面提供的「禁用第三方插件」入口启动——能起来即说明是插件侧问题（#9044）。
2. 逐个启用以定位元凶：从禁用态开始，每次只启用一个插件重启，直到复现——比读日志快（#9044）。
3. 注意触发是时序相关的：讨论里提到「全部插件冷启动时必崩、逐个手动启用却正常」——所以定位到某个插件后，还要在「全量冷启动」条件下复核一次（#9044）。
4. 两条修法：宿主侧把空值一并挡住（而不是只挡未定义）；插件侧不要导出空配置（#9044）。
5. 验证：修完后恢复全量插件，冷启动一次，预期能正常进入欢迎页（#9044）。

DeepSeek Harness 启动即 EMFILE：缓存文件太多，留下空锁

一句话结论：启动期扫描大量会话文件会耗尽进程打开文件数；写凭据锁的模块是必需插件，此时失败——而锁是先创建再写进程号**，死在两步之间就留下一个零字节锁文件，之后每次启动都因读不到持有者而无法接管，形成永久阻塞。** 症状是启动约 2.6 秒后报打开文件数超限（缓存目录里上万文件），此后每次启动都失败或长时间无 fatal（#9609）。

DeepSeek Harness 四步恢复（按顺序做）

1. 确认判据：报错里出现打开文件数超限；缓存目录（会话投影缓存）文件数异常大（讨论中实测量级为上万个文件）（#9609）。
2. 移走缓存目录（不要直接删）：你可以把它整体移到一个临时位置，便于随时回拷（#9609）。
3. 删掉那个零字节的凭据锁文件：

Get-Item "$env:USERPROFILE\.dsh\.credentials.yaml.lock" -ErrorAction SilentlyContinue |
  Where-Object Length -eq 0 | Remove-Item
#   预期：文件被删除；下次启动会重新创建

4. 重启 DSH，预期这次能正常进入（#9609）。
5. 从移走的缓存里只回拷仍存在的会话，把历史残留清掉，避免再次堆积到上万文件（#9609）。
6. 修法方向（两条，值得反馈上游）：让读表操作有并发上限（不要一次把所有记录都读进内存），以及区分「单文件脏」与「进程级资源耗尽」——后者不该被当成普通缺文件处理（#9609）。

DeepSeek Harness 启动后 80 秒单核满载：设置描述没有缓存

一句话结论：设置描述在启动期被反复调用，而每次调用都会把整个 profile 的补丁与全部插件清单重新读取解析一遍**；按讨论中的测量，启动阶段这类调用量级在千次以上，于是形成一次明显的 CPU 与磁盘尖峰。** 症状是启动后约 80 秒单核满载、磁盘读取接近 900 MB，期间插件树/设置/新会话都卡（#9710）。

DeepSeek Harness 三步处置

1. 确认判据：负载尖峰集中在启动后的固定时段（约 80 秒），此后恢复；与「同时开了几个会话」无关（#9710）。
2. 临时缓解：你可以装社区提供的组合缓存插件（按文件身份与配置变更事件失效），或减少 profile 里的插件数量与补丁层数——补丁层越多，每次重算越贵（#9710）。
3. 修法方向：给「设置描述 / profile 目录加载」加一层按文件身份失效的缓存（#9710）。
4. 验证：重启后观察这段尖峰是否明显变小；若不变，确认缓存插件是否真的生效（#9710）。

DSH插件 排查注意事项

桌面端启动故障的排查主线是：先用「禁用第三方插件能否启动」二分插件与核心，再看报错落点是「配置/设置」还是「文件系统资源」。 若失败只在打包形态出现、或报错与路径、宿主环境相关，就更靠近「桌面壳集成」那一族，可对照 DeepSeek Harness 桌面端壳集成：打开与显示失败、打包技能缺失、stderr 不可见与宿主启动失败。 八条要点：

1. 只有托盘没窗口 = 就绪等待没截止时间，不是应用没启动（#9610）。
2. 「点托盘无效」是守卫提前返回，不是点击没生效（#9610）。
3. 启动期没有日志本身就是线索：停滞不写日志属缺陷（#9610）。
4. Web RPC failed 是通用文案，真因需要在设置/插件侧找（#9044）。
5. 插件问题可能是时序相关的：逐个手动启用正常、全量冷启动才崩（#9044）。
6. 「删空锁能启动一次」= 资源类问题，别去改配置（#9609）。
7. 缓存目录要「移走不要删」，便于回拷（#9609）。
8. 修复状态如实：四条在讨论所指版本（0.2.0-rc.2~0.2.1-alpha.*）里都未修；本文的处置均为临时规避（换 web 形态、禁用插件、移走缓存、删空锁、装缓存插件），官方侧未宣布修复。

桌面端启动问题排查时，「装了哪些插件」几乎是必查项。与其在各处手敲命令，不如用 DSH Plugin Hub 这类可视化插件市场：已安装列表、装卸历史与系统日志集中在一个面板里，先用它把插件这一层排掉。

来源：Discussion #9610、Discussion #9044、Discussion #9609、Discussion #9710。