最近在思考前端js文件該如何合并，當然不包括不能合并文件，而是我們能合并的文件，想了想應(yīng)該也只有三種方式。

三個方式如下：

1. 一個大文件，所有js合并成一個大文件，所有頁面都引用它。

2. 各個頁面大文件，各自頁面合并生成自己所需js的大文件。

3. 合并多個共用大文件，根據(jù)實踐情況合并出多個共用js文件，每個頁面引用多個共用大文件。

另外在我看來，合并有兩個目的：

1. 為了減少請求數(shù)。

2. 代碼安全考慮（文件分得越多，越容易被人看清）。

PS：注意我說的不是壓縮混淆，只是合并

1. 一個大文件

這種方式就是不管三七二十一，所有js合并成一個大文件，所有頁面都引用它，即使某些代碼可能不會用到。

優(yōu)點：

（1）. 合并簡單，使用也簡單。

（2）. 其他頁面可利用緩存優(yōu)化加載。

缺點：

（1）. 頁面可能會加載到本頁面不使用的代碼。

不適用場景：

（1）. 這種方式肯定不適用于大型的Web應(yīng)用，且不論單文件代碼量，業(yè)務(wù)的復雜性也不允許我們這樣干（我沒見過那個網(wǎng)站這樣做的）。

適用場景：

（1）. Hybrid應(yīng)用，無論是Mobile的Hybrid應(yīng)用，還是PC的Hybrid應(yīng)用（桌面應(yīng)用，類似有道團隊開發(fā)框架hex+chromium +nodejs），都非常適合，本身就不會有請求速度問題，這種位于客戶端代碼的應(yīng)用的代碼安全更為重要。

PS：當然最重要的還是后端的安全，無論前端是否被破解，后端是否完善輸入校驗，是否防止越權(quán)，后端才是關(guān)鍵，也就是常說一句話“不要相信用戶的任何輸入”。

2. 各個頁面大文件

各個頁面合并生成自己所需js的大文件，生成多份js合并。

優(yōu)點：

（1）. 每個頁面都用到最精確的js，不會有不相關(guān)代碼。

缺點：

（1）. 有多少個頁面，就會生成多個js，導致存在大量共同js代碼的冗余。

（2）. 共用部分無法使用緩存優(yōu)化加載。

（3）. 合并和使用會相對比較復雜。

這種方式我始終覺得不對勁，小應(yīng)用直接單個大文件搞定，而大應(yīng)用更不會這樣去做，更不能用在Hybrid應(yīng)用上，在這樣講究安裝包大小的情形下，不能容忍冗余代碼。我在思考各種場景時候，都發(fā)現(xiàn)能用上面或下面方式解決，而且是更優(yōu)，所以我覺得這種方式是個雞肋。

3. 合并多個共用大文件

根據(jù)實踐情況合并多個共用大文件（例如依賴庫分類），再合并本頁面所需js文件（例如以業(yè)務(wù)分類），每個頁面引用一個或多個共用大文件和本頁面的js文件。

優(yōu)點：

（1）. 共用部分得到加載優(yōu)化，每個頁面引用的也盡可能的做到了不冗余。

缺點：

（1）. 多多少少還是會存在某些頁面會引用到不需要的代碼，共用不并不是完完全全的共用。

適用場景：

（1）. 大小型應(yīng)用都比較適用，每個頁面可能存在許多共用部分，合理的分文件合并將非常關(guān)鍵。

總結(jié)

這一篇文件只是思考，也只算泛泛之談。文件合并方法挺多，由后端動態(tài)生成或工具直接生成（grunt+requirejs），合并的方式也就以上三種，也取決于我們實踐需要。

合并很重要，但不是提倡所有文件都合并起來，有不能合并的，有些單獨文件更優(yōu)的，還是要看具體場景。

以上這篇前端js文件合并的三種方式推薦就是小編分享給大家的全部內(nèi)容了，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論