插件质量闸门（plugin quality gate）在安装时运行，于包进入运行时前拦下它。安装质量闸门（install quality gate）只花几分钟，而生产环境移除坏依赖要几天。
安装时是拦住坏依赖最便宜的时机
生产里的坏插件让你付两次钱：先排查没写过的代码，再改写调用点、重测、发布。一个依赖可能花团队三天清除。安装时审查十分钟，是便宜 200 倍的修法。
质量闸门到底该检查什么
- 维护新鲜度：上次提交何时？
- 维护者可联系吗：有联系人吗？
- 权限与网络：是否超出所需？
- 构建：是否捆绑脚本？
- 测试：是否自带套件，CI 在跑？
- 许可证：是否兼容分发？
- 下载来源：构件签名且一致？
- 版本固定：锁的版本即被评分版？
这些几秒就能从元数据拿到。陷阱是最后一条：插件在 1.4.0 评分好，却可能在 1.4.1 换主人而名字不变。把评分绑定到固定版本，而非包名。
| 闸门类型 | 检查项 | 误报代价 | 团队摩擦 | 适合谁 |
|---|---|---|---|---|
| 无闸门 | 不查 | 安装时零，生产极高 | 无 | 个人项目 |
| 提示型 | 低于阈值标记 | 低 | 轻微 | 多数团队 |
| 拦截型 | 安全问题安装失败 | 配置错时高 | 中等 | 大团队 |
误报问题
每次低分都拦的闸门，会被误报的工程师关掉。按风险分级：低风险插件保持提示型，展示评分、放行。只在安全信号上拦截。
首次安装与每次版本升级
只给首次安装设闸、自动放行更新，是常见错误。更新正是风险回流入处：插件被卖，发回传数据的版本，流水线因名字在白名单就接受。闸门应在每次版本升级运行。
写下策略，让它扛过人员流动
只记结论的策略会腐烂。“已拦截：插件 X” 换新主人后毫无意义。写下理由：评分哈希、失败信号、什么会改变判断。一条“维护者不可联系且申请网络时失败”的规则可审查、可交接。
为什么“我们相信作者”不是策略
信任是感觉，不是控制。一个作者这周可能被盗号或卖掉包。闸门要求你验证状态并重做。绝不用厂商自己的评分当闸门，评分必须独立于插件厂商。原因见 /blog/why-independent-plugin-scoring，评分在 /。
透明加权评分让闸门经得起质疑
没人能审的闸门会变成争吵。透明加权评分——维护、安全、文档、社区、性能，各自可见——把一个“不”变成可读句。被质疑时，你指向失败的那一维及其权重。这正是武断与可辩护的差别。
从这里开始
先上提示型闸门。记录每次安装与放行。两周后回顾哪些被放行、为什么。只有那时，才把可靠的规则升为拦截。
常见问题
质量闸门拖慢开发吗？只在安装时，慢几分钟。它避免几天 production 清理。记录放行的团队常发现 90% 安装未经触动就通过。
需要的插件没过闸怎么办？别悄悄绕过。记录信号，说明补偿控制，让提示型闸门记下放行。带理由的拦截可接受；静默绕过不行。
小团队负担得起吗？可以。多数检查是安装命令里的元数据查询。你要一个脚本、一个阈值、一个日志，而非平台。/ 上的评分免费提供加权输入。