作者：張?jiān)讫?br />鏈接：https://www.zhihu.com/question/20790576/answer/32602154
來源：知乎
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。

沒人邀請，看到這個(gè)問題不錯(cuò)，路過怒答。（多圖預(yù)警）

前百度工程師，曾負(fù)責(zé)百度 前端集成解決方案 的核心設(shè)計(jì)與開發(fā)工作。我現(xiàn)在稱這個(gè)領(lǐng)域?yàn)椤厩岸斯こ獭俊]錯(cuò)，這是我最愛嘮叨的問題域。

這是一個(gè)非常有趣的 非主流前端領(lǐng)域，這個(gè)領(lǐng)域要探索的是如何用工程手段解決前端開發(fā)和部署優(yōu)化的綜合問題，入行到現(xiàn)在一直在學(xué)習(xí)和實(shí)踐中。

在我的印象中，facebook是這個(gè)領(lǐng)域的鼻祖，有興趣、有梯子的同學(xué)可以去看看facebook的頁面源代碼，體會(huì)一下什么叫工程化。

接下來，我想從原理展開講述，多圖，較長，希望能有耐心看完。

---------------------------- 我是一條分割線 ----------------------------

<img src="https://pic2.zhimg.com/07c2bdef6ccef3ada425d61e3062dd09_b.jpg" data-rawwidth="389" data-rawheight="238" class="content_image" width="389">

讓我們返璞歸真，從原始的前端開發(fā)講起。上圖是一個(gè)“可愛”的index.html頁面和它的樣式文件a.css，用文本編輯器寫代碼，無需編譯，本地預(yù)覽，確認(rèn)OK，丟到服務(wù)器，等待用戶訪問。前端就是這么簡單，好好玩啊，門檻好低啊，分分鐘學(xué)會(huì)有木有！

<img src="https://pic1.zhimg.com/d53b504bbc9f1887eddf06d90545b870_b.jpg" data-rawwidth="400" data-rawheight="98" class="content_image" width="400">

然后我們訪問頁面，看到效果，再查看一下網(wǎng)絡(luò)請求，200！不錯(cuò)，太?完美了！那么，研發(fā)完成。。。。了么？

等等，這還沒完呢！對于大公司來說，那些變態(tài)的訪問量和性能指標(biāo)，將會(huì)讓前端一點(diǎn)也不“好玩”。

看看那個(gè)a.css的請求吧，如果每次用戶訪問頁面都要加載，是不是很影響性能，很浪費(fèi)帶寬啊，我們希望最好這樣：

<img src="https://pic1.zhimg.com/6a611755a5648ca252211cec85a31ac4_b.jpg" data-rawwidth="401" data-rawheight="98" class="content_image" width="401">

利用304，讓瀏覽器使用本地緩存。但，這樣也就夠了嗎？不成！304叫協(xié)商緩存，這玩意還是要和服務(wù)器通信一次，我們的優(yōu)化級別是變態(tài)級，所以必須徹底滅掉這個(gè)請求，變成這樣：

<img src="https://pic3.zhimg.com/fd74ab2bf02d79dd7af1336b4c8f180e_b.jpg" data-rawwidth="400" data-rawheight="98" class="content_image" width="400">

強(qiáng)制瀏覽器使用本地緩存（cache-control/expires），不要和服務(wù)器通信。好了，請求方面的優(yōu)化已經(jīng)達(dá)到變態(tài)級別，那問題來了：你都不讓瀏覽器發(fā)資源請求了，這緩存咋更新？

很好，相信有人想到了辦法：通過更新頁面中引用的資源路徑，讓瀏覽器主動(dòng)放棄緩存，加載新資源。好像這樣：

<img src="https://pic2.zhimg.com/8a8676e933478d1a73777d84a5de55f5_b.jpg" data-rawwidth="304" data-rawheight="110" class="content_image" width="304">

下次上線，把鏈接地址改成新的版本，就更新資源了不是。OK，問題解決了么？！當(dāng)然沒有！大公司的變態(tài)又來了，思考這種情況：

<img src="https://pic1.zhimg.com/4681f7131e777dc885bf66000580ca40_b.jpg" data-rawwidth="579" data-rawheight="310" class="origin_image zh-lightbox-thumb" width="579" data-original="https://pic1.zhimg.com/4681f7131e777dc885bf66000580ca40_r.jpg">

頁面引用了3個(gè)css，而某次上線只改了其中的a.css，如果所有鏈接都更新版本，就會(huì)導(dǎo)致b.css，c.css的緩存也失效，那豈不是又有浪費(fèi)了？！

