共计 3320 个字符，预计需要花费 9 分钟才能阅读完成。
前言
在 Linux 或 MacOS 零碎中，ln命令是一个重要的命令，它的性能是为某一个文件在另外一个地位建设一个同步的链接。
对于前端来说，ln 命令被利用最多的中央就是, 就是全局装置并创立一个 npm 命令
npm i -g xxx(nrm)当敲下回车，下面的装置执行实现后，在输入中，会看到这样一串字符：
/usr/local/bin/nrm -> /usr/local/lib/node_modules/nrm/cli.js这串字符背地的意思就是零碎建设了node_modules/nrm/cli.js 的软链接/bin/nrm
其实 bin 文件夹中的可执行命令，根本都是以软链接的模式存在。
更多对于 ln 的应用，可参考菜鸟教程
上面会围绕门路 A 和 B 这两个实例来讲软硬链接和文件拷贝的区别：
门路 A: /user/wam/A/request.js
门路 B: /user/wam/B/request.js
request.js 内容
import utils from './utils';
console.log('res:', utils.res());目录与文件
在开始前，简略回顾一下大学没学过，可能在那里看到过的文件系统，这里围绕简略易了解的 Linux 为例。
大部分的 Linux 文件系统（如 ext2、ext3）规定，一个文件由目录、节点 (inode) 和数据块 (block) 组成
- 目录项：包含文件名和 inode 节点号。
- inode：又称文件索引节点，蕴含文件的根底信息以及数据块的地位。
- block：蕴含文件的具体内容。
当咱们轻易关上咱们某个开发我的项目，命令行输出 ls -li, 就可看到目录与inode 的对应信息，下图第一行就是目录对应的 inode。
因为一个文件块 (block) 的大小无限(通常为 4kb)，所有经常一个文件须要存储在多个文件块中，这样 inode 就须要存储多个 block 的地位信息（如最上图所示）, 而一个 inode 自身只有 128 Btyes 的存储空间，所以存储文件 block 地位也是间接通过 block 来做的, 所以 block 能够了解为分两种: 文件内容 block 与 inode 信息 block，搞懂这些就能够往下了。
参考资料
- 鸟哥 Linux: 磁盘分区
- 鸟哥 Linux: 文件系统
- 备份
软链接
软链接(soft link) 又被称为符号链接，相当于 Window 零碎中的快捷方式。
eg: 建设 A 为 B 的软链接
ln -s /user/wam/B/request.js /user/wam/A/request.js
建设软链接 其实质 就是某为门路的建设一个超链接（在这体现为 A 为 B 的超链接），其不具备文件实体。当咱们尝试关上 A 门路所在的文件，其最终在编辑器关上的是门路 B 的文件，所以其文件内的相对路径援用文件也是相对路径 B 来计算的，即 utils 文件门路为：
/user/wam/B/utils.js当删除 B 文件，再去拜访 A, 会发现索引不存在，无法访问。
硬链接
硬链接(hard link), 是为源文件建设另一个索引。
eg: 建设 A 为 B 的硬链接
// 少一个 -s 选项
ln /user/wam/B/request.js /user/wam/A/request.js
建设硬链接 其实质就是 为文件实体创立另一个可拜访的门路索引 。所以当咱们尝试关上 A 门路所在的文件，与软链接区别的是：其最终在编辑器关上的是门路 A 本人，所以其文件内的 相对路径援用文件 也是绝对 门路 A 来计算的, 即 utils 文件门路为：
/user/wam/A/utils.js但值得一提的是，因为 A 与 B 门路都指向同一个源文件，所以在 A 门路对文件内容所做的编辑都会反映在 B 门路文件，即两边文件的变动是互相同步影响的。
当删除门路 B 时，源文件不会被垃圾回收，因为门路 A 仍放弃对源文件的索引。
硬链接和软链接还有一个区别是：因为零碎的限度，硬链接要求门路是在文件维度，而软链接既能够是文件，也能够是文件夹。
文件拷贝
这个应该用过电脑的人都懂。
eg: 拷贝文件 B 到门路 A
// 少一个 -s 选项
cp -f /user/wam/B/request.js /user/wam/A/request.js
文件拷贝，是日常咱们最常见的操作，只是更常见的模式是用 ctrl + c/v，而非cp 命令（实际上 cp 也能实现ln 链接的操作）, 其实质就是 拷贝一份文件实体并创立一个可拜访的门路索引。所以当咱们尝试关上 A 门路所在的文件，其指向的实体是不同于 B 的(克隆体)，所以其文件内的相对路径援用文件也是相对路径 A 来计算的即 utils 文件门路为，与建设硬链接统一：
/user/wam/A/utils.js因为 A 门路 与 B 门路 都别离指向本人的实体，所以 A / B 各自是独立的，当删除 B 时，B 对应的源文件会被回收，A 不受任何影响。
神侃 JS 对象与硬软链接
作为前端咱们都晓得，JS 对象 (object) 是援用类型。
援用类型的值是保留在内存中的对象。JS 不容许间接拜访内存中的地位，即不能间接操作对象的内存空间。在操作对象时，实际上是在操作对象的援用而不是理论的对象。为此，援用类型的值是按援用拜访的。（摘抄自红宝书 P87）
你品，你细品。是不是感觉 援用类型 和咱们下面讲到文件链接与源文件很像。
以：
const B = {a: 1};
所以当执行上面这种操作：
const C = B;
C.a = 2;
console.log('B.a:', B.a); // 2
B.a = 3；console.log('C.a:', C.a); // 3从下面的执行输入，咱们能够很容易看出，原来 JS 中的援用类型变量赋值和 硬链接 是一回事。
接着咱们引入一个 lodash 的深拷贝 (cloneDeep) 函数：
import {cloneDeep} from 'lodash'；const C = cloneDeep(B);
C.a = 2;
console.log('B.a:', B.a); // B.a: 1
B.a = 3；console.log('C.a:', C.a); // C.a: 2从下面的执行输入，咱们能够很容易看出，原来 JS 中的深拷贝和 文件拷贝 是一回事。
哪 软链接 怎么用 JS 来形容呢？Proxy?
Proxy 中文译作 代理 ，在体现上其实是与硬链接统一的，而硬链接与软链接从体现上最大的区别就是：B(母体) 被删除后，A(超链接) 就不可拜访了，所以这并不是正确的答案。
而正确答案是：WeakRef，弱援用. 当下处于 proposal 阶段，不过在 Chrome 与 Firefox 最新的版本都对其做了实现;
看个 demo：
let B = {a: 1};
const C = new WeakRef(B);
const registry = new FinalizationRegistry(heldValue => {console.log('GC worked:', heldValue); // GC worked: B
// 当 B 所指向的值被垃圾回收后，这个回调将被执行
console.log('C.a：', C.deref()?.a); //C.a：undefined
});
// 注册 B 所指向的值被垃圾回收的监听
registry.register(B, "B");
console.log('C.a:', C.deref().a); // C.a: 1
C.deref().a = 2; // 通过索引扭转值
console.log('B.a:', B.a); // B.a: 2
B.a = 3;
console.log('C.a:', C.deref().a); // C.a: 3
// 切断对值得索引, 察看下面的 GC 回调
B = null;
// console.log('after C.a:', C.deref()?.a);貌似下面的 JS 代码能勉强论述软链接的原理，但离现实的确还有间隔，这个神侃更多的是想让大家对 ES 新提案中的 WeakRef 与 FinalizationRegistry 有一个理性的意识。
更多对于 WeakRef 请浏览
- https://v8.dev/features/weak-references
- tc39/proposal-weakrefs
- WeakRef
- FinalizationRegistry
结语
通过本文，你是不是发现，这世间万事万物是不是特地微妙。尽管是神侃，读到这里，心愿你能有一丝丝播种。
原文见: https://github.com/closertb/c…
