由于一直在使用，所以了解了下seajs的源代碼。這里是我對下面幾個問題的理解：

1、seajs的require(XXX)的方法是怎樣實現模塊加載的？

2、為什么需要預加載？

3、為什么需要構建工具？

4、構建前后的代碼究竟有些什么區別，為什么要這么做？

問題1： seajs的require(XXX)的方法是怎樣實現模塊加載的？

代碼邏輯比較繞，對源代碼的理解放在文章的末尾，這里先簡單梳理下模塊加載的邏輯：

1、從seajs.use方法入口，開始加載use到的模塊。

2、use到的模塊這時mod緩存當中一定是不存在的。seajs創建一個新的mod,賦予一些初始的狀態。

3、執行mod.load方法

4、一堆邏輯之后走到seajs.request方法，請求模塊文件。模塊加載完成之后，執行define方法。

5、define方法分析提取模塊的依賴模塊，保存起來。緩存factory但不執行。

6、模塊的依賴模塊再被加載，如果繼續有依賴模塊，則繼續加載。直至所有被依賴的模塊都加載完畢。

7、所有的模塊加載完畢之后，執行use方法的callback.

8、模塊內部邏輯從callback開始執行。require方法在這個過程當中才被執行。

問題2：為什么需要預加載？

我們看到seajs.use方法實際上是在所有依賴模塊都加載完了之后才執行callback。可以理解成在業務邏輯代碼在執行之前，必須先預加載所有被依賴的模塊代碼。那么為什么是一個這樣必須先做預加載的邏輯？

答案在于邏輯代碼里面引用其他模塊方法的這個require方法的執行方法：

var mod = require(id);

這個語法決定了mod的取得是個同步執行的過程，如果模塊代碼在此之前沒有被預加載的話，就只能采用異步加載回調的方法來實現了，那么整個seajs的執行邏輯將完全會是另一個樣子。因為異步你會搞不懂模塊的執行順序，邏輯會變的難以掌控。

問題3：為什么需要構建工具？

可以看到沒有構建前各個依賴模塊都是單獨加載的。這會產生過多的模塊請求，對于頁面的加載性能是不利的。構建工具本質上就是為了解決模塊合并加載的問題。

問題4：構建前后的代碼究竟有些什么區別，為什么要這么做？

構建工具究竟做了些什么。我們說它本質上是為了解決代碼合并加載的問題，那么它所做的只是簡單的將各個模塊文件合并成一個文件？

當然不是。測試一下，你如果只是簡單把幾個模塊文件合并到一個文件以后，會發現這個文件根本沒有辦法正常執行。

原因在于define方法的實現。

seajs是推崇定義模塊的時候只在define方法傳入factory參數的。回顧define方法內部，當沒有傳入id（姑且等同于模塊的url）時，會通過getCurrentScript()方法去取得當前正在執行的這個模塊文件的url路徑，然后把這個路徑作為鍵值與模塊本身一起緩存到cachedMods。這里很關鍵的一點是，整個seajs內部的這個模塊緩存機制其實是依賴每個模塊的url來做緩存的鍵值。require(id)方法，歸根結底也是通過url鍵值到。require(id)方法，歸根結底也是通過url鍵值到cachedMods里面去找相應的模塊。這個鍵值不能重復不能出錯，不然模塊的對應關系就混亂了。如果把a、b、c幾個模塊文件簡單合并到一個目標文件x之后，getCurrentScript()只能獲取到x的路徑，三個模塊的鍵值就沒法做出區別了，執行肯定出錯。

所以如果要把幾個模塊文件合并在一起，就必須為每個模塊明確uri。也就是define方法必須都傳入id參數。當id傳入的時候，seajs會將這個id轉換為url用作緩存的鍵值。

如果只傳id和factory，也就是 define(id, factory)，那么deps = undefined，define方法就會去執行parseDependencies(factory.toString())方法提取factory里面的依賴模塊，后續會走到解析模塊路徑，線上單獨加載各個模塊的邏輯里面去，這個時候就失去了合并加載的意義了。

所以合并加載，define方法必須正確的傳入id，deps,factory三個參數才能正確執行。

seajs 所謂CMD的模塊定義方法，是提倡大家寫模塊的階段都只傳factory一個參數的，其他兩個參數在后期代碼構建的階段來生成。上面解釋了為什么這兩參數在構建后是必須的。

至于為什么提倡定義模塊的時候只傳factory，我看主要是因為手工傳入的id和deps參數，極易出錯，不便維護。工具可以提高效率并保證參數的正確。

附： 對seajs 主要代碼邏輯的理解。

說明：源代碼版本是Sea.js 2.3.0

1、先看看define方法做了些什么

Module.define = function (id, deps, factory)

define方法的時候，支持三個參數。其中id，deps是選填的。factory必須。代碼里面通過以下邏輯來控制：

但其實deps是必須的，因為seajs必須知道每個模塊依賴了哪些模塊，不然無法執行加載。

所以，當factory是函數，并且deps沒有被主動傳入的時候，就需要使用parseDependencies方法來分析出factory當中的依賴模塊了。

parseDependencies方法做的事情主要就是用一個正則表達式把函數體里面所有require(XXX)里面的XXX提取出來，這也就是這個函數依賴到的所有模塊了。

方法本身不復雜，但是這個正則表達式不簡單：

分析完deps之后,將模塊定義存入緩存：

注意，我們會發現define方法純粹只是分析模塊、存儲模塊，并沒有執行模塊。

2、真正執行模塊，是在require方法里面。我們接下來看require。

簡而言之require方法就是根據id在define定義存儲的模塊緩存中找到相應的模塊，并執行它，獲得模塊定義返回的方法：

整個這個大步驟中，有一個很關鍵的步驟，有必要細說：

Module.get(require.resolve(id))。

require一個模塊的時候，首先要找到這個模塊。 Module.get方法就起這個作用。

cachedMods里面沒有的話，就創建一個新的Module并緩存到cachedMods里面：

define和rquire方法這樣看來不算復雜。seajs主要還是模塊加載的邏輯有點復雜。

3、seajs真正執行的入口，是use方法：

通過use方法，從這里的ids開始觸發模塊的加載和執行。

可以看到加載的關鍵點在mod.load方法。

load方法代碼有點長，其中的主要邏輯是：判斷mod的當前狀態是否為已加載或者加載中。

在Module的舒適化函數中，我們可以看到status默認值是0.

所以沒有加載過的新模塊，到這里都是： mod.status = STATUS.LOADING 狀態設置為加載中，并執行后續加載邏輯。

接來下是獲取模塊的依賴urls

mod.resolve方法：

Module.resolve方法本質上就是把相對路徑、配置的path、別名等轉換成一個絕對路徑。不貼代碼了。

更新模塊加載狀態。

加載模塊的邏輯：

主要是m.fetch方法，里面其他邏輯這里略過。

可以看到 seajs.request最終會去執行模塊文件的加載:

當所有依賴模塊加載完了之后，執行mod的onload方法

這里是 mod.onload()方法

到此，seajs的核心邏輯就差不多都看到了。供參考，有理解不到位或者表達不準確的地方，歡迎一起探討。

以上所述就是本文的全部內容了，希望大家能夠喜歡。