1. 这个报错到底在说什么第一次看到[ERR_PNPM_IGNORED_BUILDS] Ignored build scripts: parcel/watcher2.5.6, canvas2.11.2这行红字很多人第一反应是“我是不是装崩了”然后开始疯狂重装、删node_modules、删 lock 文件折腾半天发现报错还在。其实这个提示本身不是安装失败而是 pnpm 在告诉你有两个依赖包带了postinstall之类的构建脚本出于安全策略我没有自动执行它们。先把结论摆出来你的依赖已经装上了只是这两个包的构建脚本被 pnpm 主动跳过了。pnpm 从 v10 开始默认禁止依赖包在安装时自动运行构建脚本原因是供应链安全——防止某个包在postinstall里偷偷干坏事。这个策略本身是好事但代价就是像parcel/watcher、canvas这种需要编译原生模块native addon的包脚本不跑就缺东西运行时才报错。所以这条报错要分两层看。第一层是“提示”pnpm 告诉你哪些包的脚本被忽略了第二层是“后果”如果这些包确实需要构建产物那你在实际使用时会遇到Cannot find module、bindings加载失败、canvas引入即崩之类的问题。搞清这两层解决思路就清晰了要么让 pnpm 放行这些包的构建脚本要么确认你根本用不到它们的原生能力。parcel/watcher是 Parcel 打包器用的文件监听库很多构建工具Vite 某些插件、Parcel 本身、部分 monorepo 工具链会间接依赖它它需要编译原生模块来提升文件监听性能。canvas则是 Node.js 环境下的 Canvas 绘图库底层依赖 Cairo、Pango 等系统库安装时要编译 C 扩展。这两个都是典型的“必须跑构建脚本”的包被忽略后大概率会出问题。提示不要看到红字就慌先判断这个包在你的项目里是不是真的被用到。有些是传递依赖实际运行路径根本走不到那忽略就忽略了不影响。2. 为什么 pnpm 要默认忽略构建脚本要理解这个报错得先理解 pnpm 的设计哲学。npm 和 yarn 在安装依赖时默认会执行每个包的preinstall、install、postinstall脚本。这个机制方便了原生模块编译但也打开了一个巨大的攻击面任何一个你间接依赖的包都能在安装时执行任意代码读取你的环境变量、上传文件、植入后门。历史上出过不少这样的供应链投毒事件。pnpm 从 v10 起把默认策略改成了“白名单制”只有你明确允许的包才会执行构建脚本。这个开关就是package.json里的pnpm.onlyBuiltDependencies字段或者.npmrc里的相关配置。被拒绝的包会被记录到pnpm.ignoredBuiltDependencies或者直接在安装日志里以ERR_PNPM_IGNORED_BUILDS的形式提示你。这个设计带来的直接好处是你的安装过程更可控不会莫名其妙跑一堆脚本。代价就是原生模块类依赖需要你手动放行。pnpm 官方文档里也说了这个报错是“warning 级别”的提醒不是致命错误它希望你主动做决策而不是无脑放行所有脚本。从工程角度看这个策略其实逼着团队去审视依赖树到底哪些包需要构建为什么需要能不能换成纯 JS 实现这种“被迫的清醒”长期看是好事。但短期内尤其是从 npm/yarn 迁移过来的项目就会遇到这个报错需要一次性把该放行的包配好。我自己的经验是一个中等规模的前端项目需要放行构建脚本的包通常不超过五个parcel/watcher、canvas、esbuild、sharp、better-sqlite3这几个是高频出现的。配一次之后基本不用再管。3. 三种解决办法按场景选解决这个报错有三条路没有绝对优劣取决于你的项目场景和团队规范。我按推荐程度从高到低说。3.1 方案一在 package.json 里精确放行这是最推荐的做法因为它把“允许哪些包跑脚本”这个决策固化到了代码仓库里团队成员和 CI 环境行为一致。具体操作是在package.json根级加一个pnpm字段{ pnpm: { onlyBuiltDependencies: [ parcel/watcher, canvas ] } }加完之后重新执行pnpm installpnpm 就会为这两个包执行构建脚本。注意这里写的是包名不带版本号pnpm 会匹配该包的所有版本。如果你只想放行特定版本可以写canvas2.11.2这种形式但一般没必要包名粒度就够了。这个方案的优点是精确、可审计、可提交到 git。缺点是每次遇到新的原生依赖都要手动加。不过这正是它的价值所在——你被迫知道自己在放行什么。3.2 方案二用 pnpm approve-builds 交互式放行pnpm 提供了一个交互命令适合临时处理或者不确定该放行哪些包的时候用pnpm approve-builds执行后它会列出所有被忽略的构建脚本你用空格键勾选要放行的包回车确认。pnpm 会自动把选中的包写进package.json的onlyBuiltDependencies里。这个命令本质上是方案一的快捷方式适合懒人或者快速排查。我实测下来这个命令在 pnpm 10.x 上表现稳定但要注意它修改的是当前项目的package.json在 monorepo 里要确认改的是根目录还是子包。另外如果 CI 环境是只读的这个命令会失败还是得用方案一手动配。3.3 方案三全局关闭脚本忽略不推荐有些人图省事直接在.npmrc里加ignore-scriptsfalse或者用pnpm config set ignore-scripts false。这确实能让所有构建脚本都跑起来报错也消失了。但我不推荐这么做原因很简单你把 pnpm 辛苦建立的安全防线又拆了。任何一个依赖都能在安装时执行任意代码供应链风险直接拉满。如果非要用这个方案至少限定在本地开发环境CI 和产线环境保持默认的忽略策略。但更好的做法还是老老实实用方案一把该放行的包列清楚。方案操作位置安全性可复现性推荐度精确放行package.json高高强烈推荐approve-builds命令行交互高中临时可用全局关闭.npmrc低高不推荐4. 放行之后 canvas 还是装不上怎么办很多人按上面的方法放行了canvas结果pnpm install还是报错错误信息从ERR_PNPM_IGNORED_BUILDS变成了node-gyp编译失败。这是因为canvas不是纯 JS 包它依赖系统级的 C 库Cairo、Pango、libjpeg、libpng 等等。放行构建脚本只是让编译流程启动能不能编译成功还得看系统环境。在 macOS 上通常需要先装这些依赖brew install pkg-config cairo pango libpng jpeg giflib librsvg pixman在 Ubuntu/Debian 上sudo apt-get install build-essential libcairo2-dev libpango1.0-dev libjpeg-dev libgif-dev librsvg2-dev在 CentOS/RHEL 上则是yum install对应的-devel包。Windows 上最麻烦官方推荐用windows-build-tools或者手动装 Visual Studio Build Tools 加 GTK 相关库很多人干脆放弃在 Windows 上编译canvas改用预编译版本或者换napi-rs/canvas。这里有个经验canvas2.x 版本对 Node 版本和系统库版本都比较敏感Node 18 以上建议用canvas2.11.2或更高。如果编译一直失败可以考虑用canvas的预编译二进制通过设置环境变量CANVAS_BINARY_HOST_MIRROR指向可用的镜像源或者直接换用napi-rs/canvas它是 Rust 实现的预编译包覆盖全平台安装体验好很多。注意如果你只是用canvas做简单的图片合成且运行在 Serverless 或容器环境优先考虑napi-rs/canvas能省掉大量系统依赖的麻烦。5. parcel/watcher 的坑和替代思路parcel/watcher相对canvas温和一些它编译失败通常是因为缺少 C 编译工具链node-gyp依赖 Python 和 make/gcc。在大多数开发机上只要装了 Xcode Command Line ToolsmacOS或build-essentialLinux放行后就能顺利编译。但parcel/watcher有个特点它提供了预编译的二进制包按平台分发比如parcel/watcher-darwin-arm64、parcel/watcher-linux-x64-glibc等。pnpm 在安装时会尝试拉取对应平台的预编译包如果拉到了其实不需要本地编译。报ERR_PNPM_IGNORED_BUILDS有时候是因为 pnpm 的 optional dependencies 处理逻辑和预编译包的分发机制有交互导致它认为需要跑构建脚本。遇到这种情况可以先确认node_modules/parcel/watcher目录下有没有对应平台的.node文件。如果有说明预编译包已经就位构建脚本忽略也不影响运行你可以直接忽略这个报错。如果没有再按前面的方法放行构建。另外如果你的项目其实不直接依赖parcel/watcher而是某个工具链的传递依赖可以考虑用 pnpm 的overrides字段把它替换掉或者确认那个工具链是否支持关闭文件监听的原生实现。比如某些构建工具提供--no-native-watch之类的选项用纯 JS 的轮询模式替代虽然性能差一点但省去了编译麻烦。6. 从 npm/yarn 迁移到 pnpm 的完整避坑清单这个报错在迁移场景下特别高频因为 npm/yarn 默认跑所有脚本迁移到 pnpm 后突然一堆包被忽略。我把迁移时容易踩的坑整理成一张表按优先级排列。问题现象根因解决动作ERR_PNPM_IGNORED_BUILDSpnpm 10 默认忽略构建脚本配 onlyBuiltDependenciesnode-gyp 编译失败缺系统编译工具链装 build-essential/Xcode CLTcanvas 引入报错原生模块未编译装 Cairo/Pango 等系统库pnpm 命令找不到PATH 未配置检查 pnpm 安装位置并加 PATHlock 文件冲突npm/yarn lock 与 pnpm-lock 并存删旧 lock重新 pnpm installworkspace 配置报错pnpm-workspace.yaml 缺失或格式错补 packages 字段离线安装失败store 未预热pnpm fetch 后 pnpm install --offline迁移时我建议的顺序是先删掉package-lock.json或yarn.lock保留package.json然后pnpm import把旧 lock 转成pnpm-lock.yaml如果旧 lock 还在接着配好onlyBuiltDependencies最后pnpm install。这样一次性把构建脚本策略定下来避免反复。还有一个容易被忽略的点pnpm 的node_modules结构是符号链接加硬链接的 store 机制和 npm 的扁平化结构不同。有些包在代码里硬编码了node_modules/xxx的路径假设迁移后会找不到。这种情况用node-linkerhoisted配置可以让 pnpm 生成类似 npm 的扁平结构兼容性更好但会牺牲一部分 pnpm 的空间优势。是否开启取决于你的依赖树里有没有这种“路径敏感”的包。7. 内网和离线环境的特殊处理热词里出现了“pnpm 项目迁移到内网”“pnpm 离线”这确实是企业环境的高频需求。内网环境没有外网访问canvas这种需要下载源码编译的包会很麻烦因为node-gyp编译时可能还要下载 Node headers。内网部署的核心思路是“预热 离线安装”。具体步骤在有网环境用pnpm fetch把所有依赖下载到 store包括构建脚本需要的源码包。把整个 store 目录和pnpm-lock.yaml一起拷贝到内网。内网机器上配置store-dir指向拷贝过来的 store执行pnpm install --offline。但canvas的编译还需要系统库和 Node headers这些不在 pnpm store 里。所以内网环境更稳妥的做法是在有网环境把canvas编译好把生成的.node文件连同node_modules/canvas整个目录打包内网直接解压使用。或者干脆用napi-rs/canvas它的预编译二进制是 npm 包的一部分pnpm fetch能直接拉到内网安装无需编译。对于parcel/watcher同样优先依赖预编译包。pnpm 的supportedArchitectures配置可以指定要拉取哪些平台的预编译包内网机器架构固定的话提前配好能避免拉错包。提示内网环境务必把onlyBuiltDependencies配好并提交到仓库否则每个开发者本地都要手动 approve 一次效率极低且容易漏。8. 几个我踩过的真实坑说几个文档里不会写、但实际会遇到的坑。第一个坑onlyBuiltDependencies配了但没生效。原因通常是配错了位置——它必须在根package.json的pnpm字段下不能放在子包里也不能放在pnpm-workspace.yaml里至少 pnpm 10.x 还不支持在 workspace 文件里配这个。我见过有人在 monorepo 的子包package.json里配结果根安装时完全不认。第二个坑放行了canvas但 CI 上还是失败。原因是 CI 的 Docker 镜像里没有 Cairo 等系统库本地能编译不代表 CI 能。解决办法是在 Dockerfile 里加系统依赖安装步骤或者用多阶段构建在构建阶段装好编译环境运行阶段只拷贝产物。第三个坑pnpm approve-builds在 CI 里卡住。这个命令是交互式的CI 环境没有 TTY执行会挂起或报错。CI 里必须用package.json静态配置不能依赖交互命令。第四个坑删了node_modules重装后报错消失但过几天又出现。这通常是因为某个依赖升级后引入了新的原生模块而onlyBuiltDependencies没更新。建议把 pnpm 版本锁定在package.json的packageManager字段里避免不同机器用不同 pnpm 版本导致策略差异。第五个坑ERR_PNPM_IGNORED_BUILDS和ERR_PNPM_INVALID_WORKSPACE_CONFIGURATION同时出现。后者通常是pnpm-workspace.yaml里packages字段缺失或格式错误先解决 workspace 配置再看构建脚本的问题否则会互相干扰排查。9. 怎么判断一个包到底需不需要放行最后分享一个判断方法避免无脑放行所有包。拿到一个被忽略的包先问三个问题第一它是不是原生模块看包目录下有没有binding.gyp、prebuilds、*.node文件或者package.json里有没有gypfile: true、install/postinstall脚本。有这些特征的基本都需要构建。第二你的运行路径会不会走到它用pnpm why 包名看它是谁的依赖再判断那条依赖链在你的项目里是否被实际使用。比如你根本不用 Parcel那parcel/watcher可能只是某个工具的 optional 依赖忽略无妨。第三有没有纯 JS 或预编译的替代canvas可以换napi-rs/canvasparcel/watcher可以换chokidar纯 JS性能略低但零编译sharp有预编译包。能换就换从根上消除构建脚本需求。这三个问题问完大部分包该不该放行就清楚了。我的原则是能不放行就不放行能换预编译就换预编译实在不行才精确放行。这样既解决了报错又不牺牲 pnpm 的安全策略。我个人在实际操作中的体会是这个报错看着吓人其实是个“提醒你审视依赖”的契机。把它当成一次依赖树体检顺手把不必要的原生依赖清理掉项目反而更健康。