正文

本文只討論 CommonJS 規(guī)范，不涉及 ESM

我們知道 JavaScript 這門(mén)語(yǔ)言誕生之初主要是為了完成網(wǎng)頁(yè)上表單的一些規(guī)則校驗(yàn)以及動(dòng)畫(huà)制作，所以布蘭登.艾奇（Brendan Eich）只花了一周多就把 JavaScript 設(shè)計(jì)出來(lái)了?？梢哉f(shuō) JavaScript 從出生開(kāi)始就帶著許多缺陷和缺點(diǎn)，這一點(diǎn)一直被其他語(yǔ)言的編程者所嘲笑。隨著 BS 開(kāi)發(fā)模式漸漸地火了起來(lái)，JavaScript 所要承擔(dān)的責(zé)任也越來(lái)越大，ECMA 接手標(biāo)準(zhǔn)化之后也漸漸的開(kāi)始完善了起來(lái)。

在 ES 6 之前，JavaScript 一直是沒(méi)有自己的模塊化機(jī)制的，JavaScript 文件之間無(wú)法相互引用，只能依賴腳本的加載順序以及全局變量來(lái)確定變量的傳遞順序和傳遞方式。而 script 標(biāo)簽太多會(huì)導(dǎo)致文件之間依賴關(guān)系混亂，全局變量太多也會(huì)導(dǎo)致數(shù)據(jù)流相當(dāng)紊亂，命名沖突和內(nèi)存泄漏也會(huì)更加頻繁的出現(xiàn)。直到 ES 6 之后，JavaScript 開(kāi)始有了自己的模塊化機(jī)制，不用再依賴 requirejs、seajs 等插件來(lái)實(shí)現(xiàn)模塊化了。

在 Nodejs 出現(xiàn)之前，服務(wù)端 JavaScript 基本上處于一片荒蕪的境況，而當(dāng)時(shí)也沒(méi)有出現(xiàn) ES 6 的模塊化規(guī)范（Nodejs 最早從 V8.5 開(kāi)始支持 ESM 規(guī)范：Node V8.5 更新日志），所以 Nodejs 采用了當(dāng)時(shí)比較先進(jìn)的一種模塊化規(guī)范來(lái)實(shí)現(xiàn)服務(wù)端 JavaScript 的模塊化機(jī)制，它就是 CommonJS，有時(shí)也簡(jiǎn)稱為 CJS。

這篇文章主要講解 CommonJS 在 Nodejs 中的實(shí)現(xiàn)。

一、CommonJS 規(guī)范

在 Nodejs 采用 CommonJS 規(guī)范之前，還存在以下缺點(diǎn)：

• 沒(méi)有模塊系統(tǒng)
• 標(biāo)準(zhǔn)庫(kù)很少
• 沒(méi)有標(biāo)準(zhǔn)接口
• 缺乏包管理系統(tǒng)

這幾點(diǎn)問(wèn)題的存在導(dǎo)致 Nodejs 始終難以構(gòu)建大型的項(xiàng)目，生態(tài)環(huán)境也是十分的貧乏，所以這些問(wèn)題都是亟待解決的。

CommonJS 的提出，主要是為了彌補(bǔ)當(dāng)前 JavaScript 沒(méi)有模塊化標(biāo)準(zhǔn)的缺陷，以達(dá)到像 Java、Python、Ruby 那樣能夠構(gòu)建大型應(yīng)用的階段，而不是僅僅作為一門(mén)腳本語(yǔ)言。Nodejs 能夠擁有今天這樣繁榮的生態(tài)系統(tǒng)，CommonJS 功不可沒(méi)。

1.1 CommonJS 的模塊化規(guī)范

CommonJS 對(duì)模塊的定義十分簡(jiǎn)單，主要分為模塊引用、模塊定義和模塊標(biāo)識(shí)三個(gè)部分。下面進(jìn)行簡(jiǎn)單介紹：

1.1.1、模塊引用

示例如下：

const fs = require('fs')

在 CommonJS 規(guī)范中，存在一個(gè) require “全局”方法，它接受一個(gè)標(biāo)識(shí)，然后把標(biāo)識(shí)對(duì)應(yīng)的模塊的 API 引入到當(dāng)前模塊作用域中。

1.1.2、模塊定義

我們已經(jīng)知道了如何引入一個(gè) Nodejs 模塊，但是我們應(yīng)該如何定義一個(gè) Nodejs 模塊呢？在 Nodejs 上下文環(huán)境中提供了一個(gè) module 對(duì)象和一個(gè) exports 對(duì)象，module 代表當(dāng)前模塊，exports 是當(dāng)前模塊的一個(gè)屬性，代表要導(dǎo)出的一些 API。在 Nodejs 中，一個(gè)文件就是一個(gè)模塊，把方法或者變量作為屬性掛載在 exports 對(duì)象上即可將其作為模塊的一部分進(jìn)行導(dǎo)出。

