한 기사에서 Node의 파일 모듈과 핵심 모듈에 대해 알아보세요.

사용자 정의 모듈 검색

具体来讲，Node 会遍历模块路径数组，逐个尝试其中的路径，查找该路径对应的node_modules目录中是否有指定的自定义模块，如果没有就向上逐级递归，一直到根目录下的node_modules目录，直到找到目标模块为止，如果找不到的话就会抛出错误。

可以看出，逐级向上递归查找node_modules目录是 Node 查找自定义模块的策略，而模块路径便是这个策略的具体实现。

同时我们也得出一个结论，在查找自定义模块时，层级越深，相应的查找耗时就会越多。因此相比于核心模块和普通的文件模块，自定义模块的加载速度是最慢的。

当然，根据模块路径查找到的仅仅是一个目录，并不是一个具体的文件，在查找到目录后，同样地，Node 会根据上文所描述的包处理流程进行查找，具体过程不再赘述了。

以上是普通文件模块和自定义模块的文件定位的流程和需要注意的细节，接下来我们来看者两类模块是如何编译执行的。

文件模块的编译执行

当定位到 require 所指向的文件后，通常模块标识符都不带有扩展名，根据上文提到的文件扩展名分析我们可以知道，Node 支持三种扩展名文件的编译执行：

• JavaScript 文件。通过fs模块同步读取文件后编译执行。除了.node和.json文件，其他文件都会被当作.js文件载入。

• .node文件，这是用 C/C++ 编写后编译生成的扩展文件，Node 通过process.dlopen()方法加载该文件。

• json 文件，通过fs模块同步读取文件后，使用JSON.parse()解析并返回结果。

在对文件模块进行编译执行之前，Node 会使用如下所示的模块封装器对其进行包装：