重新開啟變態(tài)模式，我們不難發(fā)現(xiàn)，要解決這種問題，必須讓url的修改與文件內(nèi)容關(guān)聯(lián)，也就是說，只有文件內(nèi)容變化，才會(huì)導(dǎo)致相應(yīng)url的變更，從而實(shí)現(xiàn)文件級別的精確緩存控制。

什么東西與文件內(nèi)容相關(guān)呢？我們會(huì)很自然的聯(lián)想到利用 數(shù)據(jù)摘要要算法 對文件求摘要信息，摘要信息與文件內(nèi)容一一對應(yīng)，就有了一種可以精確到單個(gè)文件粒度的緩存控制依據(jù)了。好了，我們把url改成帶摘要信息的：

<img src="https://pic1.zhimg.com/5276595f41d6276e21e5bc1d25741680_b.jpg" data-rawwidth="588" data-rawheight="310" class="origin_image zh-lightbox-thumb" width="588" data-original="https://pic1.zhimg.com/5276595f41d6276e21e5bc1d25741680_r.jpg">

這回再有文件修改，就只更新那個(gè)文件對應(yīng)的url了，想到這里貌似很完美了。你覺得這就夠了么？大公司告訴你：圖樣圖森破！

唉~~~~，讓我喘口氣

現(xiàn)代互聯(lián)網(wǎng)企業(yè)，為了進(jìn)一步提升網(wǎng)站性能，會(huì)把靜態(tài)資源和動(dòng)態(tài)網(wǎng)頁分集群部署，靜態(tài)資源會(huì)被部署到CDN節(jié)點(diǎn)上，網(wǎng)頁中引用的資源也會(huì)變成對應(yīng)的部署路徑：

<img src="https://pic2.zhimg.com/0866cb58bcf349642d57a06b162e0d91_b.jpg" data-rawwidth="574" data-rawheight="259" class="origin_image zh-lightbox-thumb" width="574" data-original="https://pic2.zhimg.com/0866cb58bcf349642d57a06b162e0d91_r.jpg">

好了，當(dāng)我要更新靜態(tài)資源的時(shí)候，同時(shí)也會(huì)更新html中的引用吧，就好像這樣：

<img src="https://pic1.zhimg.com/16d6d6c32e52ef1d1a835fb2ed15f864_b.jpg" data-rawwidth="574" data-rawheight="456" class="origin_image zh-lightbox-thumb" width="574" data-original="https://pic1.zhimg.com/16d6d6c32e52ef1d1a835fb2ed15f864_r.jpg">
這次發(fā)布，同時(shí)改了頁面結(jié)構(gòu)和樣式，也更新了靜態(tài)資源對應(yīng)的url地址，現(xiàn)在要發(fā)布代碼上線，親愛的前端研發(fā)同學(xué)，你來告訴我，咱們是先上線頁面，還是先上線靜態(tài)資源？

先部署頁面，再部署資源：在二者部署的時(shí)間間隔內(nèi)，如果有用戶訪問頁面，就會(huì)在新的頁面結(jié)構(gòu)中加載舊的資源，并且把這個(gè)舊版本的資源當(dāng)做新版本緩存起來，其結(jié)果就是：用戶訪問到了一個(gè)樣式錯(cuò)亂的頁面，除非手動(dòng)刷新，否則在資源緩存過期之前，頁面會(huì)一直執(zhí)行錯(cuò)誤。

先部署資源，再部署頁面：在部署時(shí)間間隔之內(nèi)，有舊版本資源本地緩存的用戶訪問網(wǎng)站，由于請求的頁面是舊版本的，資源引用沒有改變，瀏覽器將直接使用本地緩存，這種情況下頁面展現(xiàn)正常；但沒有本地緩存或者緩存過期的用戶訪問網(wǎng)站，就會(huì)出現(xiàn)舊版本頁面加載新版本資源的情況，導(dǎo)致頁面執(zhí)行錯(cuò)誤，但當(dāng)頁面完成部署，這部分用戶再次訪問頁面又會(huì)恢復(fù)正常了。

好的，上面一坨分析想說的就是：先部署誰都不成！都會(huì)導(dǎo)致部署過程中發(fā)生頁面錯(cuò)亂的問題。所以，訪問量不大的項(xiàng)目，可以讓研發(fā)同學(xué)苦逼一把，等到半夜偷偷上線，先上靜態(tài)資源，再部署頁面，看起來問題少一些。

