npm全局安装vs本地安装：一次安装多次使用为什么不行？
每次新建 Node.js 项目，都得在当前目录重新下载一整份 node_modules，操作体验确实繁琐。尤其当你同时维护多个项目，每个都要重复安装 lodash、express 这类高频依赖，不仅拖慢初始设置，还会无谓消耗大量磁盘空间。你很可能想过：能不能把这些公共包统一存放在一处，让所有项目共享利用？
这个问题直接触及 npm 依赖管理的核心设计。下面拆解背后的取舍逻辑，并提供真正可行的优化方案。
npm 为什么坚持“各自隔离”？
npm 从诞生起就把依赖隔离作为首要原则。全局安装表面省事，实际后患极多。
| 项目本地安装（默认） | 版本独立：A 项目用 lodash 4.x，B 项目用 3.x，互不冲突 | 重复下载、重复写入，磁盘占用成倍增加 |
| 全局安装 | 一次安装，全局可用 | 版本冲突难以管控；项目换环境即崩溃，不可移植 |
权衡之下，npm 优先确保可复现性而非效率或空间占用。对团队协作、CI/CD 场景而言，这种设计无疑是正确的。不过对开发者日常本地开发流程来说，重复安装的体验确实不够友好。
常用提速方案有哪些？
既然 npm 底层逻辑难以撼动，我们只能换个思路。
方案一：改用 pnpm 或 yarn（强烈推荐）
这是目前业界最成熟的解方。两者都采用“全局缓存 + 硬链接”机制：相同版本依赖只需下载一次存入全局 store，之后所有项目通过硬链接引用，既不重复下载，也不重复占用磁盘空间。
| pnpm | 硬链接节省磁盘，安装速度极快 | npm i -g pnpm |
| yarn | 全局缓存，支持离线安装 | npm i -g yarn |
以 pnpm 为例，在项目根目录执行：
# 全局安装 pnpm
npm install -g pnpm
# 之后用 pnpm 替代 npm
cd F:WorkBuddy_work2026-06-07apptainer-video
pnpm install效果立竿见影：首次将 lodash 下载到全局 store 后，后续其他项目再安装同一版本，仅创建一个硬链接——几秒即可完成。
方案二：利用 npm 自带缓存
npm 自身也有缓存机制，可跳过网络下载。但它缓存的是压缩包，安装时仍需解压并复制到项目目录，磁盘空间依旧被重复占用。可作为辅助手段，并非根本解法。
# 查看缓存路径
npm config get cache
# 优先使用缓存
npm install --prefer-offline方案三：全局安装再 link（不推荐）
技术上可行，但实践中几乎无人使用。版本冲突及不可移植问题会使维护成本急剧升高。
已经用 npm 下载好的包，还能再利用吗？
可以确定的是，npm 的 node_modules 结构与 pnpm 的全局 store 格式不兼容，不能直接搬运 node_modules。不过无需焦虑，已有下载并不会白费，下面给出平滑迁移路径。
正确的迁移步骤
# 1. 全局安装 pnpm
npm install -g pnpm
# 2. 进入项目，利用现有 node_modules 生成锁定文件
cd F:WorkBuddy_work2026-06-07apptainer-video
pnpm import
# 3. 删除旧的 node_modules
rm -rf node_modules
# 4. 用 pnpm 重新安装
pnpm install此步骤虽然会再次从远端拉取包，但得益于 npm 本地缓存，速度很快。只需忍受这一轮，之后所有项目都能直接复用全局 store 中的文件。
如果真的一秒都不想等
还有一个小技巧：先用 npm install --prefer-offline 强制 npm 从本地缓存安装，再执行上述 pnpm 迁移流程。不过实际体验与直接联网跑一次 pnpm install 差别不大——大多数包只有几 MB，很快就能拉完。
迁移后的操作注意事项
需要明确：pnpm 和 npm 是两个独立的命令，你调用哪个就执行哪个对应的逻辑。
npm install | 仍走 npm 逻辑，依赖包会复制到项目 node_modules |
pnpm install | 走 pnpm 逻辑，通过硬链接指向全局 store |
因此，养成新的操作习惯即可：所有依赖管理都改用 pnpm 命令。例如：
pnpm init # 代替 npm init
pnpm add react # 代替 npm install react
pnpm install # 代替 npm install简单总结：只痛最后一次，之后所有项目自动复用，安装速度与磁盘占用都能获得质的提升。