dsh plugin hub 空白但 CLI 正常：DeepSeek Harness 前端资源、版本与缓存

dsh plugin hub 一片空白、命令行却能正常列出插件，这个组合本身已经把范围缩小了一半。 DeepSeek Harness 的后端与插件安装大概率是好的，问题落在页面拿到数据之后的那一段链路上。

命令行正常说明 DeepSeek Harness 的哪些部分还活着

CLI 能列出插件，只能证明包在、profile 对、注册表读得到，证明不了浏览器能渲染。

dsh plugin list 的输出来自本地安装目录与注册表，它不经过前端打包，也不依赖浏览器缓存。所以当它正常返回时，你可以先排除插件没装、装错 profile、注册表损坏这几类问题。很多人一看到空白就去重装，其实是在修一个本来没有坏的地方。

命令行走的是进程内调用，页面走的是 HTTP 加静态资源两条链路。前者只要能读到文件就能出结果，后者还要经过路由、鉴权、接口和渲染四道关。两条链路共用的是数据，不共用的是呈现方式。

这也是为什么 CLI 正常反而是一个有价值的线索。它把问题从「插件坏了」收窄到「页面没把插件显示出来」，排查范围一下子小了很多。接下来要做的不是继续在命令行里找答案，而是去看页面到底卡在哪一步。

当然，CLI 也有它看不到的地方。它不知道 Hub 的前端包版本，也不知道浏览器缓存里存着哪个旧的 chunk。把它当作排除法的一步，而不是最终结论，后面的判断才不会跑偏。

dsh plugin hub 空白，先分清局部还是整页

只有 Hub 区域空白和整个界面空白，指向的是两套完全不同的原因。

如果侧边栏、会话区和设置页都正常，只有插件市场那块是空的，问题基本锁在 Hub 这个插件自己的前端资源上。它的脚本没加载、路由没注册，或者接口返回了空数组，都会表现成同一块空白。

如果整个 Web UI 都是白的，连侧边栏都没有，那就要往前退一步看客户端本身。这时候 Hub 只是受害者，真正的问题可能是主 bundle 加载失败、入口脚本报错，或者服务根本没起来。

分辨方法很朴素：换一个页面看骨架在不在。骨架在而内容空，是局部问题；骨架都没有，是整页问题。这个判断不需要任何工具，却能决定你接下来该翻哪一份日志。

还有一种中间状态：页面有骨架，Hub 区域显示加载中的转圈，几秒后变成空白。这通常意味着请求发出去了但超时或被拒绝，方向应该转向网络与接口，而不是继续怀疑安装。

客户端与网络：DSH插件 的请求到底发出去了没有

控制台的红色报错和网络面板的状态码，比反复刷新页面更能说明问题。

打开开发者工具，先看 Console 里有没有脚本异常，再看 Network 里 Hub 相关请求的返回。请求根本没出现，说明前端在发起之前就挂了；请求出现但状态码是 404 或 500，说明服务端或路由有问题；状态码 200 而响应体是空的，那才是数据层的问题。

代理和网络策略确实会造成空白，但它们通常不会只针对 Hub。如果代理配置错了，整个页面都打不开，而不是市场区域单独空着。所以 CLI 正常时，网络因素的优先级应该排在资源与版本之后。

浏览器扩展是另一个容易被忽略的变量。广告拦截、脚本拦截和隐私插件都可能拦掉 Hub 的请求，尤其是在无痕窗口里一切正常的时候。换一个干净的浏览器配置复现一次，能很快排除这一类干扰。

如果请求返回的是旧结构的数据，页面也可能渲染失败。这种情况看起来像网络问题，实际上是版本问题，下一节会接着讲。别急着改代理，先确认响应体的字段名和当前前端期待的是不是同一套。

资源层：DeepSeek Harness 的前端包有没有配上

接口有数据但页面空白，多半是脚本或样式没加载完整。

DeepSeek Harness 的 Hub 前端以静态资源的形式随插件发布，升级后文件名里通常带哈希。如果浏览器还持有旧页面，它请求的哈希可能已经在服务器上不存在，控制台会留下一串 404。

这类问题的典型特征是强制刷新后偶尔恢复，或者换浏览器就正常。它不是数据坏了，而是页面和资源对不上。清理站点缓存、重启客户端，让资源重新打包加载，通常就能解决。

还要留意资源加载的路径。反向代理如果改写了静态目录，或者把子路径吃掉，脚本就会全部 404，而接口仍然正常。这时候页面骨架可能还在，因为 HTML 是服务端直出的，但所有交互都不会响应。

资源问题最忌讳的处理方式是直接重装。重装会覆盖现场，让你失去判断依据，而且大多数时候资源并没有真的损坏。先看 404，再决定要不要动安装目录。

版本层：DeepSeek Harness 与 Hub 两条线错位

Hub 是插件，本体是运行时，升级后空白最常见的根因是两条版本线没有对齐。

在 DSH Plugin Hub 的条目页里，通常会写它支持的 DSH插件 版本范围，本体也有自己的发布节奏。两者的版本号不必相同，但必须落在兼容区间里。只升了其中一条，页面就可能读不懂对方给的字段。

判断方法很直接：记下 Hub 版本，再记下 dsh --version 的输出，对照条目或仓库里的兼容声明。如果声明缺失，就在隔离环境里先验证，不要直接在日常环境里试。

版本错位的症状往往有规律。升级后突然空白、字段显示成 undefined、分类消失、详情页打不开，这些都指向新前端配了旧接口，或者旧前端碰上了新字段。回退之前先确认是哪一侧先动的手。

顺便说一句，DSH插件 与 DeepSeek插件 在这类问题里没有区别，它们都受同一条兼容规则约束。版本对齐靠的是声明，不是感觉。把兼容组合记下来，下次升级就不用重新猜。

把 DSH plugin 的四类证据收齐再动手

先取证再操作，能避免在错误的方向上反复重装。

证据不需要多，四样就够：命令行能否列出插件、控制台有没有报错、Hub 请求返回了什么、两条版本线各是什么。把它们写在一起，问题的层级基本就浮出来了。

取证时顺手截图，尤其是控制台和网络面板。截图比记忆可靠，也比事后复述更容易让同事看懂。如果问题只在一台机器上出现，记得把浏览器版本和操作系统一起记下来。

接下来按这个顺序动手，每一步只改一个变量，改完立刻复现。如果一次改了两处，你就无法判断是哪一处起了作用。排查的价值不在于动作多，而在于每个动作都能被解释。

1. 在命令行确认 Hub 已安装，并记下它的版本。
2. 打开控制台，截图保存脚本报错与资源 404 的完整路径。
3. 在网络面板里找到 Hub 的数据请求，记录状态码与响应体。
4. 对照条目页或仓库说明，确认 Hub 与本体的兼容区间。
5. 只做一处改动，刷新后立即复现，确认症状是否变化。
6. 问题解决后把版本组合与日期写进记录。

如果四类证据指向同一个层级，结论就可以下了。指向不一致时，优先相信靠前的证据，因为越靠近进程和网络的观察越少受缓存影响。至于重装，留到证据用完还没有解释的时候再说。

来源：DSH Plugin Hub 插件条目、dsh-plugin-hub 仓库、DeepSeek Harness 快速开始。