验证规则

① 验证等级：本站当前到 L4

等级回答的是「我们测到了哪一步」。 只有真的跑过那一步，才会标那个等级；标签不会因为「应该没问题」而升级。

L1–L3（仓库可访问 / 清单字段完整 / 可解析安装命令）属于静态检查， 本站以「静态安装检查」的形式展示在详情页，不计入上面的实装验证数。 本站的实装验证执行的是 dsh plugin add，等价于 L4 ——能装，但不代表运行时一定正常， 这一点请以 L4 的语义为准，不要当成「已完整测试」。

② 结论有保质期：绑定 dsh 版本

「装成功过」是一次**运行结果**，只在当时那个 dsh 版本下成立。 dsh 升级后，插件可能因 API 变动而装不上 —— 若把旧结论当永久事实展示， 等于是给用户一个已失效的保证。

• 每次验证都会记录**当时实际使用的 dsh 版本**。
• 该版本与当前版本不一致时，详情页档位降为「待复验」—— 语义是「我们还没在新版下复验」，**不是**「这个插件有问题」。
• 版本未记录的历史结论不判过期：没有证据就不下结论， 这是本站的一贯口径。但它也不等于「有效」—— 本站既不主张「没记录过版本就是过期」（那会制造数千条假警报）， 也不主张它「已经验证过」。它表达的是「无法判断」， 故在页面上单独统计，不与「有效」混计。
• 版本记录自 2026-09-23 起采集，此前的结论没有版本信息，正随验证轮次逐步补齐 （当前已记录 32 / 4,238 条， 其余 4,206 条尚无版本信息）。

③ 三分法：不是所有收录物都是插件

有些收录对象**本来就不该用 dsh plugin add 安装**（桌面客户端、Web 外壳）。 如果不管这一点，页面会给一个正常项目挂上「实装验证未通过」， 看起来像插件有缺陷 —— 那是在冤枉作者。故分三类，**生态应用从不计为失败**。

④ 三态口径：宁可不给结论，也不给错结论

• 通过 —— 真实执行安装并成功。
• 未通过 —— 确实装不上，且原因属于插件侧 （仓库不存在、依赖冲突、Node 版本要求不满足等）。这类结论与「通过」一样有价值： 它让用户不必自己踩一次坑。
• 无结论 —— 失败来自**验证环境本身** 而非插件，不构成对插件的判断。当前白名单：build_script_blockednetworkgit_dep_unresolvable（GitHub 通道中断、构建脚本被包管理器白名单拦截等）。 这类情况站内如实显示为「未验证」，不写成装不上。

⑤ 引用本站结论（面向插件作者）

本站验证结论可自由引用，需署名 dpharness.com。 请保留数据里的 generatedAt 时间戳，不要当作实时数据源转发。