硬链接 & 软链接（符号链接）& 包管理工具

最新推荐文章于 2025-12-05 14:31:02 发布

原创最新推荐文章于 2025-12-05 14:31:02 发布 · 646 阅读

CC 4.0 BY-SA版权

文章标签：

硬链接通过索引节点指向的是同一块地址，软链接只是引用了路径

本质不同：
- 硬链接是同一文件的多个入口（共享数据，无 “指向” 关系）；
- 符号链接是指向文件的 “路标”（独立文件，仅存路径）。
删除影响不同：
- 删除一个硬链接，其他硬链接和原文件不受影响（只要还有一个 “入口” 存在，数据就不消失）；
- 删除符号链接指向的目标文件，符号链接会变成 “无效路标”。
限制不同：
- 硬链接不能跨分区 / 文件系统创建，也不能链接目录（只能链接文件）；
- 符号链接无此限制。

硬链接：同一间房子的多把钥匙。钥匙 A、钥匙 B、钥匙 C 都能开门，丢了钥匙 A，钥匙 B 和 C 还能用；只有所有钥匙都丢了，房子才彻底 “无法进入”（数据被删除）。
软链接：一张写着 “房子地址” 的纸条。纸条本身丢了不影响房子；但如果房子拆了（原文件删了），纸条留着也没用了。

我开始误以为硬链接就是会创建很多重复的相同文件。并非如此！

可以从 “访问方式是否依赖路径” 和 “是否直接关联数据” 这两个核心点来区分软链接 & 硬链接

你在 /home/user/ 目录下给它创建一个硬链接 link_hard.txt：

ln /home/user/docs/data.txt /home/user/link_hard.txt

此时：

link_hard.txt 和 data.txt 共享同一个 inode（直接关联磁盘数据），它们的关系是 “同一个数据的两个名字”。
哪怕你把 data.txt 移动到同一分区的其他地方（比如 /home/user/desktop/data.txt），link_hard.txt 依然能正常打开文件内容 —— 因为它不依赖原路径，直接关联的是数据本身。
你修改 link_hard.txt，data.txt 的内容会同步变化（因为改的是同一份数据）。

你在 /home/user/ 目录下给它创建一个软链接 link_soft.txt：

ln -s /home/user/docs/data.txt /home/user/link_soft.txt

此时：

link_soft.txt 里只存了一行文字：/home/user/docs/data.txt（它依赖这个路径）。
如果你把 data.txt 移动到 /home/user/desktop/data.txt，再点击 link_soft.txt 就会报错 “找不到文件”—— 因为它记录的还是旧路径，路径变了，软链接就失效了。
你修改 link_soft.txt，实际改的是 /home/user/docs/data.txt 的内容（通过路径找到目标后再修改）。

npm,yarn :软链接。

pnpm :软硬链接。

工具 / 特性	存储方式	链接类型	幽灵依赖	空间效率
npm（v3+）	复制文件	仅`link`时用软链接	存在	低（重复复制）
Yarn Classic（v1）	复制文件	仅`link`时用软链接	存在	低（重复复制）
Yarn 2+（PnP）	虚拟映射（无复制）	不依赖传统链接	几乎无	高
pnpm	全局存储 + 硬链接 + 软链接	硬链接（全局→项目）+ 软链接（入口→实际文件）	无	极高（无重复）

简单说：npm 和 Yarn Classic 因 “复制 + 扁平化” 导致幽灵依赖和空间浪费；pnpm 通过 “硬链接复用 + 软链接隔离” 解决了这两个问题，这也是 pnpm 近年来受欢迎的核心原因。

常规安装（npm install）：
npm 会将依赖包的所有文件完整复制到项目的node_modules目录中，不使用硬链接或软链接。
同时，npm 采用 “依赖扁平化” 策略：如果多个依赖共同依赖某个包（比如 A 和 B 都依赖 C），会将 C “提升” 到node_modules顶层（而非嵌套在 A 和 B 的子目录中），避免重复安装。
软链接的使用：
只有在开发调试场景（npm link）时，才会创建软链接：将本地开发的包链接到项目的node_modules中，方便实时调试，此时用的是软链接（符号链接）。
幽灵依赖问题：
正因为 “依赖扁平化”，项目中未在package.json中声明的依赖（比如 A 依赖的 C 被提升到顶层），也能被项目代码直接引用（如require('C')），这就是 “幽灵依赖”。这种依赖不受版本锁定保护，可能因依赖更新导致意外问题。

Yarn 的机制随版本变化明显，需区分：

Yarn Classic（v1）：
与 npm 的核心机制几乎一致：
- 常规安装时复制文件到node_modules，无硬链接；
- 同样采用 “依赖扁平化”，存在幽灵依赖；
- yarn link时使用软链接，与npm link逻辑相同。
Yarn 2+（Berry，新版）：
引入了 “Plug'n'Play（PnP）” 模式（默认不生成node_modules）：
- 不复制依赖文件，而是通过虚拟文件系统映射和缓存路径直接关联依赖，完全不依赖传统的硬链接 / 软链接；
- 若手动开启node_modules模式，会采用更严格的结构，避免依赖提升，减少幽灵依赖。

pnpm 的设计完全不同于 npm 和 Yarn Classic，核心是 “全局存储 + 链接复用”：

硬链接的作用：
pnpm 会将所有下载过的依赖包存储在全局仓库（默认~/.pnpm-store）中，每个包的文件在全局仓库中只存一份。安装时，通过硬链接将全局仓库中的文件 “链接” 到项目的.pnpm子目录（而非直接复制）—— 硬链接确保项目中访问的是全局存储中的原始数据，且不占用额外空间。
软链接的作用：
项目的node_modules中，依赖包的入口（如node_modules/react）是软链接，指向.pnpm目录中通过硬链接关联的实际包文件。这种设计形成了 “非扁平化” 的node_modules结构：每个依赖只能访问自己声明的子依赖，避免了依赖提升。
无幽灵依赖：
由于不做依赖扁平化，且通过软链接严格隔离依赖范围，项目中只能引用package.json中声明的依赖，彻底解决了幽灵依赖问题。