关于前端:抖音二面为什么模块循环依赖不会导致死循环CommonJS和ES-Module的解决办法有什么不同

62次阅读

共计 8355 个字符，预计需要花费 21 分钟才能阅读完成。

大家好，我是年年。如果被问到“CommonJS 和 ES Module 的差别”，大略每个前端都都背出几条：一个是导出值的拷贝，一个是导出值的援用；一个是运行时加载，一个是动态编译 …

这篇文章会聚焦于遇到“循环引入”时，两者的解决形式有什么不同，这篇文章会讲清：

  1. CommonJS 和 ES Module 对于循环援用的解决原理是什么？
  2. CommonJS 的 module.exports 和 exports 有什么不同？
  3. 引入模块时的门路解析规定是什么。

JavaScript 的模块化

首先说说为什么会有两种模块化标准。家喻户晓，晚期的 JavaScript 是没有模块的概念，援用第三方包时都是把变量间接绑定在全局环境下。

以 axios 为例，以 script 标签引入时，理论是在 window 对象上绑定了一个 axios 属性。

这种全局引入的形式会导致两个问题，变量净化和依赖凌乱。

  1. 变量净化：所有脚本都在全局上下文中绑定变量，如果呈现重名时，前面的变量就会笼罩后面的
  2. 依赖凌乱：当多个脚本有相互依赖时，彼此之间的关系不明朗

所以须要应用“模块化”来对不同代码进行隔离。其实模块化标准远不止这两种，JavaScript 官网迟迟没有给出解法，所以社区实现了很多不同的模块化标准，依照呈现的工夫前后有 CommonJS、AMD、CMD、UMD。最初才是 JavaScript 官网在 ES6 提出的 ES Module。

听着很多，但其实只用重点理解 CommonJS 和 ES Module，一是面试根本只会问这两个，二是理论应用时用得多的也就是这两个。

CommonJS

CommonJS 的发明者心愿它能让服务端和客户端通用（Common）。但如果始终从事纯前端开发，应该对它不太熟悉，因为它本来是叫 ServerJS，它次要被利用于 Node 服务端。

该标准把每一个文件看作一个模块，首先看它的根本应用：

// index.js 导入
const a = require("./a.js")
console.log('运行入口模块')
console.log(a)

// a.js 导出
exports.a = 'a 模块'
console.log('运行 a 模块');

咱们应用 require 函数作模块的引入，应用 exports 对象来做模块的导出，这里的 require exports 正是 CommmonJS 标准提供给咱们的，应用断点调试，能够看到这几个外围变量：

  1. exports 记录以后模块导出的变量
  2. module 记录以后模块的详细信息
  3. require 进行模块的导入

exports 导出

首先来看 exports 导出，面试常常会问的一个题目是 exports 和 module.exports 区别是什么。
两者指向同一块内存，然而应用并不是齐全等价的。

  1. 当绑定一个属性时，两者雷同

    exports.propA = 'A';
module.exports.propB = 'B';

  2. 不能间接赋值给 exports，也就是不能间接应用 exports={}这种语法

    // 失败
exports = {propA:'A'};
// 胜利
module.exports = {propB:'B'};

    尽管两者指向同一块内存，但最初被导出的是 module.exports，所以不能间接赋值给 exports。

同样的情理，只有最初间接给 module.exports 赋值了，之前绑定的属性都会被笼罩掉。

exports.propA = 'A';
module.exports.propB = 'B';
module.exports = {propC:'C'};

用下面的例子所示，先是绑定了两个属性 propA 和 propB，接着给 module.exports 赋值，最初能胜利导出的只有 propC。

require 导入

CommonJS 的引入特点是值的拷贝，简略来说就是把导出值复制一份，放到一块新的内存中。

循环引入

接下来进入正题，CommonJS 如何解决循环引入。

首先来看一个例子：入口文件援用了 a 模块，a 模块援用了 b 模块，b 模块却又援用了 a 模块。能够思考一下会输入什么.

//index.js
var a = require('./a')
console.log('入口模块援用 a 模块：',a)

// a.js
exports.a = '原始值 - a 模块内变量'
var b = require('./b')
console.log('a 模块援用 b 模块：',b)
exports.a = '批改值 - a 模块内变量'

// b.js
exports.b ='原始值 - b 模块内变量'
var a = require('./a')
console.log('b 模块援用 a 模块',a)
exports.b = '批改值 - b 模块内变量'

输入后果如下：

这种 AB 模块间的相互援用，本应是个死循环，然而理论并没有，因为 CommonJS 做了非凡解决——模块缓存。

仍旧应用断点调试，能够看到变量 require 上有一个属性cache，这就是模块缓存

