为什么pnpm要重写
pnpm 11及以下版本基于Node.js实现，在大规模monorepo（500+包）场景下出现明显瓶颈：安装时间长、内存占用高、CI缓存命中率低。用Rust重写核心后，性能提升显著但保持接口兼容。
性能对比实测
测试环境： Node.js 20, monorepo含487个包，首次冷安装
| 指标 | pnpm 11.12 | pnpm 12.0 | 提升 |
|---|---|---|---|
| 安装时间 | 142s | 38s | 3.7x |
| 内存峰值 | 2.1GB | 680MB | 68%降低 |
| CPU利用率 | 85% | 45% | 47%降低 |
| disk I/O | 高 | 中 | 减少重复读取 |
二次安装（缓存命中）：pnpm 11需18s，pnpm 12仅需6s，提升3倍。
Lockfile兼容性
pnpm 12的pnpm-lock.yaml格式与v11完全兼容，不需要重新生成。
# 1. 备份当前lockfile cp pnpm-lock.yaml pnpm-lock.yaml.bak # 2. 升级pnpm corepack prepare pnpm@12 --activate # 或 npm install -g pnpm@12 # 3. 验证lockfile格式未变 head -20 pnpm-lock.yaml # 应仍显示 pnpm.lock: 1.1 版本 # 4. 重新安装 pnpm install
Same Commands策略
pnpm 12强调"Same Commands"：pnpm install、pnpm run build等命令行为与v11一致，不同仅是底层引擎从Node.js换成Rust。
| 命令/配置 | v11行为 | v12变化 |
|---|---|---|
pnpm install --frozen-lockfile | 正常 | 正常 |
pnpm recursive | 正常 | 正常 |
workspace协议 workspace:* | 支持 | 支持，无变化 |
| hook脚本 postinstall/preinstall | 正常 | 正常 |
Content-addressable store .pnpm-store | 正常 | 位置不变 |
已知兼容性问题
问题1：Node原生模块编译失败
现象：node-gyp rebuild在pnpm 12下报错。
原因：Rust二进制与某些native addon的Node API版本不匹配。
解决：更新package.json中的engines.node版本要求。
{
"engines": {
"node": ">=20.0.0"
}
}问题2：CI缓存键需要更新
更新缓存key包含pnpm版本：
- uses: actions/cache@v4
with:
path: ~/.local/share/pnpm/store
key: ${{ runner.os }}-pnpm-${{ hashFiles('pnpm-lock.yaml') }}-${{ github.sha }}
restore-keys: |
${{ runner.os }}-pnpm-问题3：自定义hook脚本路径变化
部分scripts引用了内部路径如.pnpm/node_modules/.bin/xxx，改用pnpm内置命令或直接引用package.json中的bin。
迁移决策流程
当前pnpm版本 < 8.0：先升级到8.x，再升级到12
当前版本 ≥ 8.0：直接升级
备份lockfile和store
测试环境运行
pnpm install运行测试套件
通过则合并到main，失败则排查或回滚
回滚方案
# 1. 恢复lockfile mv pnpm-lock.yaml.bak pnpm-lock.yaml # 2. 切换回pnpm 11 corepack prepare pnpm@11.12.0 --activate # 3. 重新安装 pnpm install
结论
pnpm 12的Rust重写是"换引擎不换方向盘"的升级：lockfile格式不变、命令接口不变、workspace协议不变。性能提升3-4倍对大型monorepo立竿见影。建议在测试环境先行验证hook脚本和native模块兼容性，再推广到生产CI。