多数团队最后落在两个位置之一：要么干脆禁用插件，要么谁都能加、没人看。插件评审流程是第三条路，而且比前两条都快。这篇讲新插件落地前要过的插件评审清单、PR 插件闸门放在哪里才不会变成瓶颈，以及一套把安装前审查新插件控制在十分钟而不是排一次会的 DSH 插件审批流程。
为什么禁用会失败，而放开更糟
禁用挡不住插件的使用，只是把它赶到个人机器和临时分支上去 —— 那里没有任何记录，也没有任何人审查。放开是相反的失败：依赖列表在长，审查面跟着长，等到第一次出事，你得在时间压力下审计上百条记录。
- 禁用：没有记录、没有审查，出事时回答不了「我们现在到底在跑什么」。
- 放开：记录完整、审查为零，依赖列表没人敢担保。
- 评审流程：记录存在，且审查的强度与风险匹配。
插件评审清单
控制在八条，按这个顺序。前四条是机械检查，大约四分钟；后四条是判断。
- 身份：索引上的名字和源仓库一致吗，中间有没有包装层？
- 新鲜度：看最后发布时间，不是最后提交时间。
- 安装路径：把安装脚本读一遍。任何运行时拉取的东西都要单独审。
- 评分：查当前 DSH 评分，更有用的是看它有没有在往下掉。
- 权限范围：它要的权限或文件访问，比它要干的活大吗？
- 维护：近三个月 issue 的响应时间。
- 巴士系数：近六个月有几个人提交过代码？
- 退出方案：如果下个季度要摘掉它，会断什么？
前四条拦的是供应链问题。后四条决定的是你愿不愿意依赖它一年。
PR 插件闸门放在哪里
PR 插件闸门是 CI 里的一条检查，在 pull request 改动插件清单时触发。它不做拒绝，只打印改了什么、审查者该看什么。有三个合理的落点。
| 落点 | 能拦住什么 | 成本 |
|---|---|---|
| 提交前钩子 | PR 还没建就已经发现拼写和名字错误 | 低，本地跑 |
| PR 检查（推荐） | 每一次清单 diff，附评分与安装脚本摘要 | 低，几秒钟 |
| 发布闸门 | 开发者在清单之外、装在机器上的插件 | 高，需要先有机器清单 |
从 PR 检查开始。它覆盖了几乎所有插件实际会走的那条路，而且它打印的 diff，本来就是人工审查者要手工拼出来的东西。
值得强制执行的阈值
在你还不需要的时候就先把数字定下来，而且别定太多。三档就够了。
| 档位 | 条件 | 动作 |
|---|---|---|
| 自动通过 | 评分 80 以上、安装脚本打包在内、索引名与仓库名一致 | 免审查直接合并 |
| 单人审查 | 评分 60 到 79，或某项机械检查不清楚 | 一次批准，清单附在 PR 上 |
| 暂缓 | 评分低于 60、安装脚本里有运行时拉取、或名字不一致 | 需要书面理由加第二次批准 |
什么都拦的闸门，一个月内就会被关掉。只打印 diff、只问一个问题的闸门活得下来，因为它比它替代的那场争论更便宜。
推行时不惹恼所有人的做法
- 先让闸门只报告、不拦截，跑两周。在强制之前，先看它本来会标出什么。
- 用一次提交把现有清单整体批准，让基线干净，之后的每次 diff 才有意义。
- 把清单放进 PR 模板，别放进一个没人打开的 wiki。
- 在清单里给每个插件写清一个负责人。负责人轮换是审查走样最常见的原因。
- 每季度复审一遍，而且只复审评分发生变化的那些。
常见问题
- 一次审查要多久？二档插件十分钟，其中大部分花在读安装脚本上。
- 会不会拖慢安装？不会。闸门跑在清单 diff 上，不在开发者机器上。
- 装在仓库之外、全局的插件怎么办？那是发布闸门那一档，而且先得有机器清单。
- 移除插件也要审吗？只有当初是三档批准的才需要，因为退出方案只写在那一档里。
先从清单和 PR 检查开始，其余的可以后补。团队层面的做法见 /blog/plugin-supply-chain-security-team-enforcement，单个插件的危险信号列在 /blog/how-to-avoid-risky-dsh-plugins，想先修你手头这份清单的话，/blog/setting-up-a-plugin-allowlist-for-your-dev-team 里有步骤。评分阈值在 /blog/dsh-quality-score-decoded 里讲过，完整插件索引在 /。