dsh web 插件市场空白打不开：和桌面端差在哪、端口、认证与缓存的三步排查及完整恢复顺序

dsh web 打开了，侧边栏也在，只有插件市场一块是白的——这个画面最容易被误判成「Hub 坏了」，但桌面端往往一切正常。 两端用的是不同 profile、不同页面链路，Web 端空白更可能是「web profile 没装 Hub」「认证失效」「前端资源对不上」这三类（浏览器令牌认证说明）。这篇按分诊表走：先分清端与症状，再查三层，最后按代价排序恢复。入口在 DSH Plugin Hub 的「设置 → 插件市场」。

先分清 Web 端与桌面端：DeepSeek Harness 插件市场的差异

Web 端与桌面端不是同一个运行环境：它们各有 profile，插件装在哪一端，只在哪一端出现。 桌面端正常、Web 端空白，第一反应应该是「web profile 里有没有 Hub」，而不是重装。

1. 在终端跑 dsh plugin --profile web list，确认 Hub 是否在 web profile 里。
2. 不在列表里，先按 Web 端的方式装 Hub，再刷新页面。
3. 在列表里但页面空白，继续往下查端口、认证与缓存。
4. 同时确认桌面端装的是不是另一个 profile，避免把两端的现象混在一起。

先分清端，能排除一半「插件坏了」的误判。两端的插件列表不共享，一端正常不代表另一端也正常。

空白还是加载中：DSH Plugin Hub 的两种症状

空白和加载中是两种问题：前者是「该出现的东西没出现」，后者是「请求还没回来」。 看一眼页面骨架和开发者工具，就能分开。

1. 看侧边栏与会话区：都在、只有市场空，是局部问题；全白，是整页问题。
2. 看市场区域有没有转圈：转几秒变空白，通常是请求超时或被拒。
3. 打开开发者工具的 Console，看有没有脚本报错或资源 404。
4. 看 Network 里市场请求的状态码：404 是路由或资源，401 是认证，200 空响应是数据层。
5. 记录现象：局部/整页、转圈/直接空白、状态码，三项决定下一步。

症状分得越细，后面越省时间。最怕的是「看起来空白」就直接清缓存，结果把认证失败的证据一起清掉了。

端口、认证、缓存三层怎么查：DeepSeek Harness 的排查顺序

三层按「端口 → 认证 → 缓存」查：端口决定你能不能到，认证决定让不让你拿数据，缓存决定拿到的是不是旧页面。 顺序反了，会在错误的层反复试。

1. 端口：确认访问的是 http://127.0.0.1:3080，换过端口就用新地址；dsh web 拒绝绑定 0.0.0.0。
2. 认证：用终端本次启动打印的带 ?token= 地址访问一次，让它把令牌换成 cookie。
3. 认证细节：cookie 绑定 hostname 与 port，换端口或换 hostname 后旧 cookie 不匹配，要重新换一次。
4. 缓存：强制刷新页面，或在开发者工具里禁用缓存后再加载一次。
5. 资源：看 Network 里脚本、样式是否 404；升级后旧 chunk 不存在，会出现这种 404。

令牌 URL 属于进程凭据，别贴到聊天窗口或 Issue 里。认证与端口的完整机制见 dsh web 认证与 3080 端口。

图片能打开不代表认证通过

静态资源与非 index 资源可能保持公开，图片能显示只说明网络通，不说明会话有效。看到图标正常就跳过认证检查，会漏掉 cookie 失效这一层；判断标准是市场数据请求的返回码，不是页面有没有图标。

恢复顺序：DSH Plugin Hub 从刷新到桌面端对照

恢复按代价从小到大：刷新、带 token URL 重新认证、清缓存、最后用桌面端对照隔离变量。 每一步只改一个变量，改完立刻复现。

1. 先普通刷新一次页面，确认不是一次性加载失败。
2. 回终端，用本次启动打印的带 ?token= 地址重新访问，完成令牌换 cookie。
3. 仍然空白时，强制刷新或清站点缓存，再重新加载。
4. 清缓存后还空白，换一个干净浏览器配置复现，排除扩展拦截。
5. 最后打开桌面端对照：桌面端正常，说明问题在 Web 端链路；桌面端也空白，才回头查 Hub 本身。

顺序的价值是保留证据。先清缓存，你就无法判断原来是不是认证失效；先换浏览器，也无法判断是不是端口变化。每一步都记下「改了什么、结果如何」。

还不行时的取证清单：dsh plugin market 日志怎么看

四类证据收齐再动手：CLI 列表、Console、Network、两端版本；证据指向同一层，结论才可靠。 只凭「页面空白」一个现象，很容易在错误的方向重装。

1. dsh plugin --profile web list 的输出，确认 Hub 与目标插件在不在。
2. Console 里的脚本报错与资源 404 路径，截图保存。
3. Network 里市场请求的状态码与响应体，区分 401、404、200 空数据。
4. Hub 版本与 dsh --version，对照兼容声明。
5. 去「设置 → 插件市场 → 系统日志」导出本次操作的记录。

四类证据里，Network 的状态码信息量最大：401 指向认证，404 指向资源或路由，200 空数据指向目录拉取。拿到结论后，再决定是重新认证、清缓存还是重装 Hub。

取证的目标不是证明「谁坏了」，而是让下一步动作有依据。相邻的空白排查可以对照 插件市场打不开 与 Hub 空白但 CLI 正常。