插件市场安装失败怎么看通知:DSH Plugin Hub 通知中心、系统日志与确认弹窗排查顺序
点了三次安装,卡片一直转圈,关掉弹窗后再也找不到错误——这是插件市场安装失败最常见的现场:不是没有错误,而是错误只出现了一次。 DSH Plugin Hub 其实留了三个证据源:确认弹窗、通知中心、系统日志(2.2.5 索引)。问题在于大多数人只看弹窗,弹窗一关就失去线索。这篇按分诊表走:先判断该看哪个源,再按日志把失败落到具体阶段。入口在 DSH Plugin Hub。
先分清三个证据源:DeepSeek Harness 的通知、日志与弹窗
三个证据源回答三个不同问题:弹窗回答「这次操作失败了吗」,通知中心回答「刚才发生了什么」,系统日志回答「为什么会这样」。 用错证据源,就会在错误的界面上反复刷新。
| 你现在的状态 | 该看哪里 | 能看到什么 | 局限 |
|---|---|---|---|
| 刚点完安装,弹窗还在 | 确认弹窗 | 插件名、来源、将执行的命令 | 只有摘要,关掉就没了 |
| 弹窗关了,任务失败 | 通知中心 | 历史记录、进度、失败上下文 | 清空后不可恢复 |
| 知道失败,但不知道原因 | 系统日志 | 分类、级别、时间、完整条目 | 记录多,需要筛 |
- 安装前先打开通知中心,让它有机会记录整个过程。
- 弹窗出现时先截图或复制插件名与来源,别急着点确认。
- 失败后先回通知中心复制完整日志,再去系统日志找同一时间点。
- 两个源都拿不到信息时,再复现一次,并且只复现一次。
三个源不是替代关系。弹窗负责「当场确认」,通知中心负责「事后回看」,系统日志负责「定位原因」;顺序反了,就会变成在日志里大海捞针。
通知中心先看哪三类记录:DSH Plugin Hub 的进度、失败与待重启
通知中心里优先看三类:失败任务、卡在进行中的任务、带待重启提醒的任务。 其余成功记录扫一眼即可,它们的主要价值是给你一条时间线。