一行行来看执行过程，

  1. 【入口模块】开始执行，把入口模块退出缓存，
  2. var a = require(‘./a’) 执行 将 a 模块退出缓存，进入 a 模块，
  3. 【a 模块】exports.a = ‘ 原始值 - a 模块内变量 ’ 执行，a 模块的缓存中给变量 a 初始化，为原始值，
  4. 执行 var b = require(‘./b’)，将 b 模块退出缓存，进入 b 模块
  5. 【b 模块】exports.b =’ 原始值 - b 模块内变量 ’，b 模块的缓存中给变量 b 初始化，为原始值，
  6. var a = require(‘./a’)，尝试导入 a 模块，发现已有 a 模块的缓存，所以不会进入执行，而是间接取 a 模块的缓存，此时打印{a: '原始值 - a 模块内变量'},
  7. exports.b = ‘ 批改值 - b 模块内变量 执行，将 b 模块的缓存中变量 b 替换成批改值，
  8. 【a 模块】console.log(‘a 模块援用 b 模块：’,b) 执行，取缓存中的值，打印{b: '批改值 - b 模块内变量'}
  9. exports.a = ‘ 批改值 - a 模块内变量 ’ 执行，将 a 模块缓存中的变量 a 替换成批改值，
  10. 【入口模块】console.log(‘ 入口模块援用 a 模块：’,a) 执行，取缓存中的值，打印{a: '批改值 - a 模块内变量'}

下面就是对循环援用的处理过程，循环援用无非是要解决两个问题，怎么防止死循环以及输入的值是什么。CommonJS 通过模块缓存来解决：每一个模块都先退出缓存再执行，每次遇到 require 都先查看缓存，这样就不会呈现死循环；借助缓存，输入的值也很简略就能找到了。

屡次引入

同样因为缓存，一个模块不会被屡次执行，来看上面这个例子：入口模块援用了 a、b 两个模块，a、b 这两个模块又别离援用了 c 模块，此时并不存在循环援用，然而 c 模块被援用了两次。

//index.js
var a = require('./a')
var b= require('./b')

// a.js
module.exports.a = '原始值 - a 模块内变量'
console.log('a 模块执行')
var c = require('./c')

// b.js
module.exports.b = '原始值 - b 模块内变量'
console.log('b 模块执行')
var c = require('./c')

// c.js
module.exports.c = '原始值 - c 模块内变量'
console.log('c 模块执行')

执行后果如下：

能够看到，c 模块只被执行了一次，当第二次援用 c 模块时，发现曾经有缓存，则间接读取，而不会再去执行一次。

门路解析规定

门路解析规定也是面试常考的一个点，或者说，为什么咱们导入时间接简略写一个 ’react’ 就正确找到包的地位。

仔细观察 module 这个变量，能够看到还有一个属性paths

首先把门路作一个简略分类：内置的外围模块、本地的文件模块和第三方模块。

  1. 对于外围模块，node 将其曾经编译成二进制代码，间接书写标识符 fs、http 就能够
  2. 对于本人写的文件模块，须要用‘./’’../’ 结尾，require 会将这种相对路径转化为实在门路，找到模块
  3. 对于第三方模块，也就是应用 npm 下载的包，就会用到 paths 这个变量，会顺次查找以后门路下的 node_modules 文件夹，如果没有，则在父级目录查找 no_modules，始终到根目录下，找到为止。

在 node_modules 下找到对应包后，会以 package.json 文件下的 main 字段为准，找到包的入口，如果没有 main 字段，则查找 index.js/index.json/index.node

ES Module

只管名为 CommonJS，但并不 Comomn（通用），它的影响范畴还是仅仅在于服务端。前端开发更罕用的是 ES Module。

ES Module 应用 import 命令来做导入，应用 export 来做导出，语法绝对比较复杂，相熟能够先跳过这一部分

  1. 一般导入、导出

    // index.mjs
import {propA, propB,propC, propD} from './a.mjs'

// a.mjs
const propA = 'a';
let propB = () => {console.log('b')};
var propC = 'c';

export {propA, propB, propC};
export const propD = 'd'

    应用 export 导出能够写成一个对象合集，也能够是一个独自的变量，须要和 import 导入的变量名字一一对应

  2. 默认导入、导出

    // 导入函数
import anyName from './a.mjs'
export default function () {console.log(123)
}

// 导入对象
import anyName from './a.mjs'
export default {
  name:'niannian';
  location:'guangdong'
}

// 导入常量
import anyName from './a.mjs'
export default 1

    应用 export default 语法能够实现默认导出，能够是一个函数、一个对象，或者仅一个常量。默认的意思是，应用 import 导入时能够应用任意名称，

  3. 混合导入、导出

    
// index.mjs
import anyName, {propA, propB, propC, propD} from './a.mjs'
console.log(anyName,propA,propB,propC,propD)

