前言

在我們使用 Node 進(jìn)行日常開發(fā)時(shí)，經(jīng)常會(huì)使用 require 導(dǎo)入兩類模塊，一類是我們自己編寫的模塊或使用 npm 安裝的第三方模塊，這類模塊在 Node 中稱為 文件模塊；另一類則是 Node 內(nèi)置的提供給我們使用的模塊，如 os、fs 等模塊，這些模塊被稱為 核心模塊。

需要注意的是，文件模塊與核心模塊的差異不僅僅在于是否被 Node 內(nèi)置，具體到模塊的文件定位、編譯和執(zhí)行過程，兩者之間都存在明顯的差別。不僅如此，文件模塊還可以被細(xì)分為普通文件模塊、自定義模塊或 C/C++ 擴(kuò)展模塊等等，不同的模塊在文件定位、編譯等流程也存在諸多細(xì)節(jié)上的不同。

本文會(huì)就這些問題，理清文件模塊與核心模塊的概念以及它們?cè)谖募ㄎ?、編譯或執(zhí)行等流程的具體過程和需要注意的細(xì)節(jié)，希望對(duì)你有所幫助。

我們先從文件模塊講起。

文件模塊

什么是文件模塊呢？

在 Node 中，使用 .、.. 或 / 開頭的模塊標(biāo)識(shí)符（也就是使用相對(duì)路徑或絕對(duì)路徑）來 require 的模塊，都會(huì)被當(dāng)作文件模塊。另外，還有一類特殊的模塊，雖然不含有相對(duì)路徑或絕對(duì)路徑，也不是核心模塊，但是會(huì)指向一個(gè)包，Node 在定位這類模塊時(shí)，會(huì)用 模塊路徑 逐個(gè)查找該模塊，這類模塊被稱為自定義模塊。

因此，文件模塊包含兩類，一類是帶路徑的普通文件模塊，一類是不帶路徑的自定義模塊。

文件模塊在運(yùn)行時(shí)動(dòng)態(tài)加載，需要完整的文件定位、編譯執(zhí)行過程，速度比核心模塊慢。

對(duì)于文件定位而言，Node 對(duì)這兩類文件模塊的處理有所不同。我們來具體看看這兩類文件模塊的查找流程。

普通文件模塊的查找

對(duì)于普通的文件模塊，由于攜帶路徑，指向非常明確，查找耗時(shí)不會(huì)很久，因此查找效率比下文要介紹的自定義模塊要高一些。不過還是有兩點(diǎn)需要注意。

一是通常情況下，使用 require 引入文件模塊時(shí)一般都不會(huì)指定文件擴(kuò)展名，比如：

const math = require("math");

由于沒有指定擴(kuò)展名，Node 還不能確定最終的文件。在這種情況下，Node 會(huì)按 .js、.json、.node 的順序補(bǔ)足擴(kuò)展名，依次嘗試，這個(gè)過程被稱為 文件擴(kuò)展名分析。

另外需要注意的是，在實(shí)際開發(fā)中，除了 require 一個(gè)具體的文件外，我們通常還會(huì)指定一個(gè)目錄，比如：

const axios = require("../network");

在這種情況下，Node 會(huì)先進(jìn)行文件擴(kuò)展名分析，如果沒有查找到對(duì)應(yīng)文件，但是得到了一個(gè)目錄，此時(shí) Node 會(huì)將該目錄當(dāng)作一個(gè)包來處理。

具體而言，Node 會(huì)將目錄中的 package.json 的 main 字段所指向的文件作為查找結(jié)果返回。如果 main 所指向的文件錯(cuò)誤，或者壓根不存在 package.json 文件，Node 會(huì)使用 index 作為默認(rèn)文件名，然后依次使用 .js、.node 進(jìn)行擴(kuò)展名分析，逐個(gè)查找目標(biāo)文件，如果沒有找到的話就會(huì)拋出錯(cuò)誤。

（當(dāng)然，由于 Node 存在兩類模塊系統(tǒng) CJS 和 ESM，除了查找 main 字段外，Node 還會(huì)采用其他方式，由于不在本文討論范圍內(nèi)，就不再贅述了。）

自定義模塊的查找

剛才提到，Node 在查找自定義模塊的過程中，會(huì)使用到模塊路徑，那什么是模塊路徑呢？

熟悉模塊解析的朋友應(yīng)該都知道，模塊路徑是一個(gè)由路徑組成的數(shù)組，具體的值可以看以下這個(gè)示例：

// example.js
console.log(module.paths);

打印結(jié)果：

