2026年5月，它发了第11个主版本。改动不小——分发格式切成纯 ES6 模块，发布流程不再依赖 npm CLI，供应链安全默认拉满。如果你还在用 v10，这次升级值得看看。
纯 ES6 模块分发，Node.js 22 起步
v11 最显眼的变化是自己先变成纯 ESM 了。不再提供 CommonJS 分发包，同时要求至少 Node.js 22 起步，砍掉了对 18、19、20、21 的支持。
门槛不算高——Node.js 22 在 2025 年就是 LTS 了。但如果你的 CI 镜像还在跑 Node.js 20 甚至更老的版本，升级之前得先同步更新一下 Node.js。
另外，独立可执行文件要求 glibc 2.27+。还在用 CentOS 7 那类老镜像的话，需要留个心眼。
供应链安全不再是选项，是默认
这大概是新版最重要的变化，也说明 package manager 在 Node.js 生态里的角色在变。
新包强制延迟 24 小时
npm 攻击的套路大家都熟：攻击者劫持维护者账号，发一个带后门的版本，等 CI 自动拉取。Mini Shai-Hulud 那类供应链攻击就是这么干的——用 preinstall 钩子下载 Bun 运行时，执行混淆后的凭据窃取脚本，目标直指开发者环境和 CI/CD 密钥。
v11 的应对很直接：新发布的包默认延迟 24 小时才能被解析安装。`minimumReleaseAge` 默认 1440 分钟。不管攻击者多快发布恶意版本，你有整整一天缓冲窗口等社区发现并清理掉问题包。
如果急着要某个刚发布的安全修复，可以用 `pnpm audit –fix` 自动加白名单绕过。或者在配置里设 `minimumReleaseAge: 0` 完全退出。
阻断非标准依赖来源
`blockExoticSubdeps` 现在默认开了。所谓 exotic subdeps，就是从 Git 仓库、tarball URL 这类来源解析的传递依赖。这些来源不受 npm 注册表管控，经常被用来藏私货。默认阻断相当于给依赖图加了一道安检。
统一的构建脚本控制
v11 用 `allowBuilds` 统一替换了之前分散的五个配置项。一个 map 就能精细控制哪些包能执行构建脚本：
“`yaml
# pnpm-workspace.yaml
allowBuilds:
electron: true
core-js: false
esbuild: false
“`
生命周期脚本一直是 npm 攻击里被滥用最多的路径。这套新模型不能替代代码审查，但至少让管控更清晰，团队一眼能看到哪些包有执行权限。
原生发布流程：告别 npm CLI
从项目诞生那天起，publish 底层一直在调 `npm publish`。v11 把这个问题解决了——publish、login、logout、view、deprecate、unpublish、dist-tag、version 全用原生实现。
少一层依赖，就少一个攻击面。以前 npm CLI 的 bug 会影响用户，现在发布流程完全自己掌控。OTP 环境变量也从 `NPM_CONFIG_OTP` 改成了 `PNPM_CONFIG_OTP`，Web 认证支持扫码登录。
SQLite 存储索引与性能提升
v11 的 Store 架构升到了 v11。最大改动是把原来数百万个 JSON 文件合并到单个 SQLite 数据库。WAL 模式支持并发访问，包的 manifest 信息直接存入索引，省了安装时反复读 package.json 的开销。
其他优化：
– 用 undici 替代 node-fetch 处理 HTTP，支持双栈连接
– 已知大小的 tarball 下载预分配内存，避免重复拷贝
– 元数据缓存改 NDJSON 格式，配合 If-Modified-Since 做条件请求
– CAS 文件直接写入内容寻址路径，省去临时文件加重命名——冷安装减少约 3 万次 rename 调用
– 全局虚拟存储启用后，约 95% 的包在 Node.js 升级或架构变更时无需重新导入
一个数据点：有缓存和 lockfile 的 warm install 场景下，只要 2.3 秒。
全局安装隔离
`pnpm add -g` 的行为变了。每个全局包现在都有独立的目录、package.json、node_modules 和 lockfile，互相不干扰。之前因为 peer 依赖冲突导致全局工具罢工的情况，应该会少很多。
全局安装的二进制文件放 `PNPM_HOME/bin` 子目录下，不再直接丢进 `PNPM_HOME`，shell 补全也更干净。
SBOM 生成与审计升级
v11 加了一个企业场景的命令：`pnpm sbom`，能生成 CycloneDX 1.7 或 SPDX 2.3 格式的软件物料清单。项目要过合规审计的话很实用。
audit有两个更新：
1. `pnpm audit –fix=update`：不再靠加 overrides 修漏洞，直接在 lockfile 里更新到修复版本。
2. 切到 GHSA 过滤：npm 注册表废弃了旧的 CVE 审计端点，改用 GHSA。迁移时要把原有的 CVE 条目换成对应的 GHSA。
配置体系重构
v11 清理了配置体系：`.npmrc` 只管鉴权和注册表设置，特有的配置全移到 `pnpm-workspace.yaml` 或新的 `config.yaml`。`npm_config_*` 也被 `pnpm_config_*` 取代。
嫌迁移麻烦的话，官方提供了 `pnpm-v10-to-v11` codemod，大部分配置变更可以自动处理。
接下来：v12 与 Rust 安装引擎
团队已经在开发下一代引擎 [Pacquet](https://github.com/pnpm/pacquet)，基于 Rust 重写，预计 v12 落地。第一阶段聚焦 fetch 和 link，后续再覆盖依赖解析。
官方放的 benchmark 有点意思：lockfile-only 的无缓存安装场景，Rust 引擎 3.1 秒，v11 要 4.7 秒。Warm install 更夸张——902 毫秒对 2.3 秒。还没到生产就绪，但方向很清楚了。
总结
v11 的核心变动：
– 安全：供应链保护从可选变成默认，延迟新包、阻断非标准依赖、统一构建脚本控制。
– 自主：告别 npm CLI 依赖，发布流程原生实现。
– 性能：SQLite 替换 JSON 索引，undici 替换 node-fetch，存储架构重写。
– 清理：纯 ESM、Node.js 22 起步、配置体系重构。
不只是版本号加一。新项目建议直接上 v11；现有项目看完 Breaking Changes 清单再迁移——大部分改动 codemod 能自动处理，最需要关注的是 Node.js 版本和配置迁移。
下一站 v12 的 Rust 引擎。package manager 之间的竞争，越来越有意思了。
—
*参考来源：*
[v11 Adds Supply Chain Protection Defaults – Socket]
[v11 Release Candidate: ESM Distribution, Supply Chain Defaults – InfoQ]
📖 推荐阅读
看完工程化的内容，也看看这些跟前端工程师以及AI有关的文章，你可能会感兴趣：
React Compiler 1.0 来了：以后useMemo 和 useCallback 可以删了？
React 19 与 Vue 3.6：同一个2026年，两种不同的前端哲学