開發中，模組化可以防止變數和方法被汙染，只需要關注一部分的邏輯實現，有效地減少了與全域性的耦合，也便於後期的維護和擴充
當然，相信瞭解過前端模組化發展歷史的童鞋，都應該聽過IIFE、AMD、CommonJS等等，它們都是能夠實現模組化的規範，直到ES2015出來後，才正式把模組化納入其標準中。在談到今天主題前，我們先簡單講解一下上面幾種模組化方式的實現以及區別，對於後面將要講到的webpack模組化優化有一定幫助。
IIFE
在各種模組化規範出來之前，ES5是不支援模組化開發，但當時也有一些大牛們為了更好地避免函式的副作用和封裝，就開始巧妙地想到了使用IIFE來實現模組化（注：JS本身是不存在塊級作用域）：
可以看到，在原來的ES5基礎上可以封裝部分邏輯模組，也就是一個簡單的閉包行為，避免內部變數收到外部環境的影響。
但是，缺陷也是很明顯滴暴露出來，它無法實現模組間的依賴，同時程式碼是分配到主流程中，對於後期的維護和修改帶來了困難。
CommonJS
CommonJS規範實現的是同步載入方式，常用於服務端，其終極目標是提供一個類似Python，Ruby和Java模組化標準庫。
為此，NodeJS的出現，也就正式標誌著Javascript模組化程式設計誕生。在服務端，模組需要與作業系統或者應用程式進行互動，而NodeJS的模組系統就是參照CommonJS規範進行編寫的。
該規範指出，需通過exports或者module.exports（注：這兩個匯出方法的使用區別，有興趣的童鞋可以看看阮一峰對於該API的講解）來匯出對外的變數或介面，通過require方法匯入其他模組的輸出到當前模組作用域中。直接上栗子：
這時候，也許有童鞋會提出疑問，那麼CommonJS能用於客戶端嗎？
答案是肯定的。由於客戶端由於缺少四個Node.js環境的變數：module、exports、require、global，導致客戶端無法使用CommonJS規範。為此，需第三方工具或庫（例如require1k、tiny-browser-require等等）才能讓客戶端實現CommonJS規範。
AMD
鑑於ES5內部通過IIFE實現的模組化無法真正意思上（類似Java、Python等）的模組化，因此有些大牛們就提出了適用於客戶端的AMD規範，它可以非同步引入模組，同時模組可以很好地將某些邏輯功能封裝在一個檔案中以便主流程需要時引入。其中RequireJS庫很好滴實現了AMD規範，直接上例子：
RequireJS API暴露了require和define兩個全域性方法，對於主流程或者模組中需要依賴其他模組時，都可以傳進require和define兩個全域性方法第一個引數中。同時，我們可以看到，AMD規範實現的是非同步載入模組方式（多個模組引入時會並行載入，有效滴加快執行效率並且無阻塞頁面的載入）。對於每個模組只需要做該模組該做的事情即可，模組與主流程之間有效地減低了耦合度。
CMD
CMD規範也叫通用模組定義(Common Module Definition)，實現的也是非同步載入模組方式，SeaJS庫就很好滴實現該規範，它主要具有以下特點：
- 使用上：和
AMD規範類似，都是使用require和define兩個全域性方法，但使用require方法時卻是同步執行模組程式碼的，這和CommonJS規範很類似； - 實現上：
CMD規範核心是提前載入，延遲執行，而AMD規範核心是提前載入，提前執行，當然CommonJS規範核心則是延遲載入，延遲執行；
需要注意的是，CMD規範使用require方法的原因是因為在提前載入模組過程中，會把載入下來的模組儲存在記憶體中，以至於客戶端執行主流程按需引入模組時是同步執行記憶體中儲存的模組。（有興趣的童鞋，可以看看這邊文章——SeaJS是如何工作的）
在我看來，CMD規範的懶執行機制可有效地提高頁面互動效能，因為在頁面互動過程完成前不需要執行其他暫時沒用到的模組（當然這只是我個人觀點，如果有童鞋有不同的看法，可以在評論區上寫上來一起探討學習一下，對於效能對比上，童鞋們也可以看看SeaJS的github上關於AMD和CMD對比，挺有趣的）。而這種機制，也對於下面我要提到webpack模組化優化密切相關。
現在就直接上一個SeaJS栗子領略一下CMD規範（有興趣的童鞋，也可以看下SeaJS的API）：
UMD
UMD規範可以看成是一種方案，用於解決前後端跨平臺模組載入，支援AMD規範和CommonJS規範。說白了，就是致力於用一種實現方式能夠把模組載入相容前後端。
話不多說，有興趣的童鞋可以看看UMD的官方介紹和栗子。下面也用一個簡單的栗子來領略UMD規範的寫法：
可以看到，UMD規範實現方式就是先判斷是否支援AMD規範，然後再判斷是否支援CommonJS規範，當兩者均不支援時則直接把模組定義在全域性物件上
ES6 Module
由於ES5缺少模組化載入理念，因此在ES6中正式把模組化載入納入其標準
ES6中模組是在編譯時輸出介面，而上面提到的各種模組載入規範都是在執行時輸出介面，可以看到，ES6 Module在一定程度上對效能進行了優化。有興趣的童鞋可以看看阮一峰的對ES6 Module的介紹。下面就舉個例子：
目前，客戶端基本都是使用ES6 Module模組載入方式來對模組進行載入，而對於Node服務端尚在逐漸向該模組載入方式靠攏，但是大部分情況下依然還是使用CommonJS規範。
相信大家看完上面模組載入的各種實現方式，都應該對模組化有一定的瞭解。好啦，下面就進入今天的主題，在Webpack中可以怎樣去對Application中模組化進行優化呢？
遇到的問題
在日常模組化開發中，一個頁面會有很多個元件所構成，而這些元件是需要我們按需引入的，毫無疑問，現在我們以Vue作為栗子，專案結構（下面只展示主要的目錄和檔案，至於其他目錄和檔案就不展示了）如下：
|- src|--- components|------ message.vue // 詳細資訊框元件|------ main.vue // 首頁需要的元件 |------ goods.vue // 商品頁面元件|--- router|------ index.js // 路由檔案|--- App.vue // 入口vue檔案複製程式碼正常情況下，我們是這樣編寫頁面的：
App.vue
index.js 路由檔案
main.vue 首頁元件
goods.vue 商品頁面元件
message.vue 商品資訊元件
上面的栗子，執行時在網址上輸入localhost:8080/#/會直接使用Main.vue首頁元件，當輸入localhost:8080/#/goods時會展示goods.vue商品元件，點選按鈕會直接展示message.vue詳細資訊元件。
到這裡，我會想問，上面的簡單SPA栗子是否還有更加優化的方案？倘若我想加快首頁載入的速度以使使用者有個更好的體驗，該如何處理？
對於上面的問題，我們會經常遇到，各位童鞋也可以各抒己見在評論區說說自己的看法。在這裡，就不賣關子，換作是我，首先想到要下手的就是Webpack，而這也是今天所要提及的核心內容：用Webpack如何更好地優化複雜程式的模組化。
Dynamic Import
目前嘗處於stage 3階段的ECMAScript提案的import()語法，相信很多童鞋都有了解過或聽過，那它究竟是幹嘛的？按照官方的說法就是：
ECMAScript modules are completely static, import() enables dynamic loading of ECMAScript modules.
簡單滴說，就是目前模組載入都是靜態載入的，而import()可讓我們按需載入對應模組。那麼問題來了，上面栗子也是按需載入，首頁只需要Main首頁元件，而商品頁面也只載入了goods和message元件。那麼再細心看看，上面的栗子是不是真的做到了按需載入？
答案是否定的，正如我上面提及的ES6 Module是在編譯階段就輸出介面，因此當我們使用Webpack打包後，所有需要的模組都會打進一個js檔案中。因此，首頁在載入過程中，就需要載入完整個js檔案才能讓使用者進行體驗效果，當然我們都知道，這個js檔案也有一些模組邏輯是我們暫時並不需要用到，而這也恰好是我們接下來要處理的問題。
import()語法的出現，再結合webpack 4（也可以選擇webpack 3），就可以很優雅地處理上述問題。當然也少不了babel的轉化。下面就是處理實現：
webpack.config.js 部分配置
再將路由檔案進行修改後如下：
可以看到，當我們再次訪問localhost:8080/#/時，會發現載入js檔案比之前小了，而且最重要的該檔案裡是沒有Goods商品元件程式碼的。當再訪問localhost:8080/#/goods時，會非同步從服務端載入0.js檔案，而改檔案是包含Goods商品元件程式碼的。由此可見，不僅減少了主流程js檔案的大小，加快頁面的載入體驗，而且還可以按需非同步下載必要的模組檔案。
好了，到了這裡，如果我想再優化一下有Goods商品元件中Message詳細資訊元件，因為它是隻有在點選按鈕才去載入的，那我們是不是也可以讓其進行懶載入，讓localhost:8080/#/goods下的頁面載入更加快？
答案是肯定的，但是需要用到Vue中component語法，事不宜遲，我們就來動手改改看：
goods.vue 商品頁面元件
當我們再去訪問localhost:8080/#/goods時，會發現js檔案也比之前少了Message詳細資訊元件程式碼，加快載入體驗，同時點選按鈕後，會動態引入1.js檔案，這也是從服務端非同步引入載入Message詳細資訊元件。
這時候，也許會有童鞋提測疑問，當關閉Message詳細資訊元件彈窗時，再重新點選按鈕，就需要重新render，那這樣豈不是需要消耗一定的效能？答案是肯定會有所損耗，那麼如果想優化它，可以怎麼做？很簡單，只需要使用Vue API暴露的<來包裹我們的
keep-alive>
元件<即可，這樣就會有效滴把元件儲存在記憶體中，下次訪問時可直接從記憶體中讀取。
component>
至此，也許有童鞋又會提出疑問，上面0.js檔案和1.js檔案到底是什麼鬼？再耐心點往下看，說不定有你想要的驚喜哈哈?
Magic Comments
上面之所以會出現0和1，原因是因為對於動態引入import()不指定模組名稱chunkName時，Webpack會預設從0到n來按序命名接下來動態引入的檔案。
但是，對於這些數字0或者n，我們是無法知道該動態引入的js檔案是屬於哪一個模組，為此Webpack也為我們提供了Magic Comments，以此可以自定義模組名稱。
下面就拿上面路由檔案動態引入作為栗子，使用上很簡單：
這時候，從localhost:8080/#/中訪問localhost:8080/#/goods時，會發現載入不是0.js，而是goods.js，這樣就會很容易知道哪些模組是動態引入的。當然有興趣的童鞋，也可以想想指定Message詳細資訊元件動態引入時的chunkName。
至此，上面講到的方案，可以有效滴優化我們現有階段的模組化開發，當然童鞋們也可以嘗試一下。
Extension
其實，在我看來，還可以更深入點優化一下。就拿上面的Goods商品元件，當點選按鈕時，如果載入的模組比較大，使用者就不得不去等待載入完整個message.js檔案才能展示彈窗出來（當然這樣的情況出現不是特別多，由於打包後的js檔案一般都會存放到cdn上，而請求時會採取就近原則載入，這也有效避免這個問題，但我們還是可以探討一下這個問題可以使用什麼方式避免）。為此我們有木有方案可以將這個時延有效滴去掉？在這裡我就不賣關子，在Webpack 4.6中，指出明確支援prefetching and preloading，而這兩個東西恰好就是可以解決我們剛剛要面對問題。
Preload And PreFetch
Preload是預載入，PreFetch是預測將要載入的模組，這兩者都是link標籤下的屬性。有興趣的童鞋，可以看看關於這兩者在客戶端執行的優先順序
簡單來說，Preload優先順序為Height，而PreFetch則為Low。這兩者是有區別的：
preload：主要是用於當前頁面的預載入，會和主檔案bundle.js並行下載，且優先獲取，可用於預載入某些必要模組prefetch: 主要是用於下一步操作或者頁面，會在瀏覽器空閒時間才去下載，優先順序最低
另外，需要說明的是，preload和prefetch目前對於現有的瀏覽器的支援程度並不是那麼的友好。具體可以看看兩個相容性：Preload的相容性和Prefetch的相容性
雖然相容性不是那麼友好，preload和prefetch都是申明性質的，所以就算不支援，也不會影響現有頁面的任何功能
看到這裡，估計大家應該也可以想到，使用prefetch可以解決我們上面遇到的時延等待問題，那麼具體怎麼寫？在這裡，我們還需要藉助Webpack的preload-webpack-plugin外掛，配置編寫如下：
webpack.config.js 部分配置
這時候，就要在Webpack 4.6+版本上，修改商品頁元件如下：
goods.vue 商品頁面元件
可以看到，只需要加上webpackPrefetch: true的註釋再結合preload-webpack-plugin外掛即可把動態引入的模組進行Prefetch。
當我們再次訪問localhost:8080/#/goods時，會發現，載入完主流程的js檔案後，然後在瀏覽器的空閒時間，就會自動載入message.js檔案，並且可以看到其優先順序為Low的。另外，我們也可以看到在<標籤，是通過
head><標籤使用
link>rel="prefetch"來載入message.js檔案。這時候再點選按鈕，就會不再需要等待時延直接載入Message元件。
至於上述執行的效果圖，我就不截圖了，有興趣的童鞋可以親自去嘗試驗證一下，這樣才能有更加深刻的印象。如有不便，在這裡我就說聲不好意思哈?
對於Webpack模組化載入優化，也許還會有一些更好更優的方案，也歡迎?大神們在評論區分享分享來一起學習。而上述的優化方案，其實在日常的模組化開發中是可以使用到的，不過還請大家要結合自己需求的應用場景分析再來優化，一旦使用不當，優化也許就是一個消耗效能的體驗。