可以看到，Node 中的模塊存在一個(gè)模塊路徑數(shù)組，存放在 module.paths 中，用于規(guī)定 Node 如何查找當(dāng)前模塊引用的自定義模塊。

具體來講，Node 會(huì)遍歷模塊路徑數(shù)組，逐個(gè)嘗試其中的路徑，查找該路徑對(duì)應(yīng)的 node_modules 目錄中是否有指定的自定義模塊，如果沒有就向上逐級(jí)遞歸，一直到根目錄下的 node_modules 目錄，直到找到目標(biāo)模塊為止，如果找不到的話就會(huì)拋出錯(cuò)誤。

可以看出，逐級(jí)向上遞歸查找 node_modules 目錄是 Node 查找自定義模塊的策略，而模塊路徑便是這個(gè)策略的具體實(shí)現(xiàn)。

同時(shí)我們也得出一個(gè)結(jié)論，在查找自定義模塊時(shí)，層級(jí)越深，相應(yīng)的查找耗時(shí)就會(huì)越多。因此相比于核心模塊和普通的文件模塊，自定義模塊的加載速度是最慢的。

當(dāng)然，根據(jù)模塊路徑查找到的僅僅是一個(gè)目錄，并不是一個(gè)具體的文件，在查找到目錄后，同樣地，Node 會(huì)根據(jù)上文所描述的包處理流程進(jìn)行查找，具體過程不再贅述了。

以上是普通文件模塊和自定義模塊的文件定位的流程和需要注意的細(xì)節(jié)，接下來我們來看者兩類模塊是如何編譯執(zhí)行的。

文件模塊的編譯執(zhí)行

當(dāng)定位到 require 所指向的文件后，通常模塊標(biāo)識(shí)符都不帶有擴(kuò)展名，根據(jù)上文提到的文件擴(kuò)展名分析我們可以知道，Node 支持三種擴(kuò)展名文件的編譯執(zhí)行：

• JavaScript 文件。通過 fs 模塊同步讀取文件后編譯執(zhí)行。除了 .node 和 .json 文件，其他文件都會(huì)被當(dāng)作 .js 文件載入。
• .node 文件，這是用 C/C++ 編寫后編譯生成的擴(kuò)展文件，Node 通過 process.dlopen() 方法加載該文件。
• json 文件，通過 fs 模塊同步讀取文件后，使用 JSON.parse() 解析并返回結(jié)果。

在對(duì)文件模塊進(jìn)行編譯執(zhí)行之前，Node 會(huì)使用如下所示的模塊封裝器對(duì)其進(jìn)行包裝：

(function(exports, require, module, __filename, __dirname) {
    // 模塊代碼
});

可以看到，通過模塊封裝器，Node 將模塊包裝進(jìn)函數(shù)作用域中，與其他作用域隔離，避免變量的命名沖突、污染全局作用域等問題，同時(shí)，通過傳入 exports、require 參數(shù)，使該模塊具備應(yīng)有的導(dǎo)入與導(dǎo)出能力。這便是 Node 對(duì)模塊的實(shí)現(xiàn)。

了解了模塊封裝器后，我們先來看 json 文件的編譯執(zhí)行流程。

json 文件的編譯執(zhí)行

json 文件的編譯執(zhí)行是最簡(jiǎn)單的。在通過 fs 模塊同步讀取 JSON 文件的內(nèi)容后，Node 會(huì)使用 JSON.parse() 解析出 JavaScript 對(duì)象，然后將它賦給該模塊的 exports 對(duì)象，最后再返回給引用它的模塊，過程十分簡(jiǎn)單粗暴。

JavaScript 文件的編譯執(zhí)行

在使用模塊包裝器對(duì) JavaScript 文件進(jìn)行包裝后，包裝之后的代碼會(huì)通過 vm 模塊的 runInThisContext()（類似 eval） 方法執(zhí)行，返回一個(gè) function 對(duì)象。

然后，將該 JavaScript 模塊的 exports、require、module 等參數(shù)傳遞給這個(gè) function 執(zhí)行，執(zhí)行之后，模塊的 exports 屬性被返回給調(diào)用方，這就是 JavaScript 文件的編譯執(zhí)行過程。

C/C++ 擴(kuò)展模塊的編譯執(zhí)行

在講解 C/C++ 擴(kuò)展模塊的編譯執(zhí)行之前，先介紹一下什么是 C/C++ 擴(kuò)展模塊。

