npm
直接进行依赖modules的嵌套 缺点：层级过深，依赖地狱，复用性不好，不确定性：不同的成员安装依赖可能是不一样的node_module。
升级： 将依赖统一的提升，解决了层级过深。 缺点:还是会有重复的依赖，幽灵依赖，依赖提升不确定性
yarn
yarn-lock文件：每个包的版本，顶层提升依赖的版本，锁定node_modules 解决了不确定性，并行下载加快下载速度。 缺点：不同项目间重复依赖，还是有幽灵依赖。同项目重复安装依赖
pnpm
软链接+硬链接 包被安装到store全局空间：通过.pnpm文件夹下的硬连接来指向存储的包（解决了重复依赖的问题），通过软连接来表示依赖关系，nodulemodules顶层只有显示声明的依赖，通过软连接指向（解决了幽灵依赖）
corepack
Corepack 是 Node.js 官方推出的工具，内置支持：从 Node.js 16.13.0 版本起内置（默认可能未启用，需手动开启），无需额外安装 Corepack 的核心作用之一就是确保同一个项目的所有开发者（以及 CI/CD 等环境）使用完全相同版本的包管理工具（如 npm、yarn 或 pnpm）。 具体来说，当项目的 package.json 中通过 packageManager 字段指定了具体版本（例如 "packageManager": "pnpm@8.6.12"），任何开发者在该项目中运行包管理命令（如 pnpm install）时，Corepack 会自动检测并使用指定版本，无需手动安装或切换版本，从根源上避免因包管理工具版本差异导致的依赖安装、构建等问题。 原理： 提前在系统中安装「垫片脚本」，替代原生包管理器命令的执行入口； 当执行包管理命令时，垫片先读取项目配置（package.json 的 packageManager 字段）； 根据配置自动下载 / 调用指定版本的包管理器，确保执行环境的一致性。
bun & deno
Bun 和 Deno 都是现代 JavaScript/TypeScript 运行时
- yarnV2+都不需要node_modules了
PnP 是依赖管理的一次重要革新，通过 "全局缓存 + 映射表 + 钩子拦截" 的方式，解决了传统 node_modules 的根本性问题（幽灵依赖、冗余、不确定性），同时大幅提升了安装性能。但其缺点主要集中在生态兼容性和开发习惯的适应上。
- 假设你需要调试一个第三方依赖包的 bug，你不想等待作者发布新版本。你会用哪些方法在本地进行调试和验证？（例如 npm/pnpm link,patch-package, overrides/resolutions 等）。
npm link / pnpm link：本地源码联动,先下载包到本地仓库，然后修改。2.patch打补丁npm install patch-package --save-dev 修改modules npx patch-package <包名> 3.直接修改4.overrides墙壁制定依赖版本，覆盖依赖树。
-
npx 是什么？它和直接全局安装（npm i -g）一个包有什么区别？请举出 2-3 个你日常工作中会使用 npx 的场景。 1.创建项目脚手架，执行特定版本工具查看差异
-
当多个依赖包依赖于同一个包的不同版本时，可能会产生依赖冲突。你如何诊断和解决这类问题？npm ls package-name 和 overrides/resolutions 在这里能扮演什么角色？
npm ls <包名>展示该包在整个依赖树中的所有版本及引用路径，帮助定位冲突来源。- 方法 1：升级依赖包到兼容版本 若冲突是因依赖包版本过旧，尝试升级依赖（如 npm update package-b），使其支持高版本的子依赖。 方法 2：使用 overrides（npm）/ resolutions（yarn）强制统一版本
- 请描述一下发布一个 npm 包到公共 registry 的完整流程，包括版本管理、tagging、以及发布前的准备工作。
packge.json中要有特定的字段，比如name（在npm中唯一），version（遵守规则：不兼容API变更，向后兼容，FIX） npm login npm publish