- 打开通知中心,先按时间倒序看最近三条记录。
- 找到失败任务,点开并复制完整日志;不要只记最后一行红字。
- 看到长时间「进行中」的任务,先判断是网络慢还是进程卡住,别连续重复提交。
- 看到「待重启」提醒,说明安装已写入但没挂载,直接重启宿主,不要重装。
- 清理记录前先把要留的证据复制或截图,一键清空不可撤销。
「待重启」是最容易被误判的一类:用户以为安装失败,其实只是还没重启。它和真正的失败在通知中心里表现不同——前者有完成记录,后者没有。把这条分清,能减少一半无效重装。
清空之前,至少留下三样东西
- 失败任务的完整日志,用「复制」取走,不要只截最后一行。
- 本次操作的插件名与来源仓库,方便回市场或仓库核对。
- 操作时间点,用来和系统日志里的条目对齐。
三样东西留齐,即使通知记录被清掉,你仍然有一条可复现的线索。
系统日志怎么筛:dsh plugin market 的分类与级别
系统日志的筛法是「先分类、再级别、最后时间」,三步缩到几条再读。 直接从头翻,几百条记录里很难找到与这次失败对应的那一条(2.2.5 索引)。
- 进「设置 → 插件市场 → 系统日志」,先点「刷新」。
- 分类筛到安装、卸载、更新或设置变更中与本次操作对应的那一类。
- 级别筛到错误或警告;没有错误时再看信息级,确认请求是否发出。
- 用复现时间对齐条目,只读本次操作之后新增的记录。
- 需要带走证据时,用「复制全文」或「导出日志」,不要手抄。
日志页还能改存放位置并「打开文件」。如果你打算长期排查,把日志指到自己的工作目录,下次对比更方便。分类与级别之外,时间是最可靠的锚点:先记下你点安装的时刻,再回日志里找那一分钟。
从日志落到四个阶段:DSH plugin 下载、解包、依赖、加载
同样一句「安装失败」,落在四个阶段时修法完全不同:下载看网络,解包看文件,依赖看包管理器,加载看入口。 先定位阶段,再决定动作,比直接重装有效。
- 下载阶段:日志里是超时、连接重置或 404。先查代理与镜像,404 时换官方源验证,不要改包名。
- 解包阶段:日志里是压缩包损坏、写入失败或权限不足。查磁盘空间、目标目录权限与杀软拦截。
- 依赖阶段:日志里是 pnpm 解析失败、构建脚本被拒或版本冲突。查依赖声明、构建脚本确认与包管理器版本。
- 加载阶段:日志里是入口文件缺失、模块解析失败或激活报错。查 package.json 的入口与实际产物,源码安装尤其常见。
四个阶段对应四类证据:网络错误、文件错误、依赖错误、代码错误。把日志里的关键词对到阶段,再回到本文开头的分诊表选处置方式。更完整的失败地图见 插件安装失败地图。
| 阶段 | 日志里常见线索 | 先查什么 | 不要做什么 |
|---|---|---|---|
| 下载 | 超时、连接重置、404 | 代理、镜像源 | 改包名 |
| 解包 | 解压失败、写入失败、权限不足 | 磁盘、目录权限、杀软 | 重复下载 |
| 依赖 | pnpm 解析、构建脚本、版本冲突 | 依赖声明、构建脚本确认 | 手删 lockfile |
| 加载 | 入口文件缺失、模块解析、激活失败 | 入口产物、版本兼容 | 直接重装 |
修完怎么验证:DeepSeek Harness 插件真的生效了吗
修完不等于生效,验证要看三处:已安装列表、重启后的入口、日志里没有新的激活错误。 只看到卡片变绿,只能说明写入完成。
- 回「已安装」列表,确认条目在、版本对、来源标签正确。
- 重启 DeepSeek Harness,重新打开插件提供的入口、命令或面板。
- 实际调用一次插件能力,确认不是只有界面出现。
- 再回系统日志,确认没有同一插件的新错误。
- 如果仍失败,保留这次的日志与时间点,再按四阶段重新定位。
验证时不要同时改多个变量:先重启、再看入口、最后看日志。一次只动一处,才能知道是哪一步修好的。通知中心与系统日志的配置入口,见 DSH Plugin Hub 设置怎么配;安装阶段的日志细节,还可以对照 插件市场安装日志怎么看。
常见问题
DeepSeek Harness 里先打开通知中心,失败任务会留在历史记录里,可以复制完整日志再关掉。弹窗只显示摘要,通知中心保留本次任务的进度与失败上下文;如果通知中心也被清空,再去系统日志按分类与级别找同一时间点的条目。
DeepSeek Harness 的通知中心优先看三类:失败的安装或更新任务、长时间停在进行中的任务、以及带待重启提醒的任务。前两类指向失败原因,第三类解释「装完了为什么没生效」;历史记录可以单条删除,清空前先把证据复制出去。
DeepSeek Harness 的系统日志先按分类缩到安装、卸载或设置变更,再按级别缩到错误与警告,最后用复现时间对齐条目。分类决定「哪类操作」,级别决定「严重程度」;两步都筛完还很多,再用「刷新」复现一次,只看新增记录。
DeepSeek Harness 里四个阶段的日志特征不同:下载阶段多为超时或 404,解包阶段多为压缩包或文件写入错误,依赖阶段多为 pnpm 解析或构建脚本失败,加载阶段则是入口文件缺失或激活报错。先定位阶段,再决定是换网络、换来源还是修依赖,别一上来就重装。
DeepSeek Harness 里要确认三处:已安装列表能看到条目与版本、重启后插件入口或命令真的出现、系统日志里没有同一插件的激活错误。只看卡片变成「已安装」不够,那只是写入完成;入口出现且能调用,才算生效。
相关术语
- 通知中心
- 通知中心是 DSH Plugin Hub 里集中查看安装、卸载、更新历史、进行中任务进度与待重启提醒的弹窗。它支持复制完整日志、删除单条记录与一键清空。— https://api.dsh-plugin.org/images/releases/2-2-5/index.json
- 系统日志
- 系统日志是 DSH Plugin Hub 记录安装、卸载、设置变更与诊断等操作轨迹的页面,按分类与级别展示条目。它支持打开日志查看器、复制全文、导出日志、刷新与定位日志文件。— https://api.dsh-plugin.org/images/releases/2-2-5/index.json
- 待重启提醒
- 待重启提醒是通知中心里提示「插件已写入但尚未挂载」的状态记录。它解释为什么安装完成后入口还没出现,处理方式是重启宿主而不是重复安装。— https://api.dsh-plugin.org/images/releases/2-2-5/index.json
- 安装阶段
- 安装阶段是 DSH plugin 从发起到可加载的四个环节:下载、解包、依赖安装与加载激活。每个阶段的失败对应不同的日志特征与处置方式。— https://github.com/dshplugin/dsh-plugin-hub
来源
- DSH Plugin Hub 2.2.5 界面截图索引· dsh-plugin.org
- dshplugin/dsh-plugin-hub 仓库· GitHub
- deepseek-ai/deepseek-harness(源码仓库)· GitHub