C/C++ 擴(kuò)展模塊屬于文件模塊中的一類，顧名思義，這類模塊由 C/C++ 編寫，與 JavaScript 模塊的區(qū)別在于其加載之后不需要編譯，直接執(zhí)行之后就可以被外部調(diào)用了，因此其加載速度比 JavaScript 模塊略快。相比于用 JS 編寫的文件模塊，C/C++ 擴(kuò)展模塊明顯更具有性能上的優(yōu)勢(shì)。對(duì)于 Node 核心模塊中無法覆蓋的功能或者有特定的性能需求，用戶可以編寫 C/C++ 擴(kuò)展模塊來達(dá)到目的。

那 .node 文件又是什么呢，它跟 C/C++ 擴(kuò)展模塊有什么關(guān)系？

事實(shí)上，編寫好之后的 C/C++ 擴(kuò)展模塊經(jīng)過編譯之后就生成了 .node 文件。也就是說，作為模塊的使用者，我們并不直接引入 C/C++ 擴(kuò)展模塊的源代碼，而是引入 C/C++ 擴(kuò)展模塊經(jīng)過編譯之后的二進(jìn)制文件。因此，.node 文件并不需要編譯，Node 在查找到 .node 文件后，只需加載和執(zhí)行該文件即可。在執(zhí)行的過程中，模塊的 exports 對(duì)象被填充，然后返回給調(diào)用者。

值得注意的是，C/C++ 擴(kuò)展模塊編譯生成的 .node 文件在不同平臺(tái)下有不同的形式：在 *nix 系統(tǒng)下C/C++ 擴(kuò)展模塊被 g++/gcc 等編譯器編譯為動(dòng)態(tài)鏈接共享對(duì)象文件，擴(kuò)展名為 .so；在 Windows 下則被 Visual C++ 編譯器編譯為動(dòng)態(tài)鏈接庫文件，擴(kuò)展名為 .dll。但是在我們實(shí)際使用時(shí)使用的擴(kuò)展名卻是 .node，事實(shí)上 .node 的擴(kuò)展名只是為了看起來更自然一點(diǎn)，實(shí)際上，在 Windows 下它是一個(gè) .dll 文件，在 *nix 下則是一個(gè) .so 文件。

Node 在查找到要 require 的 .node 文件之后，會(huì)調(diào)用 process.dlopen() 方法對(duì)該文件進(jìn)行加載和執(zhí)行。由于 .node 文件在不同平臺(tái)下是不同的文件形式，為了實(shí)現(xiàn)跨平臺(tái)，dlopen() 方法在 Windows 和 *nix 平臺(tái)下分別有不同的實(shí)現(xiàn)，然后通過 libuv 兼容層進(jìn)行封裝。

下圖是 C/C++ 擴(kuò)展模塊在不同平臺(tái)下編譯和加載的過程：

核心模塊

核心模塊在 Node 源代碼的編譯過程中，就編譯進(jìn)了二進(jìn)制執(zhí)行文件。在 Node 進(jìn)程啟動(dòng)時(shí)，部分核心模塊就被直接加載進(jìn)內(nèi)存中，所以這部分核心模塊引入時(shí)，文件定位和編譯執(zhí)行這兩個(gè)步驟可以省略掉，并且在路徑分析中會(huì)比文件模塊優(yōu)先判斷，所以它的加載速度是最快的。

核心模塊其實(shí)分為 C/C++ 編寫的和 JavaScript 編寫的兩部分，其中 C/C++ 文件存放在 Node 項(xiàng)目的 src 目錄下，JavaScript 文件存放在 lib 目錄下。顯然，這兩部分模塊的編譯執(zhí)行流程都有所不同。

JavaScript 核心模塊的編譯執(zhí)行

對(duì)于 JavaScript 核心模塊的編譯，在 Node 源代碼的編譯過程中，Node 會(huì)采用 V8 附帶的 js2c.py 工具，將所有內(nèi)置的 JavaScript 代碼，包括 JavaScript 核心模塊，轉(zhuǎn)換為 C++ 里的數(shù)組，JavaScript 代碼就這樣以字符串的形式存儲(chǔ)在 node 命名空間中。在啟動(dòng) Node 進(jìn)程時(shí)，JavaScript 代碼就會(huì)直接加載進(jìn)內(nèi)存。

當(dāng)引入 JavaScript 核心模塊時(shí)，Node 會(huì)調(diào)用 process.binding() 通過模塊標(biāo)識(shí)符分析定位到其在內(nèi)存中的位置，將其取出。在取出后，JavaScript 核心模塊同樣會(huì)經(jīng)歷模塊包裝器的包裝，然后被執(zhí)行，導(dǎo)出 exports 對(duì)象，返回給調(diào)用者。