(function(exports, require, module, __filename, __dirname) { // 模块代码 });

可以看到，通过模块封装器，Node 将模块包装进函数作用域中，与其他作用域隔离，避免变量的命名冲突、污染全局作用域等问题，同时，通过传入 exports、require 参数，使该模块具备应有的导入与导出能力。这便是 Node 对模块的实现。

了解了模块封装器后，我们先来看 json 文件的编译执行流程。

json 文件的编译执行

json 文件的编译执行是最简单的。在通过fs模块同步读取 JSON 文件的内容后，Node 会使用 JSON.parse() 解析出 JavaScript 对象，然后将它赋给该模块的 exports 对象，最后再返回给引用它的模块，过程十分简单粗暴。

JavaScript 文件的编译执行

在使用模块包装器对 JavaScript 文件进行包装后，包装之后的代码会通过vm模块的runInThisContext()（类似 eval） 方法执行，返回一个 function 对象。

然后，将该 JavaScript 模块的 exports、require、module 等参数传递给这个 function 执行，执行之后，模块的 exports 属性被返回给调用方，这就是 JavaScript 文件的编译执行过程。

C/C++ 扩展模块的编译执行

在讲解 C/C++ 扩展模块的编译执行之前，先介绍一下什么是 C/C++ 扩展模块。

C/C++ 扩展模块属于文件模块中的一类，顾名思义，这类模块由 C/C++ 编写，与 JavaScript 模块的区别在于其加载之后不需要编译，直接执行之后就可以被外部调用了，因此其加载速度比 JavaScript 模块略快。相比于用 JS 编写的文件模块，C/C++ 扩展模块明显更具有性能上的优势。对于 Node 核心模块中无法覆盖的功能或者有特定的性能需求，用户可以编写 C/C++ 扩展模块来达到目的。

那.node文件又是什么呢，它跟 C/C++ 扩展模块有什么关系？

事实上，编写好之后的 C/C++ 扩展模块经过编译之后就生成了.node文件。也就是说，作为模块的使用者，我们并不直接引入 C/C++ 扩展模块的源代码，而是引入 C/C++ 扩展模块经过编译之后的二进制文件。因此，.node文件并不需要编译，Node 在查找到.node文件后，只需加载和执行该文件即可。在执行的过程中，模块的 exports 对象被填充，然后返回给调用者。

C/C++ 확장 모듈을 컴파일하여 생성된.node파일은 플랫폼마다 다른 형태를 갖는다는 점에 주목할 가치가 있습니다.*nix시스템의 C/C++ 확장 모듈 이는Windows에서.so확장자를 사용하여 g++/gcc와 같은 컴파일러에 의해 동적 링크 공유 개체 파일로 컴파일되며 동적 링크 라이브러리 파일로 컴파일됩니다. Visual C++ 컴파일러의 경우 확장자는.dll입니다. 하지만 실제로 사용하는 확장자는.node입니다. 사실.node의 확장자는 실제로에서 더 자연스럽게 보이기 위한 것입니다. >Windows의.dll파일 및*nix의.so파일..node文件在不同平台下有不同的形式：在*nix系统下C/C++ 扩展模块被 g++/gcc 等编译器编译为动态链接共享对象文件，扩展名为.so；在Windows下则被 Visual C++ 编译器编译为动态链接库文件，扩展名为.dll。但是在我们实际使用时使用的扩展名却是.node，事实上.node的扩展名只是为了看起来更自然一点，实际上，在Windows下它是一个.dll文件，在*nix下则是一个.so文件。

Node 在查找到要 require 的.node文件之后，会调用process.dlopen()方法对该文件进行加载和执行。由于.node文件在不同平台下是不同的文件形式，为了实现跨平台，dlopen()方法在Windows和*nix平台下分别有不同的实现，然后通过libuv兼容层进行封装。下图是 C/C++ 扩展模块在不同平台下编译和加载的过程：

核心模块

核心模块在 Node 源代码的编译过程中，就编译进了二进制执行文件。在 Node 进程启动时，部分核心模块就被直接加载进内存中，所以这部分核心模块引入时，文件定位和编译执行这两个步骤可以省略掉，并且在路径分析中会比文件模块优先判断，所以它的加载速度是最快的。

核心模块其实分为 C/C++ 编写的和 JavaScript 编写的两部分，其中 C/C++ 文件存放在 Node 项目的 src 目录下，JavaScript 文件存放在 lib 目录下。显然，这两部分模块的编译执行流程都有所不同。

JavaScript 核心模块的编译执行

对于 JavaScript 核心模块的编译，在 Node 源代码的编译过程中，Node 会采用 V8 附带的 js2c.py 工具，将所有内置的 JavaScript 代码，包括 JavaScript 核心模块，转换为 C++ 里的数组，JavaScript 代码就这样以字符串的形式存储在 node 命名空间中。在启动 Node 进程时，JavaScript 代码就会直接加载进内存。

当引入 JavaScript 核心模块时，Node 会调用process.binding()通过模块标识符分析定位到其在内存中的位置，将其取出。在取出后，JavaScript 核心模块同样会经历模块包装器的包装，然后被执行，导出 exports 对象，返回给调用者。

C/C++ 核心模块的编译执行

在核心模块中，有些模块全部由 C/C++ 编写，有些模块则由 C/C++ 完成核心部分，其他部分则由 JavaScript 实现包装或向外导出，以满足性能需求，像buffer、fs、os等模块都是部分通过 C/C++ 编写的。这种C++ 模块主内完成核心，JavaScript 模块主外实现封装的模式是 Node 提高性能的常见方式。

核心模块中由纯 C/C++ 编写的部分称为内建模块，如node_fs、node_os等，它们通常不被用户直接调用，而是被 JavaScript 核心模块直接依赖。因此，在 Node 的核心模块的引入过程中，存在这样一条引用链：

那 JavaScript 核心模块是如何加载内建模块的呢？

还记得process.binding()方法吗，Node 通过调用该方法实现将 JavaScript 核心模块从内存中取出。该方法同样适用于 JavaScript 核心模块，来协助加载内建模块。

具体到该方法的实现，加载内建模块时，首先创建一个 exports 空对象，然后调用get_builtin_module()方法取出内建模块对象，通过执行register_func()

핵심 모듈

핵심 모듈은 실제로 C/C++와 JavaScript로 작성된 두 부분으로 나누어져 있습니다. C/C++ 파일은 Node 프로젝트의 src 디렉터리에 저장되고, JavaScript 파일은 lib 디렉터리에 저장됩니다. 분명히 이 두 모듈의 컴파일 및 실행 프로세스는 다릅니다.

JavaScript 핵심 모듈 컴파일 및 실행

C/C++ 핵심 모듈 컴파일 및 실행