原諒我標題黨 其實也沒有非常深入底層
在了解NodeJS模塊之前 首先來科普一下什么是CommonJS
它為javaScript制定一套規范——希望Javascript能在任何地方運行 使其具備開發大型應用的能力
出發點便是為了彌補當時JavaScript語言自身的缺點：
無模塊系統 現在ES6彌補了這個缺點沒有包管理胸痛 導致js應用沒有自加載和安裝依賴能力無標準接口 沒有定義過像Web服務器一類的標準統一接口標準庫太少 僅有部分核心庫，文件系統等常見需求沒有標準API；H5推進了這個過程，但也只是瀏覽器端CommonJS-API寫出的應用可以跨宿主環境 這樣JavaScript就不僅僅只是停留在客戶端，他還可以開發：
服務器端JS應用命令行工具桌面圖形界面應用程序混合應用（原生應用內嵌瀏覽器）CommonJS涵蓋一下內容
模塊I/O流二進制緩沖區套接字進程環境文件系統單元測試字符集編碼Web服務器網關接口包管理……為什么要介紹CommonJS 因為Node簡單易用的模塊系統就是借鑒了CommonJS的Modules規范 CommonJS模塊分為三部分：模塊引用、模塊定義、模塊標識
Node中，一個文件就是一個模塊 模塊中使用exports導出當前模塊的變量或函數 下面我就建立一個tool.js的工具模塊 并且通過exports導出
//tool.jsvar add = function add(a, b){ return a + b;}exPRots.add = add;導出給外部的對象 就擁有一個add方法
不過要特別注意 如果直接給exports賦值為一個基本類型值不會成功 比如我們只是想單純的導出一個數字（雖然不會這么用）
exports = 123;是完全不能夠導出的 至于為什么下面再說
我們一般不會直接通過exports這么用 在我們模塊的上下文中，還有一個module對象，引用我們模塊自身 而這個exports對象便是module上的屬性 我們通常的做法就是通過 module.exprots 導出
模塊引用很簡單 只需調用require()方法，接收一個模塊標識字符串作為參數 如此引入一個模塊到我們當前的環境中
var tool = require('./tool');我們調用起來倒是輕松愉快 其實內部發生了日異月殊的變化（下面再說）
引入之后，我們就能調用內部的API了
tool.add(1, 2); //3模塊標識就是我們傳遞給require()的那個字符串參數 這個字符串是符合小駝峰命名的字符串 或者是 . / .. 開頭的相對路徑，再或者絕對路徑 如果要引入的模塊后綴為 .js / .json / .node 可以省略
這種模塊機制導入容易，導出也容易 把類聚的方法和變量限定在私有作用域內 模塊之間空間獨立、互不干擾，好處不言而喻 媽媽再也不用擔心我們變量污染了
NodeJS在CommonJS模塊規范基礎上作出了改動 在了解NodeJS模塊原理之前 先來了解一下NodeJS的模塊緩存機制
NodeJS為了提高性能，我們引入模塊后，它都會進行緩存 這和我們在瀏覽器端的很像 但是瀏覽器緩存的是文件 而Node緩存編譯執行后的對象 我們可以做一個實驗
//increase.jsvar a = 0;var increase = function(){ ++a;}//index.jsvar increase = require('./increase');console.log(increase());console.log(increase());var add = require('./tool');console.log(increase());console.log(increase());
實驗的結果返回了 1 2 3 4 而不是 1 2 1 2 這就證明二次引用時實際引用了緩存的對象（編譯執行后的模塊）
所以當我們調用require( )方法時 Node會優先查看緩存（第一優先級），沒有緩存再進行一系列過程 這一系列過程就是：
路徑分析文件定位編譯執行了解這些過程前 我們還要知道模塊分類
模塊大體上分兩種，它們還可以細分
核心模塊：Node提供的模塊 JavaScript核心模塊C/C++核心模塊文件模塊：用戶編寫的模塊 本地模塊：本地編寫模塊第三方模塊：從第三方下載的模塊核心模塊在Node源碼編譯過程中，編譯進二進制執行文件 Node啟動，部分核心模塊被直接加載進內存 所以文件定位和編譯執行階段可省略，并且優先判斷路徑分析（加載最快）
文件模塊運行時動態加載，速度稍慢
路徑分析的優先級如下：
緩存加載核心模塊加載文件模塊加載如果引入的是核心模塊，就直接填寫模塊名字符串就可以了
var http = require('http');如果引入的是文件模塊，就會根據填入的路徑來定位文件
var tool = require('./tool');我們下載的第三方模塊會存在于node_modules的文件夾 在分析它的時候 就會查找當前目錄下的node_modules中有沒有該文件 如果沒找到，就會查找父級目錄下有沒有node_modules并查找 以此類推 引用第三方模塊同樣不必輸入路徑
var react = require('react');require()分析標識符的時候，可能會出現省略文件擴展名的情況 此時，Node會按照 .js / .json / .node 的順序依次嘗試 很顯然這有一點兒性能問題，嘗試也需要時間 所以我們最好給 .json 和 .node 形式的文件添加擴展名
如果我們定位到的是一個文件夾 Node會把它當做一個包來處理 根據包內部的package.json文件的main屬性繼續定位入口文件
關于包的概念，這里不講 可以暫時把它理解為擁有package.json配置文件的一個文件夾
文件格式不同，載入方法也不同
.js文件：通過fs核心模塊同步讀取后編譯執行.node文件：C/C++擴展文件，通過dlopen()加載最后編譯生成的文件.json文件：通過fs核心模塊同步讀取后利用JSON.parse()解析其他：均當做.js文件處理這里我只說一下JavaScript文件模塊的編譯 大家一定很奇怪一個問題 我們的文件中根本沒有什么exports，沒有什么require，它們從哪兒來的? 答案就在這里 就拿我們上面的模塊為例
//increase.jsvar a = 0;var increase = function(){ ++a;}在這個編譯過程中，Node實際上對JS文件進行了包裝 加上了“龍頭鳳尾”（致敬兒時玩的四驅車） 龍頭：(function(exports, require, module, __filename, __dirname){/n 鳳尾：/n}）; 封裝后的文件變成了這樣
這回我們就可以理解為什么直接給exports賦基本類型值不可以 因為exports實際上作為形參傳入 賦值僅僅只是改變了形參
包裝后的代碼通過原生vm模塊的runInThisContext()執行（類似eval） 返回一個函數 最后將當前模塊的exports屬性、require方法等等傳入這個函數執行
==主頁傳送門==
新聞熱點
疑難解答
