验证规则
本站把「实装验证」当作核心能力，因此把它的全部判据公开在这一页： 测到了哪一步、结论什么时候会失效、哪些东西不算失败、以及你如何自己复核。 所有数字实时取自数据库聚合，不写死。
- 已有验证结论 21,236 个 （确认可装 13,937 · 确认装不上 4,142 · 环境侧未得结论 3,157）
- 其中带 dsh 版本记录 14,481 个（当前 dsh 版本
0.2.2-rc.1） - 版本域分布 —— 当前有效 5 · 待复验 14,476 · 版本未记录 6,755
- 共收录 25,316 个插件（含尚未验证的）
一个结论是怎么产出的：五道关
从被收录到通过实装认证，一个插件要依次过五关。后一关的先决条件是前一关， 所以数字只会往下减，不会出现后一关比前一关多。
这是产线进度，不是质量分级。①–③ 是内容加工，④ 是静态可行性检查，⑤ 才是实装认证。 编号用 ①–⑤ 而非 L1–L5，是为了不与下面验证等级的 L4 / L5 混淆 —— 两套 L 编号并存会让「L4」既指静态评估、又指真实安装。
④ 与 ⑤ 当前数字相同不是巧合：静态检查产线晚于实装认证建立，现有 10,703 个已完成实装认证的插件还没有静态检查记录，级联到第 ④ 关就被截断。 这是产线时序问题，不是插件质量问题； 补数走独立任务，不在本页口径内消化。
① 验证等级：本站当前到 L5
等级回答的是「我们测到了哪一步」。 只有真的跑过那一步，才会标那个等级；标签不会因为「应该没问题」而升级。
L1–L3（仓库可访问 / 清单字段完整 / 可解析安装命令）属于静态检查， 本站以「静态安装检查」的形式展示在详情页，不计入上面的实装验证数。 生产队列线默认只执行 dsh plugin add（等价于 L4）； 开启运行时冒烟后，安装通过的目标会再用 dsh web 加载并校验三条客观判据， 全过才升为 L5 ——能装，不等于运行时正常，两级分开标。
- L5 · 运行时冒烟计入对外接口与徽章在真实 dsh 环境中加载插件并跑通冒烟：页面就绪标记、插件注册、聚合资产可取三条客观判据全过
- L5 · 实机截图计入对外接口与徽章安装成功，且本站截图管线在真实 dsh 环境中采集到该插件的界面截图
- L5 · 实机截图（作者提供）不计入对外接口与徽章安装成功，界面截图由作者或用户提供，**未经本站复核**
口径变更日：2026-10-07。 该日之前产出的 L5 全部来自运行时冒烟，因此该日之前的 L5 与该日之后的 L5不可直接对比。 作者或用户提供的截图之所以不计入对外发布的数据接口与徽章，是因为本站的验证结论 必须可复核、可被外部检验，而他人上传的图片无法校验真伪与时效； 把它当作本站结论对外发布，会让「已验证」这件事失去依据。 另需说明：无前端界面的插件本就截不到图，它们的 L5 只会来自运行时冒烟，这不代表它们的验证更弱。
本页讲的是判据； 已跑出来的结论、每条的证据原文与适用版本在 验证证据页。那里把 L5 按证据强度分成「已加载并运行」与「仅启动通过」两档分别计数 —— 同样标 L5，实际测到的深度并不相同。
② 结论有保质期：绑定 dsh 版本
「装成功过」是一次运行结果，只在当时那个 dsh 版本下成立。 dsh 升级后，插件可能因 API 变动而装不上 —— 若把旧结论当永久事实展示， 等于是给用户一个已失效的保证。
- 每次验证都会记录当时实际使用的 dsh 版本， 并且该版本常驻显示在详情页档位上 （形如「本站已于 N 天前在 dsh 0.2.0-rc.2 下真实安装成功」）—— 结论的适用范围始终可见，不必等到它过期才补一句。
- 该版本与当前版本的发布版本（X.Y.Z）不同时， 详情页档位降为「待复验」—— 语义是「我们还没在新版下复验」，不是「这个插件有问题」。
- 同一发布版本内的预发布迭代不判过期（如
0.2.0-rc.2→0.2.0-rc.3）。 依据是实测：dsh 只发布预发布版（截至 2026-09-30 共 29 个版本，全部带 -rc / -alpha 标识， 无纯正式版），而同一发布版本内的 rc 迭代是高频率事件。 若按「版本串严格不等」判定，每次迭代都会让全站结论作废并重新排队， 而按当前复验吞吐要数天才能跑完一轮 —— 这些复验注定赶不上下一次发版， 等于持续消耗掉有限的复验配额去换一次形式上的「最新」。代价要如实说明： 同一发布版本内的 rc 之间也可能有破坏性变更，因此「当前有效」这一档不等于「在当前版本下一定装得上」—— 这正是上面「版本常驻显示」存在的意义。 - 版本未记录的历史结论不判过期：没有证据就不下结论， 这是本站的一贯口径。但它也不等于「有效」—— 本站既不主张「没记录过版本就是过期」（那会制造数千条假警报）， 也不主张它「已经验证过」。它表达的是「无法判断」， 故在页面上单独统计，不与「有效」混计。
- 版本记录自 2026-09-23 起采集，此前的结论没有版本信息，正随验证轮次逐步补齐 （当前已记录 14,481 / 21,236 条， 其余 6,755 条尚无版本信息）。
| 状态 | 含义 | 条数 |
|---|---|---|
| 结论当前有效 | 验证时所用的 dsh 版本与当前版本属于同一发布版本（忽略 -rc / -alpha 等预发布标识） | 5 |
| 待复验 | 验证时所用的 dsh 发布版本与当前版本不是同一个 —— 意味着尚未在新版下复验，不代表插件有问题 | 14,476 |
| 版本未记录 | 结论采集于版本记录机制建立之前，无法判断其在新版下是否仍然成立（既不能当作有效，也不能当作过期） | 6,755 |
③ 三分法：不是所有收录物都是插件
有些收录对象本来就不该用 dsh plugin add 安装（桌面客户端、Web 外壳）。 如果不管这一点，页面会给一个正常项目挂上「实装验证未通过」， 看起来像插件有缺陷 —— 那是在冤枉作者。故分三类，生态应用从不计为失败。
| 分类 | 判定依据 | 已验证 | 其中装不上 |
|---|---|---|---|
DSH 插件 计入失败统计 | 声明了 dsh 能力（cordis / dsh bundle），可用 dsh plugin add 安装并挂载 | 19,316 | 3,943 |
生态插件 计入失败统计 | 可安装但未声明 dsh 能力（如 MCP server、Koishi 插件、客户端工具） | 795 | 46 |
生态应用 不计为失败 | 不以 dsh plugin add 方式安装（桌面端 / Web 外壳等），实装不通过不计为插件缺陷 | 1,125 | — |
④ 三态口径：宁可不给结论，也不给错结论
- 通过 —— 真实执行安装并成功。
- 未通过 —— 确实装不上，且原因属于插件侧 （仓库不存在、依赖冲突、Node 版本要求不满足等）。这类结论与「通过」一样有价值： 它让用户不必自己踩一次坑。
- 无结论 —— 失败来自验证环境本身而非插件，不构成对插件的判断。当前白名单：
build_script_blockednetworkgit_dep_unresolvableinstall_timeout（GitHub 通道中断、构建脚本被包管理器白名单拦截等）。 这类情况站内如实显示为「未验证」，不写成装不上。
⑤ 引用本站结论（面向插件作者）
本站验证结论可自由引用，需署名 dpharness.com。 请保留数据里的 generatedAt 时间戳，不要当作实时数据源转发。
curl -s https://dpharness.com/data/install/<包名或 owner/repo>.json[](https://dpharness.com/plugin/<owner/repo>)徽章文案为英文（L4 passed / failed /unverified），因为 SVG 需按字符估算宽度，中英混排容易破图； 徽章只表达等级与结论，不复刻详情页的完整信任档位 —— 徽章会被长期缓存、贴出去收不回来，宁可信息少，也不出错。