上周五下午，我像往常一样在项目里跑 npm install结果 CI 直接红了。报错信息是一堆 “node-gyp rebuild failed”，native addon 编译全挂。

第一反应是 node 版本不对，检查了一遍发现没问题。 又以为是网络问题，挂代理重试，还是挂。 最终翻日志才发现——npm 开始提示一堆以前从没见过的 warning，说什么 “preinstall script will not run”。

我这才反应过来：npm v12 真的要来了而我完全没有准备。

项目在 CI 上失败的痛点

CI 环境中出现编译错误、网络超时、权限不足等情况。一旦依赖包内部脚本失效，整个建立链条都会被打断。对业务交付这种突发故障往往导致上线延迟甚至停机。

npm install 的隐藏脚本风险

实际来说。在这次翻车之前，我从来没仔细想过 npm install 到底在干什么。不就是下载依赖包吗，直到报错逼我去翻文档，才发现 npm 一直是这么玩的：当你执行 npm installnpm 不只是下载文件。它还会自动执行包里的生命周期脚本。package.json 里声明的 preinstallinstallpostinstallnpm 都会自动跑。其实，

很多包用这些脚本来编译原生模块、下载二进制资源、做环境初始化。例如 node-sass 要编译 C++ addon。sharp 要下载预编译的二进制，不跑脚本这些包根本没法用。

关键痛点：这些脚本跑的时候拿的是你当前进程的全部权限。

You 在 CI 机器上跑 npm install 时postinstall 脚本可以直接读取环境变量里的 AWS credentials、SSH key、npm token。它想干什么就干什么不需要任何确认。

I 一直以为 npm install 是安全的。实际来看，这种信任可能从一开始就是个误会。

供应链攻击已经盯上这个入口

The real alarm came from GitHub’s June announcement.

• NPM v12 will introduce a “史上最大安全变更”: installation scripts will no longer run automatically – you must approve m.
• The data is chilling:>% of supply‑chain attacks in JavaScript ecosystem are delivered via malicious post‑install scripts.
• This isn’t just ory – in June,Sapphire Slet group hijacked npm maintainers’ accounts to inject backdoors via post‑install scripts that harvested developers’ credentials across hundreds of packages.

If you’ve ever wondered what a post‑install script actually does on your machine…，

NPM v12 要改什么？ 主要三大硬改动

• 1️⃣ allowScripts 默认关闭。
• 2️⃣ allow-git 默认值变成 none。
• 3️⃣ 远程 URL 依赖也砍了。

The result?NPM becomes a default “no trust” package manager. Anything that wants to run must explicitly state *** it is trusted.

approve-scripts 是怎么工作的？怎么说呢，一步步手把手演示

NPM 官方提供了一个工具让你平滑过渡：.

# Scan all dependencies and list those with scripts
$ npm approve-scripts --allow-scripts-pending

The output shows every package that wants to run a script and what script it wants:

{
至于"name"。"my-project","scripts": {},"dependencies": {},"approvedScripts": {
"node-sass":,"sharp":
}
}

• You decide which scripts to trust.
• Aproving writes decision into `approvedScripts` in `package.json`.
• Your teammates pulling repo will see same approvals;unapproved scripts simply won’t run.

我的项目是怎么修复的？实战案例拆解

• #1 升级到最新 NPM：

$ npm i -g npm@latest
# Ensure version>=7
$ npm --version
7.x.x

• #2 扫描未批准的脚本：

$ npm approve-scripts --allow-scripts-pending
Find `sharp`,which needs a `postinstall` that downloads precompiled binaries.

#3 批准 `sharp` 的 postinstall：
$ npm approve-scripts sharp
This writes approval into `package.json`. Then rerun:
bash
$ npm i
The sharp binary download completes and your build passes. All in under ten minutes—less than time spent debugging original error.



但这个改动真的准备好了吗？团队面临的痛点 


*支持者*认为这是“迟到十几年的安全加固”，NPM 必须像浏览器一样默认关闭危险操作；*批评者*则指出许多老项目缺乏维护者，升级后连基本功能都无法使用。按理说，

说到*现实感受*。对于维护 native addon 或接手老项目的人这个过渡期确实有些疼。Approve‑scripts 清单可能长得让人望而却步。

*GitHub 已经给了预警机制*：NPM>=7 会提前抛 warning。但大多数开发者不会主动查看，除非遇到 CI 红色才反应过来。

从*建议*来看，将 approvedScripts 纳入代码审查；对不再维护或可替换的依赖及时剔除；保持团队对每个批准脚本进行安全审核。


你现在能做什么？不过，快速行动清单 



$ npm --version 检查当前 NPM 版本；若低于7，请先升级：
$ npm i -g npm@latest





$ npm approve-scripts --allow-scripts-pending 在每个项目中扫描待审批脚本；越早处理越好，以免遇到 NPM v12 发布后出现不可运行的问题。




bash
$ cd my-project && npm approve-scripts --allow-scripts-pending


此清单越早完成，你就能避免在发布窗口内被迫停工。

For team projects:
- Add approvedScripts section to PR templates / code review checklist.
- Verify each approved script’s intent & source.
- Replace or remove unmaintained dependencies whenever possible.

NPM 正在从一个“一键安装二合一”的工具转变为真正意义上的包管理器——这个过程虽然疼，但长期来看带来的安全收益远超短期的不便。