// add.js
exports.add = function(a, b) {
    return a + b
}

在另一個(gè)文件中，我們就可以通過(guò) require 引入之前定義的這個(gè)模塊：

const { add } = require('./add.js')
add(1, 2) // print 3

1.1.3、模塊標(biāo)識(shí)

模塊標(biāo)識(shí)就是傳遞給 require 函數(shù)的參數(shù)，在 Nodejs 中就是模塊的 id。它必須是符合小駝峰命名的字符串，或者是以.、..開(kāi)頭的相對(duì)路徑，或者絕對(duì)路徑，可以不帶后綴名。

模塊的定義十分簡(jiǎn)單，接口也很簡(jiǎn)潔。它的意義在于將類聚的方法和變量等限定在私有的作用于域中，同時(shí)支持引入和導(dǎo)出功能以順暢的連接上下游依賴。

CommonJS 這套模塊導(dǎo)出和引入的機(jī)制使得用戶完全不必考慮變量污染。

以上只是對(duì)于 CommonJS 規(guī)范的簡(jiǎn)單介紹，更多具體的內(nèi)容可以參考：CommonJS規(guī)范

二、Nodejs 的模塊化實(shí)現(xiàn)

Nodejs 在實(shí)現(xiàn)中并沒(méi)有完全按照規(guī)范實(shí)現(xiàn)，而是對(duì)模塊規(guī)范進(jìn)行了一定的取舍，同時(shí)也增加了一些自身需要的特性。接下來(lái)我們會(huì)探究一下 Nodejs 是如何實(shí)現(xiàn) CommonJS 規(guī)范的。

在 Nodejs 中引入模塊會(huì)經(jīng)過(guò)以下三個(gè)步驟：

• 路徑分析
• 文件定位
• 編譯執(zhí)行

在了解具體的內(nèi)容之前我們先了解兩個(gè)概念：

• 核心模塊：Nodejs 提供的內(nèi)置模塊，比如 fs、url、http 等
• 文件模塊：用戶自己編寫(xiě)的模塊，比如 Koa、Express 等

核心模塊在 Nodejs 源代碼的編譯過(guò)程中已經(jīng)編譯進(jìn)了二進(jìn)制文件，Nodejs 啟動(dòng)時(shí)會(huì)被直接加載到內(nèi)存中，所以在我們引入這些模塊的時(shí)候就省去了文件定位、編譯執(zhí)行這兩個(gè)步驟，加載速度比文件模塊要快很多。

文件模塊是在運(yùn)行的時(shí)候動(dòng)態(tài)加載，需要走一套完整的流程：路徑分析、文件定位、編譯執(zhí)行等，所以文件模塊的加載速度比核心模塊要慢。

2.1 優(yōu)先從緩存加載

在講解具體的加載步驟之前，我們應(yīng)當(dāng)知曉的一點(diǎn)是，Nodejs 對(duì)于已經(jīng)加載過(guò)一邊的模塊會(huì)進(jìn)行緩存，模塊的內(nèi)容會(huì)被緩存到內(nèi)存當(dāng)中，如果下次加載了同一個(gè)模塊的話，就會(huì)從內(nèi)存中直接取出來(lái)，這樣就省去了第二次路徑分析、文件定位、加載執(zhí)行的過(guò)程，大大提高了加載速度。無(wú)論是核心模塊還是文件模塊，require() 對(duì)同一文件的第二次加載都一律會(huì)采用緩存優(yōu)先的方式，這是第一優(yōu)先級(jí)的。但是核心模塊的緩存檢查優(yōu)先于文件模塊的緩存檢查。

我們?cè)?Nodejs 文件中所使用的 require 函數(shù)，實(shí)際上就是在 Nodejs 項(xiàng)目中的 lib/internal/modules/cjs/loader.js 所定義的 Module.prototype.require 函數(shù)，只不過(guò)在后面的 makeRequireFunction 函數(shù)中還會(huì)進(jìn)行一層封裝，Module.prototype.require 源碼如下：

// Loads a module at the given file path. Returns that module's
// `exports` property.
Module.prototype.require = function(id) {
    validateString(id, 'id');
    if (id === '') {
        throw new ERR_INVALID_ARG_VALUE('id', id,
                                        'must be a non-empty string');
    }
    requireDepth++;
    try {
        return Module._load(id, this, /* isMain */ false);
    } finally {
        requireDepth--;
    }
};

可以看到它最終使用了 Module._load 方法來(lái)加載我們的標(biāo)識(shí)符所指定的模塊，找到 Module._load：

