本文共 3002 字，大约阅读时间需要 10 分钟。

pnpm 原理

pnpm 通过符号链接和硬链接技术，在node_modules目录中实现了文件的高效管理。这种方法不仅提升了依赖管理效率，还大幅减少了磁盘占用。接下来，我们将从基础概念入手，逐步解析 pnpm 的工作原理。

概念

要彻底理解 pnpm 是如何工作的，肯定需要一些基本的操作系统知识。尤其是关于文件和链接的概念，在不同的操作系统中都有不同的实现方式。基于此，下面让我们从文件基础开始，逐步了解 pnpm 的核心原理。

文件的本质

在操作系统中，文件并不是直接指向内存地址的物理空间。实际上，文件是一个指针，这个指针指向的是外部存储地址。外部存储可以包括硬盘、U盘甚至是网络存储。这种设计使得文件的存储和管理更加灵活，尤其是在多用户或多租户的环境中。

当你删除一个文件时，实际上只是删除了指针。而指针指向的外部存储内容依然存在，可以通过其他指针继续访问。因此，无论删除多大的文件，速度都非常快。这使得文件的管理更加高效，也为后续的操作提供了更多的可能性。

文件的拷贝

关于文件拷贝，如果你在操作系统中拷贝一个文件，实际上并不是复制整个文件内容。相反，拷贝操作会创建一个新的指针，该指针会指向新的外部存储位置。新的文件既包含原文件的内容，也包含其它元信息。这种设计使得文件的生命周期管理更加灵活，同时也减少了数据的复制开销。

硬链接

我们已经提到了文件的本质，那么硬链接又是如何实现的呢？硬链接的概念源自于 Unix 操作系统。它允许你创建一个新的文件指针，将其直接指向另一个文件的内容。在这种情况下，两个文件（或称为硬链接）实际指向同一个外部存储地址。这样的设计拥有几个优势：

1. 硬链接不会占用额外的磁盘空间，与原文件共享同一内容

2. 硬链接的数量有无上限，可以为同一个文件创建多个硬链接

3. 硬链接的插入不会导致文件内容的复制

在 Windows 系统中，硬链接的支持相对较新。在命令行中，可以使用 `mklink /h` 来创建硬链接。需要注意的是，Windows 系统中文件夹（目录）不能创建硬链接。另外，跨盘符创建硬链接也不建议。

符号链接（符号连接）

符号链接，又称为符号连接，是另一种文件链接方式。与硬链接不同，符号链接只是创建一个新的指针，该指针直接指向目标文件或目录。这样的设计具有以下特点：

1. 符号链接文件非常轻量，文件大小通常只有文件头的大小

2. 符号链接可以引用目录，而硬链接无法做到这一点

3. 符号链接的同步机制较为简单，即使目标文件或目录被删除，符号链接依然可以正常工作，但无法反向

在 Windows 系统中，符号链接的支持同样来自于 Vista 系统及以后的版本。在命令行中，可以使用 `mklink /d` 创建一个目录的符号链接（`/d` 为创建的是目录链接，不写则创建文件链接）。需要注意的是，早期 Windows 系统不支持符号链接，但可以通过 `junction` 工具来实现类似的功能。然而，应该尽量使用现代的符号链接功能而不是老旧的工具。

符号链接和硬链接 的主要区别在于：

1. 硬链接只能链接文件，而符号链接可以链接文件或目录

2. 硬链接在链接后与原文件无关，符号链接始终与目标文件或目录关联

此外，符号链接的更新机制更简单。只要目标文件或目录存在，符号链接就可以正常工作。但硬链接与原文件的更新绑定，一旦原文件被删除或移动，硬链接将失效。

快捷方式是 Windows 系统早期就支持的链接方式。它与符号链接有两个显著不同：

1. 快捷方式不仅仅是一个指针，还包含了一些额外信息，如权限属性、启动方式等

2. 快捷方式占用更多的存储空间，因而在跨平台应用中不常用

在 Node.js 环境下，硬链接和符号链接都受到某些限制：

1. 硬链接：Node.js 对硬链接的处理与实际文件系统的处理方式一致。硬链接是一种实际存在的文件类型，Node.js 无法区分硬链接与普通文件。因此，Node.js 可能无法正确处理硬链接类型的问题。这个问题会在后续讨论中有所体现。

2. 符号链接：Node.js 会将符号链接解读为另一个文件或目录的路径。当你的 JavaScript 文件通过符号链接打开时，内部会以实际路径来处理，而不是通过符号链接本身的指向路径。这意味着如果你的依赖文件位于符号链接目录下，possible 那么你可能需要调整你的依赖路径

理解了文件系统的基础知识和链接类型，我们可以回到 pnpm 的话题。pnpm 的核心原理是利用符号链接和硬链接来优化 node_modules 目录的结构。下面，我会以一个具体的例子来说明 pnpm 的工作方式。

假设项目 `proj` 依赖包 `a`，而 `a` 又依赖包 `b`。在 pnpm 的安装流程中会怎样进行操作？首先，pnpm 会确定需要安装的最终包列表。然后，它会检查这些包是否已经缓存，如果没有缓存的情况下，会下载它们到一个统一的缓存目录中。接下来，在项目根目录中创建 `node_modules` 目录，并对其进行准备工作。

进入下一步，pnpm 会为每个需要安装的包创建适当的文件夹结构。对于直接依赖（直接依赖是指清单中明确指出的依赖），pnpm 会使用符号链接的方式将它们放置到 `node_modules` 目录中。这种做法可以避免将多个依赖重复存储为独立文件，从而提高磁盘使用效率。同时，这种方式还能确保依赖的可访问性较高，因为依赖直接位于项目目录中

如果一个依赖项目 `b` 又依赖别的项目 `c`，而 `a` 又直接依赖 `c`，这种不规范的依赖链条，pnm through 利用了另一种策略。它 将非直接依赖中的所有项目添加到 `.pnpm/node_modules` 目录中，并通过符号链接的方式链接到各自独立的缓存副本中。这样一来，即使你的依赖链条存在间接依赖问题，也可以通过符号链接的方式实现支持。

此外，pnpm 还引入了一个称为 `symbolic links` 的全新概念。它 会将每个包 的直接依赖作为符号链接放在自己对应的子目录中。这样，当你运行 `proj` 时，代码解析器可以直接使用这些符号链接得到的路径。这 种构建方式 旨在提供更高效的依赖加载速度，同时能减少 node_modules 目录的体积浪费。pnpm 的目标是确保你的项目能够从任何地方正常运行，无论是从源代码文件开始还是从缓存副本加以复用

最后，由于 pnpm 对包的全名管理非常严格，它 通过符号链接和缓存机制确保所有工程依赖的版本是一致的。对于那些依赖中存在对绝对路径的依赖的情况，pnm 不会提供支持，因为这与其依赖管理的包容性原则相悖。在这种情况下，使用特定版本的依赖包或通过其它方式指定路径可能会更适合你的项目需求

总体来看，pnpm 的创新性在于其对依赖本质的重新认识和利用。通过符号链接和硬链接，pnpm 不但实现了 node_modules 目录的高效管理，还为跨平台和依赖复用提供了强大的支持能力。其设计理念不仅体现了对操作系统内核机制的深刻理解，也展现了对软件包管理需求的精准把握。这 正是 pnpm 在前后两大版本中依然保持热门的核心原因之一