npm-shrinkwrap.json 在 VSCode 终端不生效的根本原因是其依赖锁定与 Node/npm 版本强绑定，VSCode 启动时固化 PATH 快照，nvm 切换后未重启终端会导致 npm/node 版本错配，进而引发 ERESOLVE 冲突或原生模块加载失败。
npm-shrinkwrap.json 为什么在 VSCode 终端里不生效
根本原因不是文件写错了，而是 npm-shrinkwrap.json 只在 npm install 时强制锁定依赖版本，但 VSCode 终端默认用的是当前 shell 加载的 node 和 npm 版本 —— 如果这俩和 shrinkwrap 生成时的环境不一致（比如你用 nvm 切到 v16，但 shrinkwrap 是 v14 下生成的），npm 就会拒绝安装或报 ERESOLVE 冲突。
-
npm-shrinkwrap.json本身不校验 Node 版本，但它记录的二进制模块（如node-sass）编译产物与process.versions.napi强绑定 - VSCode 启动时固化了 PATH 快照，
nvm use 16后不重启终端，which npm仍可能指向旧版路径 - 验证方式：在 VSCode 终端执行
npm -v和node -v，再对比cat npm-shrinkwrap.json | head -n 5里的"npm": "6.14.15"字段
vscode 调试器/插件主机无视 shrinkwrap 怎么办
调试器（launch.json 中的 runtimeExecutable）和插件主机（Extension Host）完全不读 npm-shrinkwrap.json。它们只认当前进程加载的 Node.js 运行时 + 全局 node_modules，所以即使 npm install 成功，断点灰掉、Cannot find module './build/Release/binding.node' 仍会发生。
- 插件主机实际运行在 VSCode 内置 Electron 的 Node 上（例如 v22.4.0 / napi=9），和你项目用的 v16 完全无关
-
runtimeExecutable只影响调试进程，不影响npm run dev或插件加载逻辑 - 真正要重编译原生模块（如
fsevents、sqlite3）时，必须指定：npm rebuild --napi-build-version=9 --runtime=electron --target=34.0.0 - 务必先删掉插件目录下的
node_modules/.pnpm和out/，否则旧缓存优先加载，重编译白做
npm ci 报错 ERESOLVE 且 shrinkwrap 不起作用
npm ci 确实会严格按 npm-shrinkwrap.json 安装，但它也会检查 engines 字段兼容性。如果 shrinkwrap 里某个包声明 "engines": {"node": ">=14.0.0"}，而你当前 Node 是 v12，npm ci 就直接失败，不会降级或跳过。
- 常见错误信息：
Unsupported engine for package-name@x.y.z: wanted {"node":"^14.0.0"} (current: {"node":"12.22.0"}) - 临时绕过：加
--ignore-engines，但仅限开发环境，CI 中禁用 - 更稳妥做法：用
nvm use 14切换后再npm ci，而不是强行让旧 Node 去跑新 shrinkwrap - 注意：
npm ci会删掉node_modules并完全重装，别在没提交shrinkwrap前乱跑
多个项目共用一份 shrinkwrap 却要求不同 Node 版本
没有“一份 shrinkwrap 适配多 Node”的方案。shrinkwrap 是快照式锁定，它和生成时的 Node/npm 版本、操作系统、架构强耦合。你不能指望 v16 下生成的 shrinkwrap 在 v18 下无损运行，尤其涉及原生模块时。
- 每个项目应独立维护自己的
npm-shrinkwrap.json，并明确记录生成环境：node -v && npm -v && uname -m - 用
.nvmrc文件配合nvm use自动切换，比手动记版本靠谱得多 - CI 流水线中，先
nvm install $(cat .nvmrc)，再npm ci，避免环境漂移 - 若真要跨版本复用，唯一可行路径是：删掉 shrinkwrap，改用
package-lock.json+resolutions（yarn）或overrides（npm >= 8.3）手动锁子依赖