Module._cache = Object.create(null);
// 這里先定義了一個(gè)緩存的對(duì)象
// ... ...
// Check the cache for the requested file.
// 1. If a module already exists in the cache: return its exports object.
// 2. If the module is native: call
//    `NativeModule.prototype.compileForPublicLoader()` and return the exports.
// 3. Otherwise, create a new module for the file and save it to the cache.
//    Then have it load  the file contents before returning its exports
//    object.
Module._load = function(request, parent, isMain) {
    let relResolveCacheIdentifier;
    if (parent) {
        debug('Module._load REQUEST %s parent: %s', request, parent.id);
        // Fast path for (lazy loaded) modules in the same directory. The indirect
        // caching is required to allow cache invalidation without changing the old
        // cache key names.
        relResolveCacheIdentifier = `${parent.path}\x00${request}`;
        const filename = relativeResolveCache[relResolveCacheIdentifier];
        if (filename !== undefined) {
            const cachedModule = Module._cache[filename];
            if (cachedModule !== undefined) {
                updateChildren(parent, cachedModule, true);
                return cachedModule.exports;
            }
            delete relativeResolveCache[relResolveCacheIdentifier];
        }
    }
    const filename = Module._resolveFilename(request, parent, isMain);
    const cachedModule = Module._cache[filename];
    if (cachedModule !== undefined) {
        updateChildren(parent, cachedModule, true);
        return cachedModule.exports;
    }
    const mod = loadNativeModule(filename, request, experimentalModules);
    if (mod && mod.canBeRequiredByUsers) return mod.exports;
    // Don't call updateChildren(), Module constructor already does.
    const module = new Module(filename, parent);
    if (isMain) {
        process.mainModule = module;
        module.id = '.';
    }
    Module._cache[filename] = module;
    if (parent !== undefined) {
        relativeResolveCache[relResolveCacheIdentifier] = filename;
    }
    let threw = true;
    try {
        module.load(filename);
        threw = false;
    } finally {
        if (threw) {
            delete Module._cache[filename];
            if (parent !== undefined) {
                delete relativeResolveCache[relResolveCacheIdentifier];
            }
        }
    }
    return module.exports;
};

我們可以先簡(jiǎn)單的看一下源代碼，其實(shí)代碼注釋已經(jīng)寫(xiě)得很清楚了。

Nodejs 先會(huì)根據(jù)模塊信息解析出文件路徑和文件名，然后以文件名作為 Module._cache 對(duì)象的鍵查詢?cè)撐募欠褚呀?jīng)被緩存，如果已經(jīng)被緩存的話，直接返回緩存對(duì)象的 exports 屬性。否則就會(huì)使用 Module._resolveFilename 重新解析文件名，再查詢一邊緩存對(duì)象。否則就會(huì)當(dāng)做核心模塊來(lái)加載，核心模塊使用 loadNativeModule 方法進(jìn)行加載。

如果經(jīng)過(guò)了以上幾個(gè)步驟之后，在緩存中仍然找不到 require 加載的模塊對(duì)象，那么就使用 Module 構(gòu)造方法重新構(gòu)造一個(gè)新的模塊對(duì)象。加載完畢之后還會(huì)緩存到 Module._cache 對(duì)象中，以便下一次加載的時(shí)候可以直接從緩存中取到。

從源碼來(lái)看，跟我們之前說(shuō)的沒(méi)什么區(qū)別。

2.2 路徑分析

我們知道標(biāo)識(shí)符是進(jìn)行路徑分析和文件定位的依據(jù)，在引用某個(gè)模塊的時(shí)候我們就會(huì)給 require 函數(shù)傳入一個(gè)標(biāo)識(shí)符，根據(jù)我們使用的經(jīng)歷不難發(fā)現(xiàn)標(biāo)識(shí)符基本上可以分為以下幾種：

• 核心模塊：比如 http、fs 等
• 文件模塊：這類模塊的標(biāo)識(shí)符是一個(gè)路徑字符串，指向工程內(nèi)的某個(gè)文件
• 非路徑形式的文件模塊：也叫做自定義模塊，比如 connect、koa 等

標(biāo)識(shí)符類型不同，加載的方式也有差異，接下來(lái)我將介紹不同標(biāo)識(shí)符的加載方式。

2.2.1 核心模塊

核心模塊的加載優(yōu)先級(jí)僅次于緩存，前文提到過(guò)由于核心模塊的代碼已經(jīng)編譯成了二進(jìn)制代碼，在 Nodejs 啟動(dòng)的時(shí)候就會(huì)加載到內(nèi)存中，所以核心模塊的加載速度非常快。它根本不需要進(jìn)行路徑分析和文件定位，如果你想寫(xiě)一個(gè)和核心模塊同名的模塊的話，它是不會(huì)被加載的，因?yàn)槠浼虞d優(yōu)先級(jí)不如核心模塊。

2.2.2 路徑形式的文件模塊

當(dāng)標(biāo)識(shí)符為路徑字符串時(shí)，require 都會(huì)把它當(dāng)做文件模塊來(lái)加載，在根據(jù)標(biāo)識(shí)符獲得真實(shí)路徑之后，Nodejs 會(huì)將真實(shí)路徑作為鍵把模塊緩存到一個(gè)對(duì)象里，使二次加載更快。

