模块化其实很早就在很多高级语言中如Java、Ruby、Python出现了，甚至在C语言都有类似的模块化，比如include语句引入头文件，各种库等等。而在前端中，JavaScript作为主要语言，它设计之初并没有实现模块化。随着Web的发展，JavaScript地位越来越高，同时也出现了以下主要问题：

这可谓是一大痛点呐！但是广大的软件工程师们也不是吃素的，于是解决方案如AMD、CMD、ES Module、CommonJS便雨后春笋般涌现出来了。

现如今AMD、CMD已经慢慢淡出我们的视野了，我们接触最多就是两种模块规范：ES Module和CommonJS，前者应用在ECMAScript中而后者在Node中。

CommonJS规范是一个超级大的概念，和ECMAScript规范一样，它是整个语言层面的规范，模块化只是偌大的规范中的一种，我相信很多人容易搞混淆，在此还是说明一下。

如果还是不理解，我举个例子吧：在CommonJS规范中实现了以下规范：

我相信你应该可以理解了，下面我会介绍一下我所学习的CommonJS模块规范。

主要分为三部分：模块引用、模块定义、模块表示。

Node模块类型分为两种：核心模块和文件模块，并通过require方法来引入模块。前者是Node中内置的模块，而后者一般是用户自己定义的模块。后面提到的自定义模块也属于文件模块，只是为了区分说明。

代码如下：

require命令的基本功能是，读入并执行一个JavaScript文件，然后返回该模块的exports对象。如果没有发现指定模块，会报错。

在CommonJS模块规范中，一个文件就是一个模块，并通过module.exports和exports两种方式来导出模块中的变量或函数。

代码如下：

为了方便，Node为每个模块提供一个exports变量，指向module.exports。等价于：

如果exports导出的变量类型是引用类型如函数，则会断开与module.exports的地址指向，导致变量导出失败。因为最终还是要靠module.exports来导出变量的。

用图来表示大概就是这个样子：

同理，如果你要使用module.exports直接导出一个对象或者函数也会重新指向新地址，而你还使用exports导出原来地址中的变量或函数是没有用的。

模块标识是require方法中的参数，该参数就是引入的模块文件的路径，可以没有后缀，但是必须符合小驼峰命名规范。

在上面的模块引用中，http、./sum、koa就是模块标识。具体有以下几类：

从Node中引入模块，主要经历了四个过程：

下面来具体看看它们的过程。

不管是内置模块还是文件模块，在第一次加载模块后，会把模块编译执行并放在缓存中。从而以后再次加载模块的时候，会直接去缓存中找相应的模块。

内置模块跟文件模块不同的是，它在Node源代码编译过程中直接编译成了二进制可执行文件，在启动Node进程的同时就从内存中加载了核心模块，并缓存起来。所以内置模块的加载跳过了文件定位和编译执行的步骤，并且优先于文件模块加载。

缓存一般放在了require.cache，如果想删除模块的缓存，可以像下面这样写。

注意，缓存是根据绝对路径识别模块的，如果同样的模块名，但是保存在不同的路径，require命令还是会重新加载该模块。

路径分析主要是对模块标识符分析，根据不同类型的模块标识符使用不同规则分析路径。

下面是模块加载速度比较：

核心模块 > 文件模块 > 自定义模块。

核心模块在Node启动的时候就已经编译成了二进制文件了，所以加载速度最快。 文件模块因为带有.、..、/路径标识，具体标识了文件的位置，所以模块加载速度仅次于核心模块。自定义模块是三者最慢的了，具体原因我们在下面会有说明。

值得注意的是，如果自定义模块和核心模块重名了，则不会加载自定义模块，因为核心模块优先于自定义模块。

Node是如何去寻找文件模块和自定义模块路径并加载的呢？下面我要先介绍一个很特殊的对象module。

Node内部提供一个Module构建函数。所有模块都是Module的实例。每个模块内部，都有一个module对象，代表当前模块。

Module

为了测试，我建立了一个项目结构：

main.js

我们在main.js中打印module，它存放了当前main.js模块的所有信息：

简单介绍一下它其中的每个属性。

id：模块的识别符，通常是带有绝对路径的模块文件名。

path：当前模块的绝对路径。

