2026 年 7 月前后，很多项目里的 npm install 会第一次显得“不听话”。不是 npm 坏了，而是 npm v12 准备把几类过去默认会发生的事，改成默认不发生。
反常点在这里：开发者以为自己只是在装依赖，npm 实际上常常还在运行别人的脚本、拉 Git 仓库、解析远程 tarball。v12 的新默认值等于把一句话摆到台面上：你可以继续信，但要把信任写下来。
v12 改了三个默认信任
npm v12 预计 2026 年 7 月发布。npm 11.16.0+ 已经能通过 warning 提前暴露相关问题。这个安排很现实：别等升级当天才发现 CI/CD 卡在安装阶段。
| 变化项 | v12 默认值 | 会拦什么 | 不是在做什么 |
|---|---|---|---|
allowScripts | 默认关闭 | 未获批准的依赖 preinstall、install、postinstall | 不是禁用所有安装脚本 |
--allow-git | 默认 none | 直接或间接的 Git 依赖解析 | 不是永久封杀 Git 依赖 |
--allow-remote | 默认 none | https tarball 等远程 URL 依赖 | 不是封死所有非 registry 场景 |
最容易误读的是脚本。准确说，npm v12 默认不执行未获批准的依赖脚本。项目自己信任的包，仍然可以进 allowlist。
原生构建包要格外留意。一个包只要有 binding.gyp，哪怕没有显式写 install 脚本，npm 也可能隐式跑 node-gyp rebuild。v12 下，这类行为也会被拦。
Git、file、link 依赖里的部分 prepare 脚本，也会按同一逻辑处理。allow-file 和 allow-directory 的默认值不变，所以这次不是一刀切。
Git 依赖被收紧，有明确安全理由。GitHub 给出的解释是：Git 依赖里的 .npmrc 可能改写 Git 可执行路径，即使用了 --ignore-scripts，仍可能形成代码执行风险。这个细节很要命。它说明“安装依赖”早就不是一个干净动作。
最先疼的是维护者和 CI
普通开发者会看到 warning。生产项目维护者会看到成本。
最相关的两类人，一类是 Node.js / npm 项目维护者，一类是管前端供应链和 CI/CD 的工程团队。他们要做的不是等 v12，而是现在用 npm 11.16.0+ 跑一次正常安装。
动作很具体：
| 对象 | 现在该做什么 | 不做的后果 |
|---|---|---|
| 项目维护者 | 升级 npm，跑 npm install，看 warning | v12 升级时才发现依赖脚本被拦 |
| CI/CD 团队 | 检查构建镜像、锁文件策略、内网包来源 | 安装阶段失败，问题难定位 |
| 企业依赖治理团队 | 用 npm approve-scripts / npm deny-scripts 生成 allowlist | 白名单靠口头约定，审计时说不清 |
迁移路径并不复杂，但需要有人负责。
先升级到 npm 11.16.0 或更高版本。跑一次正常安装。再用 npm approve-scripts --allow-scripts-pending 找出会跑脚本的包。
可信的包执行 npm approve-scripts。不可信或暂时不用的包执行 npm deny-scripts。生成的 allowlist 会写入 package.json，应该提交进仓库。
这里有一个现实约束：依赖树越深，人工判断越贵。工具给 warning 只是开始，真正费时间的是回答三个问题：这个脚本为什么需要跑？这个 Git URL 为什么可信？这个远程 tarball 为什么不能换成 registry 包？
如果团队最后只是一路 approve，把所有提示点成绿色，那 v12 只会制造新仪式。安全边界看起来更厚，实际还是橡皮图章。
便利开始付账
我更在意的不是破坏性更新本身，而是 npm 把责任边界改清楚了。
过去的默认逻辑是：生态为了顺滑，工具替你信任。脚本自动执行，原生包更容易装上；Git 依赖能直接拉，内部包和临时修复更省事；远程 tarball 能解析，绕过常规发布流程也更方便。
这些便利不是免费的。只是账单以前藏在安装流程里。
这次 v12 没有消灭复杂性。它只是把复杂性从 npm 的默认行为里拿出来，放回项目维护者桌面上。谁能执行代码，谁能拉远程源，谁能绕过 registry，都要留下痕迹。
这很像早期互联网平台从“随便接入”走向权限审核。阶段不完全一样，但权力结构相似：扩张期奖励低摩擦，治理期开始追问边界。旧账不会自己消失，只会换一种格式出现。
我不太买账“安全又拖慢开发体验”的抱怨。真正拖慢开发体验的，往往是过去没有记录信任关系。等事故发生，再回头问哪个依赖跑过脚本、哪个 Git URL 被拉过，那个成本更高。
但 npm 也不能把这事包装成纯胜利。显式许可会把治理成本推给维护者。尤其是企业内网包、原生构建包、历史 Git 依赖很多的项目，迁移不会轻。
接下来最该看的不是 v12 有没有按期发布，而是三件事：warning 是否足够可读，allowlist 是否便于审计，团队会不会把 approve 当成例行点确认。
分水岭不在 2026 年 7 月。分水岭在那张 allowlist 是安全清单，还是新的形式主义。
回到开头那句：npm install 以后会更不听话。对一个会替你执行陌生代码的工具来说，这反而是迟到的成熟。