由于文件模塊的標(biāo)識(shí)符指明了模塊文件的具體位置，所以加載速度相對(duì)而言也比較快。

2.2.3 自定義模塊

自定義模塊是一個(gè)包含 package.json 的項(xiàng)目所構(gòu)造的模塊，它是一種特殊的模塊，其查找方式比較復(fù)雜，所以耗時(shí)也是最長(zhǎng)的。

在 Nodejs 中有一個(gè)叫做模塊路徑的概念，我們新建一個(gè) module_path.js 的文件，然后在其中輸入如下內(nèi)容：

console.log(module.paths)

然后使用 Nodejs 運(yùn)行：

node module_path.js

我們可以看到控制臺(tái)輸入大致如下：

[ 'C:\\Users\\UserName\\Desktop\\node_modules',  'C:\\Users\\UserName\\node_modules',  'C:\\Users\\node_modules',  'C:\\node_modules' ]

此時(shí)我的 module_path.js 文件是放在桌面的，所以可以看到這個(gè)文件模塊的模塊路徑是當(dāng)前文件同級(jí)目錄下的 node_modules，如果找不到的話就從父級(jí)文件夾的同名目錄下找，知道找到根目錄下。這種查找方式和 JavaScript 中的作用域鏈非常相似?？梢钥吹疆?dāng)文件路徑越深的時(shí)候查找所耗時(shí)間越長(zhǎng)，所以這也是自定義模塊加載速度最慢的原因。

在 Windows 環(huán)境中，Nodejs 通過(guò)下面函數(shù)獲取模塊路徑：

Module._nodeModulePaths = function(from) {
    // Guarantee that 'from' is absolute.
    from = path.resolve(from);
    // note: this approach *only* works when the path is guaranteed
    // to be absolute.  Doing a fully-edge-case-correct path.split
    // that works on both Windows and Posix is non-trivial.
    // return root node_modules when path is 'D:\\'.
    // path.resolve will make sure from.length >=3 in Windows.
    if (from.charCodeAt(from.length - 1) === CHAR_BACKWARD_SLASH &&
        from.charCodeAt(from.length - 2) === CHAR_COLON)
        return [from + 'node_modules'];
    const paths = [];
    var p = 0;
    var last = from.length;
    for (var i = from.length - 1; i >= 0; --i) {
        const code = from.charCodeAt(i);
        // The path segment separator check ('\' and '/') was used to get
        // node_modules path for every path segment.
        // Use colon as an extra condition since we can get node_modules
        // path for drive root like 'C:\node_modules' and don't need to
        // parse drive name.
        if (code === CHAR_BACKWARD_SLASH ||
            code === CHAR_FORWARD_SLASH ||
            code === CHAR_COLON) {
            if (p !== nmLen)
                paths.push(from.slice(0, last) + '\\node_modules');
            last = i;
            p = 0;
        } else if (p !== -1) {
            if (nmChars[p] === code) {
                ++p;
            } else {
                p = -1;
            }
        }
    }
    return paths;
};

代碼和注釋都寫(xiě)得很明白，大家看看就行，常量都放在 /lib/internal/constants.js 這個(gè)模塊。

2.3 文件定位

2.3.1 文件擴(kuò)展名分析

我們?cè)谝媚K的很多時(shí)候，傳遞的標(biāo)識(shí)符都不會(huì)攜帶擴(kuò)展名，比如

// require('./internal/constants.js')
require('./internal/constants')

很明顯下面的方式更簡(jiǎn)潔，但是 Nodejs 在定位文件的時(shí)候還是會(huì)幫我們補(bǔ)齊。補(bǔ)齊的順序依次為：.js、.json 和 .node，在補(bǔ)齊的時(shí)候 Nodejs 會(huì)依次進(jìn)行嘗試。在嘗試的時(shí)候 Nodejs 會(huì)調(diào)用 fs 模塊來(lái)判斷文件是否存在，所以這里可能會(huì)存在性能問(wèn)題，如果在引用模塊的時(shí)候加上擴(kuò)展名，可以使得模塊加載的速度變得更快。

在 Nodejs 源碼 中，我們可以看到當(dāng)解析不到文件名的時(shí)候，會(huì)嘗試使用 tryExtensions 方法來(lái)添加擴(kuò)展名：

if (!filename) {
    // Try it with each of the extensions
    if (exts === undefined)
        exts = Object.keys(Module._extensions);
    filename = tryExtensions(basePath, exts, isMain);
}

而嘗試的擴(kuò)展名就是 Module._extensions 的鍵值，檢索代碼不難發(fā)現(xiàn)代碼中依次定義了 .js、.json、.node、.mjs 等鍵，所以 tryExtensions 函數(shù)會(huì)依次進(jìn)行嘗試：

