你的 CI 每次都在重复编译同样的原生模块——今天 pnpm 把这件事用跨机器缓存彻底原生化了

每次 CI 跑 PR都要重新编译一遍 native addon，明明其他机器昨天才跑过——这件事 pnpm 用一个配置彻底翻了个遍。

这就是 pnpm 12.4 刚出的 remoteSideEffectsCache：跨机器共享构建产物的缓存方案。配好了，同一个 native 模块在全国各地的 CI runner 里只编译一次，后续 PR 直接从缓存里拿结果。

它怎么工作的

pnpm 的 hard link 机制本来只在本机共享 node_modules，同一个依赖装 N 个项目只占一份磁盘。但构建产物（postinstall/preinstall 跑出来的二进制文件）不存在 store 里，每次 pnpm install 都要重新跑。

remoteSideEffectsCache 把这件事扩展到了机器之间。流程是这样的：CI builder 第一次跑完 native 模块的 build，把产物 hash 后用私钥签名，上传到内部 pnpr 服务器；下一个 runner 遇到同样输入，先拿缓存签名结果，验签通过直接拿二进制，跳过整个 build 过程。

信任模型是这么设计的：机器端只存公钥（~/.config/pnpm/config.yaml），仓库端只声明 org 和 packages 白名单。私钥永远不进仓库，也不进 CI 日志——这是一个有意义的约束隔离。

它省了多少

pnpm 团队测了自己的 monorepo：fetch-and-link 阶段快了至少 2 倍。这个数字来自对 Rust engine 和 TypeScript 版本的内部基准对比，不是宣传稿。

更实在的体感在大 monorepo：native addon（node-sass、sharp、pnpm 自己）占了 postinstall 的大部分时间，TypeScript 编译产物也可以被缓存。如果你的 CI 矩阵是 macOS arm64 + Linux x64 + Windows x64 三套，每套都在重复编译同样的东西——现在不用了。

谁应该开

适合两种场景：

企业 monorepo，PR 频繁。20 个人的团队每天跑 30 次 CI，每次都从零编译 native 模块，这个成本是可量化的。加一台 pnpr 服务器，缓存命中一次赚一次。

开源库，跨平台发布。不同 contributor 的 macOS M 系列和 Intel 各跑各的 build，有了共享缓存，主力维护者的 build 产物可以被其他机器复用。

需要注意的是：目前 pnpr server 和 client 版本必须匹配，安全模型依赖签名信任链，团队内部要有人在维护这台服务器。还没到「开箱即用」的成熟度，但方向是对的。

怎么落地

第一步：在机器端全局配置 ~/.config/pnpm/config.yaml，声明信任的 org 公钥和 builderId。

第二步：在仓库端 pnpm-workspace.yaml 声明哪些包需要缓存读写，设置 org 白名单和 packages 列表。

第一次跑会慢（没有缓存），第二次就快了。如果缓存未命中，检查 architectureBaseline 是否一致——macOS arm64 和 Linux x64 的产物不通用，这是预期行为。

pnpm 12.4 同时带来了 workspace task 调度改进（pnpm -r run 现在按任务依赖图调度，不再等拓扑分组全部跑完），以及 pnpm pipeline 命令把 CI job 的工作方式带进了 CLI。这几个更新放在一起看，指向一个更明确的方向：monorepo 的任务编排和缓存正在成为 pnpm 的内置能力，而不是靠外部脚本拼凑。