但是，大公司超變態(tài)，沒有這樣的“絕對低峰期”，只有“相對低峰期”。So，為了穩(wěn)定的服務(wù)，還得繼續(xù)追求極致啊！

這個(gè)奇葩問題，起源于資源的 覆蓋式發(fā)布，用 待發(fā)布資源 覆蓋 已發(fā)布資源，就有這種問題。解決它也好辦，就是實(shí)現(xiàn) 非覆蓋式發(fā)布。

<img src="https://pic4.zhimg.com/9b3a9df114d14a14130a70abf5733837_b.jpg" data-rawwidth="631" data-rawheight="456" class="origin_image zh-lightbox-thumb" width="631" data-original="https://pic4.zhimg.com/9b3a9df114d14a14130a70abf5733837_r.jpg">

看上圖，用文件的摘要信息來對資源文件進(jìn)行重命名，把摘要信息放到資源文件發(fā)布路徑中，這樣，內(nèi)容有修改的資源就變成了一個(gè)新的文件發(fā)布到線上，不會(huì)覆蓋已有的資源文件。上線過程中，先全量部署靜態(tài)資源，再灰度部署頁面，整個(gè)問題就比較完美的解決了。

所以，大公司的靜態(tài)資源優(yōu)化方案，基本上要實(shí)現(xiàn)這么幾個(gè)東西：

配置超長時(shí)間的本地緩存 —— 節(jié)省帶寬，提高性能

采用內(nèi)容摘要作為緩存更新依據(jù) —— 精確的緩存控制

靜態(tài)資源CDN部署 —— 優(yōu)化網(wǎng)絡(luò)請求

更資源發(fā)布路徑實(shí)現(xiàn)非覆蓋式發(fā)布 —— 平滑升級

全套做下來，就是相對比較完整的靜態(tài)資源緩存控制方案了，而且，還要注意的是，靜態(tài)資源的緩存控制要求在前端所有靜態(tài)資源加載的位置都要做這樣的處理。是的，所有！什么js、css自不必說，還要包括js、css文件中引用的資源路徑，由于涉及到摘要信息，引用資源的摘要信息也會(huì)引起引用文件本身的內(nèi)容改變，從而形成級聯(lián)的摘要變化，大概示意圖就是：

<img src="https://pic3.zhimg.com/edf10bb428d39d721e36760a86d2641e_b.jpg" data-rawwidth="709" data-rawheight="371" class="origin_image zh-lightbox-thumb" width="709" data-original="https://pic3.zhimg.com/edf10bb428d39d721e36760a86d2641e_r.jpg">

好了，目前我們快速的學(xué)習(xí)了一下前端工程中關(guān)于靜態(tài)資源緩存要面臨的優(yōu)化和部署問題，新的問題又來了：這?讓工程師怎么寫碼啊！！！

要解釋優(yōu)化與工程的結(jié)合處理思路，又會(huì)扯出一堆有關(guān)模塊化開發(fā)、資源加載、請求合并、前端框架等等的工程問題，以上只是開了個(gè)頭，解決方案才是精髓，但要說的太多太多，有空再慢慢展開吧。或者大家可以去我的blog看其中的一些拆解：fouber/blog · GitHub

總之，前端性能優(yōu)化絕逼是一個(gè)工程問題！

以上不是我YY的，可以觀察 百度 或者 facebook 的頁面以及靜態(tài)資源源代碼，查看它們的資源引用路徑處理，以及網(wǎng)絡(luò)請中靜態(tài)資源的緩存控制部分。再次贊嘆facebook的前端工程建設(shè)水平，跪舔了。

建議前端工程師多多關(guān)注前端工程領(lǐng)域，也許有人會(huì)覺得自己的產(chǎn)品很小，不用這么變態(tài)，但很有可能說不定某天你就需要做出這樣的改變了。而且，如果我們能把事情做得更極致，為什么不去做呢？

另外，也不要覺得這些是運(yùn)維或者后端工程師要解決的問題。如果由其他角色來解決，大家總是把自己不關(guān)心的問題丟給別人，那么前端工程師的開發(fā)過程將受到極大的限制，這種情況甚至在某些大公司都不少見！

媽媽，我再也不玩前端了。。。。5555

轉(zhuǎn)載于:https://www.cnblogs.com/ping8388/p/6478218.html

總結(jié)

以上是生活随笔為你收集整理的大公司里怎样开发和部署前端代码的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。