// Given a path, check if the file exists with any of the set extensions
function tryExtensions(p, exts, isMain) {
    for (var i = 0; i < exts.length; i++) {
        const filename = tryFile(p + exts[i], isMain);
        if (filename) {
            return filename;
        }
    }
    return false;
}

其中又調(diào)用了 tryFile 方法：

function tryFile(requestPath, isMain) {
    const rc = stat(requestPath);
    if (preserveSymlinks && !isMain) {
        return rc === 0 && path.resolve(requestPath);
    }
    return rc === 0 && toRealPath(requestPath);
}
// Check if the file exists and is not a directory
// if using --preserve-symlinks and isMain is false,
// keep symlinks intact, otherwise resolve to the
// absolute realpath.
function tryFile(requestPath, isMain) {
    const rc = stat(requestPath);
    if (preserveSymlinks && !isMain) {
        return rc === 0 && path.resolve(requestPath);
    }
    return rc === 0 && toRealPath(requestPath);
}
// 這個(gè)函數(shù)在其他地方還有用到，比較重要
function toRealPath(requestPath) {
    return fs.realpathSync(requestPath, {
        [internalFS.realpathCacheKey]: realpathCache
    });
}

可以看到最終還是依賴了 fs.realpathSync 方法，所以這里就跟之前說(shuō)的是一樣的，可能會(huì)存在性能問(wèn)題，如果我們直接帶上了擴(kuò)展名的話，直接就可以解析出 filename，就不會(huì)去嘗試擴(kuò)展名了，這樣可以稍微提高一點(diǎn)加載速度。

2.3.2 目錄和包分析

我們寫(xiě)的文件模塊可能是一個(gè) npm 包，此時(shí)包內(nèi)包含許多 js 文件，所以 Nodejs 加載的時(shí)候又需要定位文件。Nodejs 會(huì)查找 package.json 文件，使用 JSON.stringify 來(lái)解析 json，隨后取出其 main 字段之后對(duì)文件進(jìn)行定位，如果文件名缺少擴(kuò)展的話，也會(huì)進(jìn)入擴(kuò)展名嘗試環(huán)節(jié)。

如果 main 字段指定的文件名有誤，或者壓根沒(méi)有 package.json 文件，那么 Nodejs 會(huì)將 index 當(dāng)做默認(rèn)文件名，隨后開(kāi)始嘗試擴(kuò)展名。

2.4 模塊編譯

Nodejs 中每一個(gè)模塊就是一個(gè) Module類實(shí)例，Module 的構(gòu)造函數(shù)如下：

function Module(id = '', parent) {
    this.id = id;
    this.path = path.dirname(id);
    this.exports = {};
    this.parent = parent;
    updateChildren(parent, this, false);
    this.filename = null;
    this.loaded = false;
    this.children = [];
}

編譯和執(zhí)行是引入文件模塊的最后一個(gè)環(huán)節(jié)，定位到具體文件后，Nodejs 會(huì)新建一個(gè)模塊對(duì)象，然后根據(jù)路徑載入緩存以后進(jìn)行編譯，擴(kuò)展名不同，編譯的方式也不同，它們的編譯方法都注冊(cè)在了 Module._extensions 對(duì)象上，前文有提到過(guò)：

• .js 文件：通過(guò)同步讀取文件內(nèi)容后編譯執(zhí)行
• .json 文件：通過(guò) fs 模塊讀取文件，之后使用 JSON.parse 轉(zhuǎn)化成 JS 對(duì)象
• .node 文件：這是使用 C/C++ 編寫(xiě)的擴(kuò)展模塊，通過(guò)內(nèi)置的 dlopen 方法加載最后編譯生成的文件
• .mjs 文件：這是 Nodejs 支持 ESM 加載方式的模塊文件，所以使用 require 方法載入的時(shí)候會(huì)直接拋出錯(cuò)誤

在 Nodejs 的 輔助函數(shù)模塊 中，通過(guò)以下代碼把 Module._extensions 傳遞給了 require 函數(shù)：

// Enable support to add extra extension types.require.extensions = Module._extensions;

所以我們可以通過(guò)在模塊中打印 require.extensions 查看當(dāng)前 Nodejs 能夠解析的模塊：

console.log(require.extensions)
// { '.js': [Function], '.json': [Function], '.node': [Function] }

另外我們可以看到上面第二段代碼中的注釋：Enable support to add extra extension types，也就是說(shuō)我們可以通過(guò)修改 require.extensions 對(duì)象來(lái)注冊(cè)模塊的解析方法。

比如我們有一個(gè) .csv 文件，我們想把它解析成一個(gè)二維數(shù)組，那么我們就可以寫(xiě)一下方法注冊(cè)：