// a.mjs
const propA = 'a';
let propB = () => {console.log('b')};
var propC = 'c';
// 一般导出
export {propA, propB, propC};
export const propD = 'd'
// 默认导出
export default function sayHello() {console.log('hello')
}

  4. 全副导入

    // index.mjs
import * as resName from './a.mjs'
console.log(resName)

// a.mjs
const propA = 'a';
let propB = () => {console.log('b')};
var propC = 'c';
// 一般导出
export {propA, propB, propC};
export const propD = 'd'
// 默认导出
export default function sayHello() {console.log('hello')
}

后果如下

  1. 重命名导入

    // index.mjs
import {propA  as renameA,   propB as renameB, propC as renameC , propD as renameD} from './a.mjs'
const propA = 'a';
let propB = () => {console.log('b')};
var propC = 'c';

// a.mjs
export {propA, propB, propC};
export const propD = 'd'

  2. 重定向导出

    export * from './a.mjs' // 第一种
export {propA, propB, propC} from './a.mjs' // 第二种
export {propA as renameA, propB as renameB, propC as renameC} from './a.mjs' // 第三种
    • 第一种形式：重定向导出所有导出属性，然而不包含模块的默认导出。
    • 第二种形式：以雷同的属性名再次导出。
    • 第三种形式：从模块中导入 propA，重命名为 renameA 导出

  3. 只运行模块

    import './a.mjs'

export 导出

ES Module 导出的是一份值的援用，CommonJS 则是一份值的拷贝。也就是说，CommonJS 是把裸露的对象拷贝一份，放在新的一块内存中，每次间接在新的内存中取值，所以对变量批改没有方法同步；而 ES Module 则是指向同一块内存，模块理论导出的是这块内存的地址，每当用到时依据地址找到对应的内存空间，这样就实现了所谓的“动静绑定”。

能够看上面这个例子，应用 ES Module 导出一个变量 1 和一个给变量加 1 的办法

// b.mjs
export let count = 1;
export function add() {count++;}
export function get() {return count;}

// a.mjs
import {count, add, get} from './b.mjs';
console.log(count);    // 1
add();
console.log(count);    // 2
console.log(get());    // 2

能够看到，调用 add 后，导出的数字同步减少了。

但应用 CommonJS 实现这个逻辑：

// a.js
let count = 1;
module.exports = {
  count,
  add() {count++;},
  get() {return count;}
};

// index.js
const {count, add, get} = require('./a.js');
console.log(count);    // 1
add();
console.log(count);    // 1
console.log(get());    // 2

能够看到，在调用 add 对变量 count 减少后，导出 count 没有扭转，因为 CommonJS 基于缓存实现，入口模块中拿到的是放在新内存中的一份拷贝，调用 add 批改的是模块 a 中这块内存，新内存没有被批改到，所以还是原始值，只有将其改写成办法能力获取最新值。

import 导入

ES module 会依据 import 关系构建一棵依赖树，遍历到树的叶子模块后，而后依据依赖关系，反向找到父模块，将 export/import 指向同一地址。

循环引入

和 CommonJS 一样，产生循环援用时并不会导致死循环，但两者的解决形式大有不同。如果浏览了上文，应该还记得 CommonJS 对循环援用的解决基于他的缓存，即：将导出值拷贝一份，放在一块新的内存，用到的时候间接读取这块内存。

但 ES module 导出的是一个索引——内存地址，没有方法这样解决。它依赖的是“模块地图”和“模块记录”，模块地图在上面会解释，而模块记录是好比每个模块的“身份证”，记录着一些要害信息——这个模块导出值的的内存地址，加载状态，在其余模块导入时，会做一个“连贯”——依据模块记录，把导入的变量指向同一块内存，这样就是实现了动静绑定，

来看上面这个例子，和之前的 demo 逻辑一样：入口模块援用 a 模块，a 模块援用 b 模块，b 模块又援用 a 模块，这种 ab 模块互相援用就造成了循环

// index.mjs
import * as a from './a.mjs'
console.log('入口模块援用 a 模块：',a)

// a.mjs
let a = "原始值 - a 模块内变量"
export {a}
import * as b from "./b.mjs"
console.log("a 模块援用 b 模块：", b)
a = "批改值 - a 模块内变量"

// b.mjs
let b = "原始值 - b 模块内变量"
export {b}
import * as a from "./a.mjs"
console.log("b 模块援用 a 模块：", a)
b = "批改值 - b 模块内变量"

运行代码，后果如下。

值得一提的是，import 语句有晋升的成果，理论执行能够看作这样：

// index.mjs
import * as a from './a.mjs'
console.log('入口模块援用 a 模块：',a)

