npm install 来源控制：先把 file、remote、directory 写进 allowlist

这篇解决什么

依赖可以来自 registry、Git、远程 tarball、本地文件和目录。若项目没有来源规则，恶意依赖更容易混进安装链路。

适合谁

适合前端团队、Node.js 服务团队、内部脚手架维护者和安全审计人员。

操作步骤

1. 扫描 package.json 和 lockfile 中的非 registry 来源
2. 确认每个来源的业务理由和维护人
3. 在 .npmrc 或 package.json config 中设置 allow 策略
4. CI 中先用严格策略跑安装测试
5. 对临时本地包建立替代发布流程
6. 将异常来源加入 PR 检查

可复制模板

依赖名：
来源类型：file / remote / directory / git
业务理由：
维护人：
允许策略：
替代方案：
CI 检查：

验收清单

• 非 registry 来源已盘点
• 允许理由可追溯
• CI 已测试
• PR 检查覆盖
• 异常来源有替代方案

常见错误

• 只收藏产品更新，没有把它改成当天能执行的工作卡。
• 只看发布标题，没有确认账号权限、适用版本、成本和数据边界。
• 把 AI 自动化结果直接当结论，没有保留人工复核和失败恢复动作。
• 外部链接散落在聊天记录里，后续复查时找不到来源和日期。

30 分钟小样本

先选一个真实但低风险的任务。前 5 分钟写清输入材料和目标产物；中间 15 分钟按本文步骤执行一次；最后 10 分钟记录输出、人工修改量、失败点和下一次复用条件。小样本通过后，再扩展到团队模板或固定 SOP。

复用方式

第一次执行时，把它当成个人操作卡；第二次执行时，把成功步骤整理成团队模板；第三次执行时，再判断是否值得升级成固定 SOP、工具页或培训材料。每次复查都要看官方页面是否改版、权限或价格是否变化、原来的示例是否还能跑通。

资料依据

• GitHub Changelog / Staged publishing and new install-time controls for npm / 2026-05-22

标签