const fs = require('fs')
// 注冊(cè)解析方法到 require.extensions 對(duì)象
require.extensions['.csv'] = function(module, filename) {
    // module 是當(dāng)前模塊的 Module 實(shí)例，filename 是當(dāng)前文件模塊的路徑
    const content = fs.readFileSync(filename, 'utf8'),
          lines = content.split(/\r\n/)
    const res = lines.map(line => line.split(','))
    // 注意導(dǎo)出是通過(guò)給 module.exports 賦值，而不是用 return
    module.exports = res
}
/*
*    demo.csv 的內(nèi)容為：
*    1,2,3
*    2,3,4
*    5,6,7
*/
const arr = require('./demo.csv')
console.log(arr)
// output
// [ [ '1', '2', '3' ], [ '2', '3', '4' ], [ '5', '6', '7' ] ]

但是在 v0.10.6 開(kāi)始 Nodejs 就不再推薦使用這種方式來(lái)擴(kuò)展加載方式了，而是期望現(xiàn)將其他語(yǔ)言轉(zhuǎn)化為 JavaScript 以后再加載執(zhí)行，這樣就避免了將復(fù)雜的編譯加載過(guò)程引入到 Nodejs 的執(zhí)行過(guò)程。

接下來(lái)我們了解一下 Nodejs 內(nèi)置的幾種模塊的加載方式。

2.4.1 JavaScript 模塊的編譯

在我們編寫(xiě) Nodejs 模塊的時(shí)候我們可以隨意的使用 require、module、module、__dirname 和 __filename 等變量，仿佛它們都是 Nodejs 內(nèi)置的全局變量一樣，但是實(shí)際上他們都是局部變量。在 Nodejs 加載 JavaScript 模塊的時(shí)候，會(huì)自動(dòng)將模塊內(nèi)的所有代碼包裹到一個(gè)匿名函數(shù)內(nèi)，構(gòu)成一個(gè)局部作用域，順便把 require……等變量傳入了匿名函數(shù)內(nèi)部，所以我們的代碼可以隨意使用這些變量。

假設(shè)我們的模塊代碼如下：

exports.add = (a, b) => a + b

經(jīng)過(guò) Nodejs 加載之后，代碼變成了下面這樣：

(function(exports, require, module, __filename, __dirname) {
    exports.add = (a, b) => a + b
})

這樣看起來(lái)的話，一切都變得很順其自然了。這也是為什么每個(gè)模塊都是獨(dú)立的命名空間，在模塊文件內(nèi)隨便命名變量而不用擔(dān)心全局變量污染，因?yàn)檫@些變量都定義在了函數(shù)內(nèi)部，成為了這個(gè)包裹函數(shù)的私有變量。

弄明白 Nodejs 加載 JavaScript 的原理之后，我們很容易就可以弄明白為什么不能給 exports 直接賦值了，根本原因就在于 JavaScript 是一門(mén)按值傳遞（Pass-by-Value）的語(yǔ)言，不管我們給變量賦值的是引用類型還是原始類型，我們得到變量得到的都是一個(gè)值，只不過(guò)賦值引用類型時(shí)，變量得到的是一個(gè)代表存儲(chǔ)引用類型的內(nèi)存地址值（可以理解為指針），而我們使用變量時(shí) JavaScript 會(huì)根據(jù)這個(gè)值去內(nèi)存中找到對(duì)應(yīng)的引用類型值，所以看起來(lái)也像是引用傳遞。而一旦我們給 exports 這種變量重新賦值的時(shí)候，exports 就失去了對(duì)原來(lái)引用類型的指向，轉(zhuǎn)而指向新的值，所以就會(huì)導(dǎo)致我們賦給 exports 的值并沒(méi)有指向原來(lái)的引用類型對(duì)象。

看看下面這段代碼：

function changeRef(obj) {
    obj = 12
}
const ref = {}
changeRef(ref)
console.log(ref) // {}

可以看到函數(shù)內(nèi)對(duì) obj 重新賦值根本不影響函數(shù)外部的 ref對(duì)象，所以如果我們?cè)谀K內(nèi)（及包裹函數(shù)內(nèi)）修改 exports 的指向的話，外部的 module.exports 對(duì)象根本不受影響，我們導(dǎo)出的操作也就失敗了。

下面我們稍微看一下 Nodejs 源碼是如何編譯執(zhí)行 JavaScript 代碼的。

首先根據(jù) Module._extensions 對(duì)象上注冊(cè)的 .js 模塊加載方法找到入口：

// Native extension for .js
Module._extensions['.js'] = function(module, filename) {
    const content = fs.readFileSync(filename, 'utf8');
    module._compile(content, filename);
};

可以看到加載方法聽(tīng)過(guò) fs.readFileSync 方法同步讀取了 .js 的文件內(nèi)容之后，就把內(nèi)容交給 module 的 _compile 方法去處理了，這個(gè)方法位于 Module 類的原型上，我們繼續(xù)找到 Module.prototype._compile 方法：

