npm install卡在extract或fetchmetadata并非因嵌套太深，而是因默认registry.npmjs.org在国内dns解析慢、tls握手失败或cdn回源超时所致，表现为终端停滞在fetchmetadata、extract或某包名不动。
npm install 卡在 extract 或 fetchMetadata 是因为嵌套太深？
不是层级深导致卡住，而是默认 registry registry.npmjs.org 在国内 DNS 解析慢、TLS 握手失败或 CDN 回源超时，表现就是停在 fetchMetadata 或某个包名不动。嵌套结构本身是旧版 npm（
先执行：npm config get registry，如果不是 https://registry.npmmirror.com/（注意末尾斜杠），立刻切掉：npm config set registry https://registry.npmmirror.com/
- 别用
cnpm—— 它生成的package-lock.json与 npm 不兼容，后续npm install会报Invalid package-lock.json - 改完后必须清缓存：
npm cache clean --force - 删掉
node_modules和package-lock.json再重试
pnpm store prune 能解决 rename EBUSY 错误吗？
能，但前提是先关掉所有干扰进程。Windows 下常见 rename 报错，本质是文件被 VSCode、杀毒软件或 Node 进程锁住，不是依赖层级问题。
- 关闭 VSCode
- 任务管理器里杀掉所有
node.exe进程 - 运行：
pnpm store prune清理损坏的全局存储 - 再
pnpm install；如果仍失败，退回npm + 镜像源更稳妥
注意：pnpm 的优势是磁盘节省和符号链接复用，不是“绝对更快”——尤其在首次安装或网络不稳定时，npm + 阿里镜像往往更稳。
为什么 node_modules 里还有多层嵌套？
不是 npm 没扁平化，而是存在版本冲突：比如 A 依赖 lodash@^4.17.0，B 依赖 lodash@^4.20.0，只要语义版本不兼容（如 B 要求 4.20+，A 只认 4.17–4.19），npm 就必须保留两个副本，一个在顶层，一个嵌套在 B 的 node_modules 里。
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
查冲突用：npm ls lodash 或 yarn why lodash，看谁在拉不同版本
- 想强制统一，yarn 可加
"resolutions": {"lodash": "4.20.0"}到package.json - npm 可手动改
package.json中对应依赖的版本范围，再npm install --force重生成 lock 文件 -
npm dedupe只对已安装且兼容的重复依赖有效，不能解决版本不兼容场景
VSCode 里 import 标红但实际能运行？
这是 TypeScript 或 JS 语言服务没识别到刚装的模块，不是路径或语法错误。VSCode 不会自动感知 node_modules 变更，尤其在多项目或 monorepo 场景下。
- 重启 VSCode（不是 Reload Window，要彻底退出再打开）
- 确认
jsconfig.json或tsconfig.json里没误配"typeRoots"或"types"，尤其用了@types/xxx时 - ESM 项目别用
require()加 CommonJS 包，优先写import，或确保package.json有"type": "module"
真正容易被忽略的是：VSCode 启动时可能没继承正确的 PATH，导致它根本找不到你刚装的 node_modules/.bin 下的二进制，连类型检查都启动不了——先在系统终端验证 node -v 和 npm -v，再排查编辑器环境。