C/C++ 核心模塊的編譯執(zhí)行

在核心模塊中，有些模塊全部由 C/C++ 編寫，有些模塊則由 C/C++ 完成核心部分，其他部分則由 JavaScript 實(shí)現(xiàn)包裝或向外導(dǎo)出，以滿足性能需求，像 buffer、fs、os 等模塊都是部分通過 C/C++ 編寫的。這種 C++ 模塊主內(nèi)完成核心，JavaScript 模塊主外實(shí)現(xiàn)封裝的模式是 Node 提高性能的常見方式。

核心模塊中由純 C/C++ 編寫的部分稱為內(nèi)建模塊，如 node_fs、node_os 等，它們通常不被用戶直接調(diào)用，而是被 JavaScript 核心模塊直接依賴。

因此，在 Node 的核心模塊的引入過程中，存在這樣一條引用鏈：

那 JavaScript 核心模塊是如何加載內(nèi)建模塊的呢？

還記得 process.binding() 方法嗎，Node 通過調(diào)用該方法實(shí)現(xiàn)將 JavaScript 核心模塊從內(nèi)存中取出。該方法同樣適用于 JavaScript 核心模塊，來協(xié)助加載內(nèi)建模塊。

具體到該方法的實(shí)現(xiàn)，加載內(nèi)建模塊時(shí)，首先創(chuàng)建一個(gè) exports 空對(duì)象，然后調(diào)用 get_builtin_module() 方法取出內(nèi)建模塊對(duì)象，通過執(zhí)行 register_func() 填充 exports 對(duì)象，最后返回給調(diào)用方完成導(dǎo)出。這就是內(nèi)建模塊的加載和執(zhí)行過程。

通過以上分析，對(duì)于引入核心模塊這樣一條引用鏈，以 os 模塊為例，大致的流程如下：

總結(jié)來說，引入 os 模塊的過程經(jīng)歷 JavaScript 文件模塊的引入、JavaScript 核心模塊的加載和執(zhí)行和內(nèi)建模塊的加載執(zhí)行，過程十分繁瑣復(fù)雜，但是對(duì)于模塊的調(diào)用者來說，由于屏蔽了底層的復(fù)雜實(shí)現(xiàn)和細(xì)節(jié)，僅僅通過 require() 就可完成整個(gè)模塊的導(dǎo)入，十分簡(jiǎn)潔。友好。

總結(jié)

本文介紹了文件模塊與核心模塊的基本概念以及它們?cè)谖募ㄎ?、編譯或執(zhí)行等流程的具體過程和需要注意的細(xì)節(jié)。

具體而言：

• 文件模塊根據(jù)文件定位過程的不同可以分為普通文件模塊和自定義模塊。普通文件模塊由于路徑明確，可以直接定位，有時(shí)會(huì)涉及到文件擴(kuò)展名分析、目錄分析的過程；自定義模塊會(huì)根據(jù)模塊路徑進(jìn)行查找，查找成功之后也會(huì)通過目錄分析進(jìn)行最終的文件定位。
• 文件模塊根據(jù)編譯執(zhí)行流程的不同可以分為 JavaScript 模塊和 C/C++ 擴(kuò)展模塊。JavaScript 模塊被模塊封裝器包裝之后通過 vm 模塊的 runInThisContext 方法進(jìn)行執(zhí)行；C/C++ 擴(kuò)展模塊由于已經(jīng)是經(jīng)過編譯之后生成的可執(zhí)行文件，因此可直接執(zhí)行，返回導(dǎo)出對(duì)象給調(diào)用方。
• 核心模塊分為 JavaScript 核心模塊和內(nèi)建模塊。JavaScript 核心模塊在 Node 進(jìn)程啟動(dòng)時(shí)便被加載進(jìn)內(nèi)存中，通過 process.binding() 方法可將其取出，然后執(zhí)行；內(nèi)建模塊的編譯執(zhí)行會(huì)經(jīng)歷 process.binding()、get_builtin_module() 和 register_func() 函數(shù)的處理。

除此之外，我們還得出了 Node 引入核心模塊的引用鏈，即文件模塊-->JavaScript 核心模塊-->內(nèi)建模塊，也學(xué)習(xí)了 C++ 模塊主內(nèi)完成核心，JavaScript 模塊主外實(shí)現(xiàn)封裝的模塊編寫方式。

到此這篇關(guān)于一文詳解Node 中文件模塊與核心模塊的文章就介紹到這了,更多相關(guān)Node 文件模塊與核心模塊內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！