// Run the file contents in the correct scope or sandbox. Expose
// the correct helper variables (require, module, exports) to
// the file.
// Returns exception, if any.Module.prototype._compile = function(content, filename) {
    let moduleURL;
    let redirects;
    if (manifest) {
        moduleURL = pathToFileURL(filename);
        redirects = manifest.getRedirects(moduleURL);
        manifest.assertIntegrity(moduleURL, content);
    }
    const compiledWrapper = wrapSafe(filename, content);
    var inspectorWrapper = null;
    if (getOptionValue('--inspect-brk') && process._eval == null) {
        if (!resolvedArgv) {
            // We enter the repl if we're not given a filename argument.
            if (process.argv[1]) {
                resolvedArgv = Module._resolveFilename(process.argv[1], null, false);
            } else {
                resolvedArgv = 'repl';
            }
        }
        // Set breakpoint on module start
        if (!hasPausedEntry && filename === resolvedArgv) {
            hasPausedEntry = true;
            inspectorWrapper = internalBinding('inspector').callAndPauseOnStart;
        }
    }
    const dirname = path.dirname(filename);
    const require = makeRequireFunction(this, redirects);
    var result;
    const exports = this.exports;
    const thisValue = exports;
    const module = this;
    if (requireDepth === 0) statCache = new Map();
    if (inspectorWrapper) {
        result = inspectorWrapper(compiledWrapper, thisValue, exports,
                                  require, module, filename, dirname);
    } else {
        result = compiledWrapper.call(thisValue, exports, require, module,
                                      filename, dirname);
    }
    if (requireDepth === 0) statCache = null;
    return result;
};

可以看到最后還是交給了 compiledWrapper 方法來(lái)處理模塊內(nèi)容（inspectWrapper 是做斷電調(diào)試用的，咱們可以不管它），繼續(xù)看 compiledWrapper 方法。

compiledWrapper 方法來(lái)源于 wrapSafe 的執(zhí)行結(jié)果：

const compiledWrapper = wrapSafe(filename, content);

而 wrapSafe 函數(shù)的定義如下：

function wrapSafe(filename, content) {
    if (patched) {
        const wrapper = Module.wrap(content);
        return vm.runInThisContext(wrapper, {
            filename,
            lineOffset: 0,
            displayErrors: true,
            importModuleDynamically: experimentalModules ? async (specifier) => {
                const loader = await asyncESM.loaderPromise;
                return loader.import(specifier, normalizeReferrerURL(filename));
            } : undefined,
        });
    }
    const compiled = compileFunction(
        content,
        filename,
        0,
        0,
        undefined,
        false,
        undefined,
        [],
        [
            'exports',
            'require',
            'module',
            '__filename',
            '__dirname',
        ]
    );
    if (experimentalModules) {
        const { callbackMap } = internalBinding('module_wrap');
        callbackMap.set(compiled.cacheKey, {
            importModuleDynamically: async (specifier) => {
                const loader = await asyncESM.loaderPromise;
                return loader.import(specifier, normalizeReferrerURL(filename));
            }
        });
    }
    return compiled.function;
}
// Module.wrap
// eslint-disable-next-line func-style
let wrap = function(script) {
    return Module.wrapper[0] + script + Module.wrapper[1];
};
const wrapper = [
    '(function (exports, require, module, __filename, __dirname) { ',
    '\n});'
];
Object.defineProperty(Module, 'wrap', {
    get() {
        return wrap;
    },
    set(value) {
        patched = true;
        wrap = value;
    }
});

上面這段代碼可以看到 wrapSafe 方法通過(guò) Module.wrap 將模塊代碼構(gòu)造成了一個(gè)匿名函數(shù)，隨后扔給了 vm.runInThisContext 或者 compileFunction 去執(zhí)行，這兩函數(shù)都開(kāi)始涉及到 JavaScript 跟 C/C++ 的底層了，作者水平渣渣，不再進(jìn)行下一步解讀，感興趣的童鞋可以自己找到源碼繼續(xù)閱讀。

2.4.2 C/C++ 模塊的編譯

Nodejs 通過(guò)調(diào)用 process.dlopen 加載和執(zhí)行 C/C++ 模塊，該函數(shù)在 Window 和 *nix 系統(tǒng)下有不同的實(shí)現(xiàn)，通過(guò) linuv 兼容層進(jìn)行了封裝。

實(shí)際上 .node 模塊不需要編譯，因?yàn)槭歉鶕?jù) C/C++ 編譯而成的，所以只有加載和執(zhí)行過(guò)程。編寫(xiě) C/C++ 模塊能夠提高 Nodejs 的擴(kuò)展能力和計(jì)算能力，我們知道 Nodejs 是單線程異步無(wú)阻塞的語(yǔ)言，優(yōu)勢(shì)在于 IO 密集型場(chǎng)景而非計(jì)算密集型場(chǎng)景。當(dāng)我們有大量的計(jì)算操作需要執(zhí)行時(shí)，我們可以將計(jì)算操作放到 C/C++ 模塊中執(zhí)行，這樣可以提升 Nodejs 在計(jì)算密集型場(chǎng)景下的表現(xiàn)。但是 C/C++ 的編程門(mén)檻比 Nodejs 高很多，所以這也是一大缺點(diǎn)。