// a.mjs
import * as b from "./b.mjs"
let a = "原始值 - a 模块内变量"
export {a}
console.log("a 模块援用 b 模块：", b)
a = "批改值 - a 模块内变量"

// b.mjs
import * as a from "./a.mjs"
let b = "原始值 - b 模块内变量"
export {b}
console.log("b 模块援用 a 模块：", a)
b = "批改值 - b 模块内变量"

能够看到，在 b 模块中援用 a 模块时，失去的值是 uninitialized，接下来一步步剖析代码的执行。

在代码执行前，首先要进行预处理，这一步会依据 import 和 export 来构建模块地图（Module Map），它相似于一颗树，树中的每一个“节点”就是一个模块记录，这个记录上会标注导出变量的内存地址，将导入的变量和导出的变量连贯，即把他们指向同一块内存地址。不过此时这些内存都是空的，也就是看到的 uninitialized。

接下来就是代码的一行行执行，import 和 export 语句都是只能放在代码的顶层，也就是说不能写在函数或者 if 代码块中。

  1. 【入口模块】首先进入入口模块，在模块地图中把入口模块的模块记录标记为“获取中”（Fetching），示意曾经进入，但没执行结束，
  2. import * as a from ‘./a.mjs’ 执行，进入 a 模块，此时模块地图中 a 的模块记录标记为“获取中”
  3. 【a 模块】import * as b from ‘./b.mjs’ 执行，进入 b 模块，此时模块地图中 b 的模块记录标记为“获取中”，
  4. 【b 模块】import * as a from ‘./a.mjs’ 执行，查看模块地图，模块 a 曾经是 Fetching 态，不再进去，
  5. let b = ‘ 原始值 - b 模块内变量 ’ 模块记录中，存储 b 的内存块初始化，
  6. console.log(‘b 模块援用 a 模块：’, a) 依据模块记录到指向的内存中取值，是{a: <uninitialized>}
  7. b = ‘ 批改值 - b 模块内变量 ’ 模块记录中，存储 b 的内存块值批改
  8. 【a 模块】let a = ‘ 原始值 - a 模块内变量 ’ 模块记录中，存储 a 的内存块初始化，
  9. console.log(‘a 模块援用 b 模块：’, b) 依据模块记录到指向的内存中取值，是{b: ‘ 批改值 - b 模块内变量 ’}
  10. a = ‘ 批改值 - a 模块内变量 ’ 模块记录中，存储 a 的内存块值批改
  11. 【入口模块】console.log(‘ 入口模块援用 a 模块：’,a) 依据模块记录，到指向的内存中取值，是{a: ‘ 批改值 - a 模块内变量 ’}

总结一下：和下面一样，循环援用要解决的无非是两个问题，保障不进入死循环以及输入什么值。ES Module 来解决循环应用一张模块间的依赖地图来解决死循环问题，标记进入过的模块为“获取中”，所以循环援用时不会再次进入；应用模块记录，标注要去哪块内存中取值，将导入导出做连贯，解决了要输入什么值。

结语

回到结尾的三个问题，答案在文中不难找到：

  1. CommonJS 和 ES Module 都对循环引入做了解决，不会进入死循环，但形式不同：

    • CommonJS 借助模块缓存，遇到 require 函数会先查看是否有缓存，曾经有的则不会进入执行，在模块缓存中还记录着导出的变量的拷贝值；
    • ES Module 借助模块地图，曾经进入过的模块标注为获取中，遇到 import 语句会去查看这个地图，曾经标注为获取中的则不会进入，地图中的每一个节点是一个模块记录，下面有导出变量的内存地址，导入时会做一个连贯——即指向同一块内存。
  2. CommonJS 的 export 和 module.export 指向同一块内存，但因为最初导出的是 module.export，所以不能间接给 export 赋值，会导致指向失落。
  3. 查找模块时，外围模块和文件模块的查找都比较简单，对于 react/vue 这种第三方模块，会从当前目录下的 node_module 文件下开始，递归往上查找，找到该包后，依据 package.json 的 main 字段找到入口文件。

福利抽奖工夫（包邮送书！）

《Vue.js 从入门到我的项目实战(升级版)》

参加形式

  1. 增加年年的微信(frontend_nian)，备注“抽奖”，拉你进抽奖群
  2. 开奖日期以及形式：2022 年 07 月 01 日 22:00 群内拼手气红包抽奖，抽取 2 位侥幸观众

如果感觉这篇文章对你有帮忙，给我点个赞和在看吧～这对我很重要

你的反对是我创作的最大能源！❤️

正文完
前端
发表至： 前端
2022-06-19
 0
关于前端:在-Vue-中使用-attrs-构建高级组件
Web安全之CSRF实例解析
关于前端:使用-Flutter-和-Firebase-制作计数器应用程序
关于前端:城市消费券拒绝恶意爬取