require.js 禁用緩存

每次發(fā)版用戶都要清除頁(yè)面緩存

Require.js 模塊緩存：Require.js 內(nèi)部有一個(gè)簡(jiǎn)單的模塊緩存機(jī)制。當(dāng)通過(guò) require 加載模塊時(shí)，Require.js 會(huì)檢查該模塊是否已經(jīng)緩存。如果已經(jīng)緩存，Require.js 將直接返回緩存的模塊，而不會(huì)再次加載。這樣可以避免重復(fù)加載相同的模塊，提高性能。

有時(shí)候我們禁用緩存，以便及時(shí)看到最新的修改。在這種情況下，可以通過(guò)給 Require.js 的配置對(duì)象添加一個(gè)隨機(jī)的查詢參數(shù)來(lái)防止緩存。例如：

require.config({
 urlArgs: "bust=" + (new Date()).getTime()
});

require(["module"], function(module) {
  // 模塊邏輯
});

這會(huì)在每次加載模塊時(shí)，給腳本的 URL 添加一個(gè)不同的時(shí)間戳參數(shù)，迫使瀏覽器重新下載和執(zhí)行模塊文件，以確保獲取最新的代碼。

加時(shí)間戳禁用緩存在生產(chǎn)環(huán)境中不建議使用，因?yàn)樗鼤?huì)增加頁(yè)面加載時(shí)間。只在開發(fā)過(guò)程中使用禁用緩存來(lái)方便調(diào)試和測(cè)試。

我們可以在生產(chǎn)環(huán)境中加個(gè)固定的版本號(hào)

、require 是一個(gè)函數(shù)，同時(shí)還掛載著四個(gè)屬性

require.resolve 解析某個(gè)文件是否存在，存在就返回此文件的絕對(duì)路徑，否則會(huì)報(bào)錯(cuò)
require.main 當(dāng)前所在文件的模塊信息
require.extensions 對(duì)象存放著能解析的文件類型，有 .js、.json、.node 三種類型
require.cache 對(duì)象存放著已經(jīng)緩存的模塊（一個(gè)文件絕對(duì)路徑為鍵名，記載著這個(gè)文件的信息）

2、require 函數(shù)的參數(shù)說(shuō)明

只有一個(gè)參數(shù)
參數(shù)類型都是字符串
參數(shù)可以是：
模塊（原生內(nèi)置fs/http/path/https等、第三方包模塊express、koa等等）
路徑+文件基礎(chǔ)名（./express 當(dāng)前路徑、../express 上級(jí)路徑、/express 絕對(duì)路徑）
路徑+文件基礎(chǔ)名+文件擴(kuò)展名（./express.js 當(dāng)前路徑、../express.json 上級(jí)路徑、/express.node 絕對(duì)路徑）

3、reqiure 調(diào)用的時(shí)候

- 如果引用的是 .js 文件
  - fs模塊同步讀取文件
  - 包裝fs模塊同步讀取的內(nèi)容
  - 調(diào)用 vm 的 runInThisContext 方法 將 包裝字符串 解析為 javascript
  - 調(diào)用匿名函數(shù)，并傳參，最后返回 module.exports 的賦值。

- 如果引用的是 .json 文件
  - 經(jīng)過(guò)fs模塊同步讀取文件以后用 JSON.parse() 解析返回結(jié)果。

- 如果引用的是 .node 文件
  - 則經(jīng)過(guò) dlopen()方法加載最后編譯生成的對(duì)象，并且返回結(jié)果。

4、require 加載規(guī)則

加載規(guī)則參考地址：

 https://www.jianshu.com/p/a309864c8357
 https://blog.csdn.net/u010476739/article/details/80925128
 https://www.cnblogs.com/zhoulixue/p/8757546.html
 http://www.javashuo.com/article/p-bywkbpzj-d.html
 https://juejin.cn/post/6844903704123211783