Nodejs 在 v10.x 中引入了 Worker Threads 特性，并且這一特性在 v12.x 中開(kāi)始默認(rèn)啟用，大大提高了 Nodejs 在計(jì)算密集型場(chǎng)景下的表現(xiàn)，在某種程度上減少了開(kāi)發(fā)者所需要編寫(xiě)的 C/C++ 代碼量。

2.4.3 JSON 文件的編譯

JSON 文件的編譯是最簡(jiǎn)單的，通過(guò) fs.readFileSync 讀取文件內(nèi)容后，調(diào)用 JSON.parse 轉(zhuǎn)化成 JavaScript 對(duì)象導(dǎo)出就行了。

由于作者水平有限，關(guān)于核心模塊以及 C/C++ 模塊的書(shū)寫(xiě)和編譯不再講解。

三、總結(jié)

通過(guò)這篇文章，我們至少學(xué)習(xí)到了以下幾點(diǎn)：

CommonJS 模塊化規(guī)范的基本內(nèi)容

CommonJS 規(guī)范主要包括 模塊引用、模塊定義 和 模塊標(biāo)識(shí)，規(guī)定了一個(gè)模塊從引入到消費(fèi)以及導(dǎo)出的整個(gè)過(guò)程。通過(guò)給 require 方法傳遞模塊標(biāo)識(shí)符（路徑字符串或者模塊名稱）來(lái)引入 CJS 模塊，導(dǎo)出時(shí)給 module.exports 或者 exports 賦值或者添加屬性即可。

Nodejs 引入模塊的加載順序和基本步驟

1、加載順序和速度：

require 函數(shù)接收到模塊標(biāo)識(shí)符時(shí)，會(huì)優(yōu)先檢查內(nèi)存中是否已經(jīng)有緩存的模塊對(duì)象，有的話直接返回，沒(méi)有就繼續(xù)查找。所以緩存的加載優(yōu)先級(jí)和加載速度是最高的，其次是核心模塊，因?yàn)楹诵哪K已經(jīng)被編譯到了 Nodejs 代碼中，Nodejs 啟動(dòng)的時(shí)候就已經(jīng)把核心模塊的內(nèi)容加載到了內(nèi)存中，所以核心模塊的加載順序和加載速度位于第二，僅次于內(nèi)存。然后就是文件模塊，Nodejs 通過(guò)找到文件然后使用對(duì)應(yīng)的方法加載文件中的代碼并執(zhí)行。最后才是自定義模塊。

2、加載基本步驟：

加載步驟大概有路徑分析、文件定位和編譯執(zhí)行三個(gè)過(guò)程。

Nodejs 在拿到模塊標(biāo)識(shí)符之后，會(huì)進(jìn)行路徑分析，獲得了入口文件的絕對(duì)路徑之后就會(huì)去內(nèi)存檢索，如果內(nèi)存中沒(méi)有緩存的話就會(huì)進(jìn)入下一步，進(jìn)行文件定位。注意自定義模塊會(huì)有個(gè) 模塊路徑 的概念，加載自定義模塊時(shí)會(huì)首先在當(dāng)前文件的同級(jí) node_modules 目錄下查找，如果沒(méi)有找到的話就向上一級(jí)繼續(xù)查找 node_modules，直到系統(tǒng)根目錄（Windows 的盤(pán)符目錄，比如 C:\ 或者 *nix 的根目錄 /），所以自定義模塊的加載耗時(shí)最長(zhǎng)。

路徑分析之后會(huì)進(jìn)行文件定位，嘗試多種不同的擴(kuò)展名然后判斷文件是否存在，如果最終都不存在的話就會(huì)繼續(xù)把這個(gè)模塊當(dāng)做自定義模塊進(jìn)行加載，如果還是找不到就直接報(bào)錯(cuò)。擴(kuò)展判斷的順序依次為 .js、.json 和 .node。

Nodejs 對(duì)于不同模塊的編譯方式

• JavaScript 模塊通過(guò)包裹函數(shù)包裹之后交給系統(tǒng)函數(shù)運(yùn)行
• JSON 模塊通過(guò) JSON.parse 轉(zhuǎn)化為 JavaScript 對(duì)象然后返回結(jié)果
• C/C++ 模塊通過(guò)系統(tǒng)級(jí)的 process.dlopen 函數(shù)加載執(zhí)行

以上就是Nodejs 模塊化實(shí)現(xiàn)示例深入探究的詳細(xì)內(nèi)容，更多關(guān)于Nodejs 模塊化的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！