export：表示模块对外输出的值。我这里导出了一个3。

parent：返回一个对象，表示调用该模块的模块。没有就返回null

filename：模块的文件名，带有绝对路径。

loaded：返回一个布尔值，表示模块是否已经完成加载。

children：返回一个数组，表示该模块要用到的其他模块。

paths：当前模块查找的绝对路径数组。它遵循一定的模块路径查询规则。

我们可以利用parent属性来判断当前文件是不是一个入口文件：

我们了解了module对象后，对接下来分析模块路径查询规则很有帮助了。

上面我们已经看到了在module对象中有个很重要的属性paths，里面存放了一个路径数组。现在换成自定义模块的写法来引入sum模块：

main.js

然后在main.js同级目录下创建一个node_modules目录，创建一个sum.js模块：

node_modules/sum.js

执行main.js：

我们发现，通过自定义模块方式引入的sum.js和文件模块中的paths是一样的结果。所以我们可以得出一个规则：

奇怪的是，在main.js中我们发现node_modules目录也被打印了出来，可是，我们看到的是main.js并不在该目录下面啊，这是怎么回事呢? 这里留个思考题。

路径分析好了后，下面要具体定位文件的位置了，主要分为两个步骤：文件拓展名分析和目录分析。

我们使用require引入模块的时候，可以不加文件的后缀名。比如：

这个时候Node就会进行文件拓展名分析，会依次分析下面三个拓展名：

在分析的过程中，Node会同步阻塞式调用fs模块来判断文件是否存在。如果查找不到这个文件，而得到了一个目录，那么将会进行目录（包）分析。

为了测试，我们来整理下目录结构：

有同学肯定还是要问，为啥要放在node_modules下面呢，这个还真不好回答，请翻到上面再看一下路径分析，希望对你有帮助哦。

package.json

其余代码不变。执行main.js后发现能够正常打印结果就能说明模块加载成功了。上面其实就是一个目录分析的过程了。

如果你理解了这个过程，你也就理解了npm install 的时候为什么会自动生成node_modules文件夹，并且文件夹下有好多包。然后我们引入的方式就是自定义模块引入的方式。

上面的步骤完成后，也就是说现在已经找到了模块了，我们需要对模块进行编译，并执行模块里面的代码，把需要暴露出来的变量都暴露出来。不同的文件拓展名，载入的编译方法是不一样的。

每一个编译成功的模块都会将文件的绝对路径当作索引缓存在Module._cache对象上，来提升二次引入的性能。

这一块的编译主要是通过Node同步调用fs模块读取JSON文件内容后，使用JSON.parse方法解析，然后将解析后的结果放到exports对象暴露出去。它一般都是作为一个配置文件说明，而且一般都是node自己加载pacakage.json。处理代码如下：

node文件主要是C/C++ 的拓展，其实C/C++ 已经编译好了封装在了libuv层，只需要在node曾调用procee.dlopen方法就可以加载执行。这一块难度较大，就不多说了。

编译JavaScript文件过程中，给当前模块包上一层函数，采用闭包来解决全局变量污染问题。下面是一个简单的实现。

包装完后，将需要导出的变量通过module.exports导出去了。其他模块就只能访问导出来的变量，其余变量是访问不到的

CommonJS模块的加载机制是，输入的是被输出的值的拷贝。也就是说，一旦输出一个值，模块内部的变化就影响不到这个值。 我们将main.js代码改变一下：

可以看到，两个模块是不会影响的。

但是在ES Module中是不一样的，它是静态加载。也就是在代码静态解析阶段就已经确认好模块依赖关系了。一句话总结就是：

CommonJS 模块输出的是一个值的拷贝，ES6 模块输出的是值的引用。

所以在ES Module模块与模块是互相影响的。

之前对CommonJS模块化的理解模模糊糊的，这篇文章算是我的一个笔记吧，毕竟大部分内容是从前辈们的文章或书籍里面借鉴的，跟着他们的脚步来走的。即便如此，我发现还是收获不少，再次感谢它们的文章和书籍。虽然还有很多不完善的地方，但我对自己还是有信心的，争取以后有更多自己的理解。

【1】《深入浅出Node.js》朴灵编著

【2】阮一峰 CommonJS规范

【3】廖雪峰 模块