插件市场装完找不到、卸载后入口还在？从两套记录理清 DSH插件 安装与卸载的归属边界与验证方法

插件市场里点过安装，回头却在设置里翻不到；点了卸载，市场里那张卡片又原样躺着。 这类困惑很少是操作失败，多半是没分清 DSH插件 的两套记录：市场目录记录「世界上有什么」，包管理器记录「这台机器装了什么」，入口见 DSH Plugin Hub。下面沿着这条分界，把安装、验证与卸载残留一次讲透。

装完找不到入口，先分清 DSH插件 的两套记录

装完找不到，通常说明插件已经落地，只是入口不在你以为的那一页。

市场卡片上的「已安装」只代表这条目录项与当前 profile 关联过，设置侧的入口是否出现，还取决于插件注册的页面、命令或侧边栏项。有些插件只增加一个命令，不会在设置里长出一个新面板，你自然找不到「它」。另一些插件要刷新页面甚至重启 dsh web 才会挂载界面，刚点完安装就去找，看到的还是旧页面。

更常见的情况是装错了 profile。web 界面读的是 web profile，而你在终端里用默认 profile 装的插件，在网页里当然不显示。这类错位不会报错，只会安静地让人以为安装失败。先确认界面与命令指向同一个 --profile，再谈入口问题。

还有一种「找不到」其实是查看路径不对。市场的搜索按名称与关键词匹配，已安装列表则可能按启用状态分组，插件被折叠在未启用一栏里。把市场、已安装、全部三个视图各翻一遍，比反复点安装有效得多。

从使用者的角度，更该问的是「这个插件承诺提供什么形态的入口」。有的插件只在命令面板里出现，有的会加一个设置分组，还有的纯粹在后台运行。先读插件条目里的说明，再决定去哪找，能省掉一半的来回。

插件市场管发现与触发，DSH插件 的落地交给包管理器

市场是橱窗加按钮，真正把文件放到磁盘上的是包管理器。

市场展示包名、版本、来源与维护者，让你在安装前做出判断。它把点击翻译成一条 add 命令，再把执行进度显示回来。目录里的条目可以一直存在，因为它描述的是「可安装的东西」，不是「已经装上的东西」。对 DeepSeek插件 来说，条目里还包含兼容的 Harness 版本区间，这也是目录信息的一部分。

包管理器负责解析依赖、选择版本、下载压缩包、写入 profile 的依赖清单。它只认包名与版本范围，不关心你是在哪个界面点的按钮。也正因如此，市场能触发安装，却不能替代包管理器。

这条分界解释了两个常见错觉：市场里还显示某个插件，不等于它还装在你机器上；命令行装好的插件，不刷新市场就看不到变化。把「目录状态」与「安装状态」分开看，困惑会少一大半。

把市场想成索引，把 profile 想成账本，两边的关系就清楚了。索引可以过时，账本却是当下的事实。排查时先翻账本，再回头理解索引为什么那样显示。

两边都要验证：市场看状态，dsh plugin 命令看事实

判断一次操作是否成功，要同时看界面状态与包管理器记录。

界面上看到的是渲染后的状态，命令看到的是磁盘上的事实。两者不一致时，以命令为准，再回头解释界面为什么没更新。缓存、未刷新、装错 profile，是三种最常见的解释。

1. 打开设置 → 插件市场 → 已安装，确认目标插件出现在列表里，而不是只看市场首页的卡片。
2. 执行 dsh plugin --profile web list，核对包名与版本是否与预期一致。
3. 若插件提供命令，直接运行一次，确认它确实能被解析到。
4. 刷新页面或重启 dsh web，看入口是否真的挂载出来。

命令行侧的最小验证只需要三条命令，安装、卸载、查看各一条：

dsh plugin --profile web add <包名>
dsh plugin --profile web remove <包名>
dsh plugin --profile web list

如果 list 里没有目标包，先别怀疑卸载按钮。确认命令里的 profile 是否与界面一致，再确认包名有没有拼错。两步都排除后，问题才回到包管理器本身。

反过来，list 里有包、界面却没有入口，就不要重复安装。这时该查的是插件是否需要重启、是否被禁用，以及它注册的入口是否属于当前页面。重复安装只会让依赖清单多一条无意义的记录。

验证时顺手记录包名与版本，后面排查会省很多事。名字相近的插件在市场上并不少见，靠图标辨认很容易点错。把 list 的输出留一份，等于给自己留了一张对照表。

卸载之后还有残留，DSH插件 留下的不只是依赖

卸载删掉的是依赖记录与包文件，删不掉的是它们曾经写下的东西。

市场卸载触发的是 remove，包管理器从 profile 的依赖清单里移除条目，再从包目录里清掉对应的文件。这一步通常很干净，失败也很少。问题出在包目录之外：配置、凭据、会话、缓存，都不归包管理器管。

$DSH_HOME 下的配置与密钥，是最常被误认为「应该一起删」的部分。它们按插件名或命名空间存放，卸载不会碰，重装还能接着用。会话与日志同理，删掉它们等于抹掉历史，工具不会替你做这个决定。

真正的残留多在缓存与索引：npm 的全局缓存、市场本地的缩略图与搜索索引、插件自建的临时目录。它们不影响功能，只占空间。想清理就按路径手动删，别指望卸载按钮代劳。

还有一类残留是界面上的。卡片仍在、计数没减、入口灰着，往往只是前端状态没刷新。重启 dsh web 后再看，多数会自行消失。如果重启后依旧存在，再去查 profile 与包目录。

什么时候卸载会留下真问题：DSH插件 的边界情况

大多数残留无害，少数残留会让下一次安装变得奇怪。

包冲突是第一种。旧版本的文件没被完全替换，新版本又写了同名路径，加载时可能读到混合内容。此时先 remove 再 add，比直接覆盖稳妥。若 remove 也报错，去看弹窗里给出的具体路径。

第二种是插件之间共享的运行时。某些插件依赖同一个原生模块或后台服务，卸载其中一个会顺手带走共享文件。表现是另一个插件突然报模块缺失。重新安装被卸载的那个，通常就能恢复。

第三种是残留配置引发的行为差异。配置还在，插件却没了，重装后它可能接着用旧设置，让人以为新版本没有生效。确认版本与配置来源，再判断是否要手动清理。

判断残留是否值得处理，可以看它会不会影响下一次加载。只占空间的缓存可以放着，会参与模块解析的旧文件则必须清掉。分不清时，先备份配置，再做一次干净的重装。

把分界记成习惯：DeepSeek插件 的安装与卸载都不神秘

市场负责让你看见并触发，包管理器负责让事情发生，残留则落在两者都不管的角落。

安装时多看一眼确认弹窗里的包名与来源，比事后排查省力得多。装完用命令核对一次，再刷新界面找入口，顺序反过来就容易误判。找不到时先问「装到哪个 profile 了」，而不是急着重装。DeepSeek插件 的入口也遵循同样的规则，先看它注册了什么，再看它在哪注册。

卸载时先想清楚要删到什么程度。只想让它不再运行，remove 足够；想连配置一起清，就得自己动手。把这两件事混为一谈，才会出现「卸了还在」的错觉。

最后留一句实用判断：界面说没有、命令说有，是缓存问题；命令说没有、界面说有，是渲染问题；两边都说没有、目录还在，才是真的残留。按这个顺序查，DSH插件 的安装与卸载就不会再绕圈。

这套判断不只适用于市场，也适用于任何图形化的包管理界面。界面越友好，越容易让人忘记底下还有一层账本。记住账本在哪，操作就始终可控。