!!! abstract 那些曾让我们又爱又恨的 node_modules——前端的包管理工具，从来都不只是技术的选择，更是工程文明的缩影。统一工具，是一支队伍走得更远的第一步。 !!!
原罪
在开始歌颂 pnpm 之前，我们得回头看看，npm 和 yarn（特指 yarn v1）究竟栽在哪些坑里。
它们的问题，其实都源自同一个选择——扁平化的 node_modules。
这听上去像是件好事。扁平，意味着简洁，意味着避免 npm v2 时代那场著名的“依赖地狱”。
但就像城市扩张一样，原本为了方便修的宽阔马路，慢慢演变成了秩序混乱的十字路口。旧的问题解决了，新的问题却接踵而至：
幽灵依赖：潜伏在阴影中的隐患
你安装了一个叫 A 的包，它恰好依赖 B。扁平化结构把 B 顺手放到了根目录，结果呢？你可以直接在代码里引入 B——仿佛它一直就在那。
但你从未在 package.json 里真正邀请过它。
它就像个幽灵，潜入了你的系统，悄无声息地参与运行，却在某天 A 不再依赖它时，突然引发崩塌。而你，甚至不知道它曾存在。
空间的浪费：一场悄然发生的侵占
如果你在本地有十个项目，十个都用到了 lodash，那你硬盘里就真的躺着十份 lodash。
这些重复，是一种静默的浪费。它们不哭不闹，却让你的空间一点点被吞噬。你甚至不知道，哪天因为没空间升级 Xcode 的那一刻，其实是 lodash 惹的祸。
速度的瓶颈：等待成为日常
即使有缓存，npm 和 yarn 仍然会在每次安装时不停地复制、粘贴、移动、检查。
当 node_modules 大到占据 G 级空间时，安装依赖不再是一个动作，而是一种修行。你在键盘前，看着风扇呼啸、硬盘闪烁，像等待一次代码的洗礼。
pnpm：一场革命，从链接开始
pnpm，全称“performant npm”，意思是——高性能的 npm。但我更愿意称它为前端世界的“秩序之书”。
它没有选择继续在废墟上修修补补，而是推倒重来，用两个字，重塑 node_modules 的世界：链接。
幽灵，被关在门外
pnpm 的 node_modules，不再是混乱的广场，而是一个井然有序的图书馆。
每个依赖，都被放在 node_modules/.pnpm/ 里，通过 符号链接（Symbolic Link），精确地指向属于它的上游依赖。
B 只是 A 的朋友，它不会莫名其妙出现在你的项目门口。你想 import B？不行，结构决定了命运。
幽灵依赖，从此消失在结构的铁律里。
磁盘：只存一次的尊严
pnpm 在你电脑深处建了一个看不见的“影子仓库”，地址通常在 ~/.pnpm-store/。
它用一种叫做 硬链接（Hard Link） 的魔法，让全世界（的项目）共用一份真实副本。
就像图书馆里无数学生读着同一本教材的影印本，磁盘不再负重前行，你也不会再为那几个 G 的依赖而删游戏、清缓存。
安装：飞一般的体验
pnpm 几乎不会去“复制”文件，它只是搭起通往依赖的捷径。少了搬运，安装便如风。
尤其是当依赖已经存在于全局仓库中时，那种“秒装”的体验，简直像回到了开发的理想国。
团队协作的选择：不是独裁，是信任
在一个团队中，如果有人用 npm，有人用 yarn，还有人坚持 pnpm，问题会悄然生根：
- 三种 lock 文件互不相认，依赖版本就像三条平行世界的时间线；
- 用 npm 的人写下了幽灵依赖的代码，而用 pnpm 的人一拉下来就直接崩；
- 线上线下不一致的 bug，像是从别人的梦境里跑出来的怪物。
统一包管理工具，不是为了控制，而是为了减少意外。开发的高效、协作的默契、上线的确定性，才是这场选择的真正意义。
pnpm 就像是一位洁癖又守规矩的朋友。他不许你随便乱放东西，却也因此让你安心，知道一切都在预期之中。
结语
前端发展至今，工具的更迭如浪潮。而 pnpm，不再只是工具，而是一种态度：
用更干净、更节省、更可控的方式，去建设我们的工程世界。
别再犹豫于“大家都在用什么”了。用一次 pnpm install，你就会明白，有些东西，一用就回不去了。