加載的模塊類型：

 1、原生內(nèi)置模塊
     存在:原生內(nèi)置模塊緩沖區(qū)中，直接返回緩存結(jié)果，不執(zhí)行原生內(nèi)置模塊代碼
     不存在:原生內(nèi)置模塊緩沖區(qū)中，執(zhí)行原生內(nèi)置模塊代碼，把模塊加入緩沖區(qū)，并返回執(zhí)行結(jié)果

 2、路徑文件模塊
 
     (1)、構(gòu)建文件絕對(duì)路徑列表
         存在后綴名（.js | .json | .node）
             使用path.resolve("路徑") 拼接一個(gè)絕對(duì)路徑，推入文件絕對(duì)路徑列表
         不存在后綴名
             使用 path.resolve("路徑"+".js") 拼接一個(gè)絕對(duì)路徑的 .js 文件，推入文件絕對(duì)路徑列表
             使用 path.resolve("路徑"+".json") 拼接一個(gè)絕對(duì)路徑的 .json 文件，推入文件絕對(duì)路徑列表
             使用 path.resolve("路徑"+".node") 拼接一個(gè)絕對(duì)路徑的 .node 文件，推入文件絕對(duì)路徑列表
             是否存在 path.resolve("路徑") 目錄
                 存在
                     是否存在package.json文件
                         存在
                             是否存在main屬性（若main沒(méi)指定后綴名，那會(huì)使用 .js | .json | .node，按照順序查找）
                                 存在
                                     使用path.resolve(path.jon("路徑",'main屬性值')) 拼接一個(gè)絕對(duì)路徑的文件，推入 文件絕對(duì)路徑列表
                                 不存在
                                     使用path.resolve(path.jon("路徑",'index.js')) 拼接一個(gè)絕對(duì)路徑的 .js 文件，推入 文件絕對(duì)路徑列表
                                     使用path.resolve(path.jon("路徑",'index.json')) 拼接一個(gè)絕對(duì)路徑的 .json 文件，推入 文件絕對(duì)路徑列表
                                     使用path.resolve(path.jon("路徑",'index.node')) 拼接一個(gè)絕對(duì)路徑的 .node 文件，推入 文件絕對(duì)路徑列表
                         不存在
                             使用path.resolve(path.jon("路徑",'index.js')) 拼接一個(gè)絕對(duì)路徑的 .js 文件，推入 文件絕對(duì)路徑列表
                             使用path.resolve(path.jon("路徑",'index.json')) 拼接一個(gè)絕對(duì)路徑的 .json 文件，推入 文件絕對(duì)路徑列表
                             使用path.resolve(path.jon("路徑",'index.node')) 拼接一個(gè)絕對(duì)路徑的 .node 文件，推入 文件絕對(duì)路徑列表
 
     （2）、遍歷文件絕對(duì)路徑列表 ，查看是否在require.cache['文件路徑']緩沖區(qū)中
         存在
             讀取緩沖區(qū)中的模塊，不執(zhí)行文件模塊的代碼，直接返回緩存的結(jié)果（require.cache['文件路徑'].exports）
         不存在
             報(bào)錯(cuò)找不到模塊

 3、第三方包模塊
 
     （1）、獲取模塊可能存在的目錄列表 module.paths 
 
     （2）、構(gòu)建 文件絕對(duì)路徑列表
 
         遍歷 目錄列表 module.paths 第一個(gè)元素
             使用(path.join(目錄元素,包名+".js") 拼接一個(gè)絕對(duì)路徑的 .js 文件，推入 文件絕對(duì)路徑列表
             使用(path.join(目錄元素,包名+".json") 拼接一個(gè)絕對(duì)路徑的 .json 文件，推入 文件絕對(duì)路徑列表
             使用(path.join(目錄元素,包名+".node") 拼接一個(gè)絕對(duì)路徑的 .node 文件，推入 文件絕對(duì)路徑列表
             判斷 path.join(目錄元素,包名) 目錄是否存
                 存在
                     判斷目錄下是否存在package.json文件
                         存在
                             是否存在main屬性
                                 存在
                                     使用 path.jon(目錄元素",包名,'main屬性值')) 拼接一個(gè)絕對(duì)路徑的文件，推入 文件絕對(duì)路徑列表
                                 不存在
                                     使用 path.jon(目錄元素",包名,'index.js')) 拼接一個(gè)絕對(duì)路徑的文件，推入 文件絕對(duì)路徑列表
                                     使用 path.jon(目錄元素",包名,'index.json')) 拼接一個(gè)絕對(duì)路徑的文件，推入 文件絕對(duì)路徑列表
                                     使用 path.jon(目錄元素",包名,'index.node)) 拼接一個(gè)絕對(duì)路徑的文件，推入 文件絕對(duì)路徑列表
                         不存在
                             繼續(xù)遍歷 目錄列表 module.paths
                 不存在
                     繼續(xù)遍歷 目錄列表 module.paths
 
     （3）、遍歷文件絕對(duì)路徑列表，查看是否在require.cache['文件路徑']緩沖區(qū)中
         存在
             讀取緩沖區(qū)中的模塊，不執(zhí)行文件模塊的代碼，直接返回緩存的結(jié)果（require.cache['文件路徑'].exports）
         不存在
             報(bào)錯(cuò)找不到模塊

5、require 3種文件的加載方式

謝 @曉之車在我上一篇分享（模塊化中的import與require及區(qū)別）中的提問(wèn)，我也特定研究了一番，這里是一篇很早的博文，一起來(lái)看下作者的分析

Node.js也使用了CommonJS模塊機(jī)制，最近在InfoQ上有一篇文章討論了這方面的問(wèn)題。這篇文章提到Node.js在載入模塊時(shí)，如果之前該模塊已經(jīng)加載過(guò)則不會(huì)有重復(fù)開銷，因?yàn)槟K加載有緩存機(jī)制。這篇文章是我初審的，當(dāng)時(shí)也正好在思考Jscex在Node.js使用時(shí)的模塊化問(wèn)題，但研究了它的規(guī)則之后，我發(fā)現(xiàn)在某些情況下還是可能加載多次。現(xiàn)在我們便來(lái)分析這個(gè)問(wèn)題。

當(dāng)我們使用require方法加載另一模塊的時(shí)候，Node.js會(huì)去查詢一系列的目錄。我們可以從module.paths中得到這些路徑，例如：

[ '/Users/jeffz/Projects/node-test/node_modules',
  '/Users/jeffz/Projects/node_modules',
  '/Users/jeffz/node_modules',
  '/Users/node_modules',
  '/node_modules']

這里是我在運(yùn)行/User/jeffz/Projects/node-test目錄下一個(gè)模塊時(shí)得到的結(jié)果。可見(jiàn)，Node.js會(huì)從當(dāng)前模塊所在目錄的node_modules（這里怎么不遵守Unix習(xí)慣，而使用了下劃線呢？）開始找起，如果沒(méi)找到再會(huì)去找上級(jí)目錄的node_modules，直到根目錄為止。當(dāng)然，實(shí)際情況下還會(huì)有NODE_PATH環(huán)境變量標(biāo)識(shí)的目錄等等。當(dāng)模塊的位置確定之后，Node.js便會(huì)查看這個(gè)位置的模塊是否已經(jīng)被加載，如果已加載，則直接返回。

簡(jiǎn)單地說(shuō)，Node.js是根據(jù)模塊所在路徑來(lái)緩存模塊的。

這么看來(lái)，“相同模塊是否會(huì)被加載多次”這個(gè)問(wèn)題，其實(shí)就演變成了“相同模塊是否會(huì)出現(xiàn)在不同路徑里”。簡(jiǎn)單想來(lái)這似乎不太可能，因?yàn)槿绻覀円褂媚硞€(gè)模塊的時(shí)候，它的位置總是確定的。例如，使用npm安裝的模塊，總是會(huì)出現(xiàn)在當(dāng)前目錄的node_modules里，加載時(shí)總是會(huì)找到相同的路徑。那么，在“間接”依賴相同模塊的情況下呢？

例如我們想要使用Express框架，于是使用npm來(lái)安裝，便會(huì)得到：

$ npm install express
express@2.5.2 ./node_modules/express 
├── mkdirp@0.0.7
├── qs@0.4.0
├── mime@1.2.4
└── connect@1.8.5

可見(jiàn)，Express依賴了其他一些模塊，它們都存放在express模塊自己的目錄里面，例如./node_modules/express/node_modules/mime。好，假如我們項(xiàng)目自身也要使用mime項(xiàng)目，我們自然也可以使用npm來(lái)安裝：

$ npm install mime
mime@1.2.4 ./node_modules/mime

于是我們最終得到的是這樣的結(jié)構(gòu)：

./node_modules
├── mime
└── express
    └── node_modules
        ├── mkdirp
        ├── qs
        ├── mime
        └── connect

請(qǐng)注意，這里的mime模塊便出現(xiàn)在兩個(gè)位置上，它們名稱版本都一致，完全是一個(gè)模塊。那么試想，如果我們?cè)谧约旱拇a里加載的mime模塊，以及express內(nèi)部加載的mime模塊是同一個(gè)嗎？顯然不是，可見(jiàn)，在這里相同的模塊被重復(fù)加載了兩次，產(chǎn)生了兩個(gè)模塊“實(shí)例”。

這種重復(fù)加載在一般情況下不會(huì)有太大問(wèn)題，最多內(nèi)存占用大一點(diǎn)而已，不會(huì)影響程序的正確性。但是，我們也可以輕易設(shè)想到一些意外的情況。例如，在Jscex中，每個(gè)Task對(duì)象我都會(huì)給定一個(gè)ID，不斷增長(zhǎng)。要實(shí)現(xiàn)這點(diǎn)我們需要維護(hù)一個(gè)“種子”，全局唯一。之前這個(gè)種子定義在閉包內(nèi)部，但由于Jscex模塊會(huì)被加載多次，這樣從不同模塊“實(shí)例”生成的Task對(duì)象，它們的ID便有可能重復(fù)。當(dāng)然，解決這個(gè)問(wèn)題也并不困難，只需要將種子定義在根對(duì)象上即可，不同的模塊“實(shí)例”共享相同的根對(duì)象。

還有個(gè)問(wèn)題可能就顯得隱蔽些了，我們可以通過(guò)一個(gè)簡(jiǎn)單的實(shí)驗(yàn)來(lái)觀察結(jié)果。我們先來(lái)定義一個(gè)jeffz-a模塊，其中暴露出一個(gè)MyType類型：

module.exports.MyType=function () { }

然后將其發(fā)布到npm上。然后再寫一個(gè)jeffz-b模塊，依賴jeffz-a，并將jeffz-a中定義的MyType類型直接暴露出去：

module.exports.MyType=require("jeffz-a").MyType;

接著將jeffz-b也發(fā)布置npm上。再重新寫一個(gè)測(cè)試模塊，使用npm安裝jeffz-a和jeffz-b，最終目錄會(huì)是這樣的：

./node_modules
├── jeffz-a
└── jeffz-b
    └── node_modules
        └── jeffz-a

在測(cè)試模塊內(nèi)，我們來(lái)測(cè)試實(shí)例與類型之間的關(guān)系：

var a=require("jeffz-a");
var b=require("jeffz-b");

console.log(new a.MyType() instanceof a.MyType); // true
console.log(new b.MyType() instanceof b.MyType); // true

console.log(new a.MyType() instanceof b.MyType); // false
console.log(new b.MyType() instanceof a.MyType); // false

從表面上看，jeffz-b和jeffz-a暴露出的應(yīng)該是相同的MyType類型，它們的對(duì)象通過(guò)instanceof相互判斷應(yīng)該都返回true，但實(shí)際上由于jeffz-b中的jeffz-a，與我們直接加載的jeffz-a模塊是不同的實(shí)例，因此MyType類型自然也不是同一個(gè)了。

這對(duì)于Jscex的影響在于，Jscex的異步模塊在取消時(shí)，原本是通過(guò)判斷異常對(duì)象是否為CanceledError類型來(lái)決定Task的狀態(tài)為cancelled還是faulted。但由于Node.js可能會(huì)將相同的模塊加載為多個(gè)實(shí)例，因此即便拋出的的確是某個(gè)實(shí)例的CancelledError，也無(wú)法通過(guò)另一個(gè)實(shí)例內(nèi)部的判斷。因此，目前Jscex的判斷方式修改為檢查異常對(duì)象的isCancellation字段，簡(jiǎn)單地解決了這個(gè)問(wèn)題。

當(dāng)然，Node.js這種“重復(fù)加載”的影響也并非完全是負(fù)面的，至少它天然的解決了多版本共存的問(wèn)題。例如，express v2.5.2依賴mime v1.2.4，但我們程序自身又想使用mime v1.2.5。此時(shí)，express內(nèi)部自然使用mime v1.2.4，而我們自己的程序使用的便是mime v1.2.5。

有些情況下您可能也想避免這種重復(fù)加載，這就必須手動(dòng)地刪除模塊內(nèi)部被間接依賴的模塊，將其移動(dòng)到模塊查詢路徑的公用部分上了。就目前看來(lái)，這些操作必須手動(dòng)進(jìn)行，因?yàn)閚pm在安裝模塊時(shí)不會(huì)關(guān)心依賴的模塊是否已經(jīng)安裝過(guò)了（例如在NODE_PATH環(huán)境變量標(biāo)識(shí)的路徑里），它一定會(huì)重新下載所有依賴的模塊。可惜如果您使用的是托管形式的Node.js服務(wù)，則很有可能無(wú)法做到這一點(diǎn)。

原文地址：Node.js中相同模塊是否會(huì)被加載多次？-CSDN博客

在線咨詢

上一篇：使用C#實(shí)現(xiàn)電子書閱讀器來(lái)讀取EPUB書籍
下一篇：H5數(shù)獨(dú)游戲開發(fā)-按鈕控件的實(shí)現(xiàn)

您的項(xiàng)目需求

*請(qǐng)認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。

整合營(yíng)銷服務(wù)商