一、 核心配置優(yōu)化（前提是訪問(wèn)網(wǎng)站的請(qǐng)求能抵達(dá)服務(wù)器）

方案一：前端項(xiàng)目設(shè)置全局不緩存方案

• 運(yùn)行邏輯：在H5服務(wù)器配置中增加Cache-Control: no-cache或max-age=0響應(yīng)頭，禁用靜態(tài)資源緩存‌；
• 優(yōu)點(diǎn)：能在服務(wù)器出口處最大可能地解決發(fā)布項(xiàng)目緩存問(wèn)題
• 缺點(diǎn)：用戶在不同界面跳轉(zhuǎn)都會(huì)重新加載界面信息，影響整個(gè)前端加載速度，高并發(fā)時(shí)容易造成帶寬壓力

方案二： 首頁(yè)index.html資源緩存修正，禁制index.html文件緩存

server {
    listen 8080;
	root /var/www/web/;
	location /index.html {
        add_header Cache-Control "no-cache, no-store, must-revalidate, private";
    	add_header Pragma "no-cache";
   		add_header Expires "0";
    	try_files $uri /index.html;
    }
	location / {
        try_files $uri $uri/ /index.html;
    }
}

• 優(yōu)點(diǎn)： 單頁(yè)面應(yīng)用設(shè)置首頁(yè)模板強(qiáng)制不緩存，用戶瀏覽器不會(huì)緩存 index.html 文件，每次都會(huì)向服務(wù)器拉取新的首頁(yè)模板，確保用戶不會(huì)使用歷史模板。
• 缺點(diǎn)： 用戶不緩存首頁(yè)，每次都會(huì)拉取，導(dǎo)致每次進(jìn)入系統(tǒng)都會(huì)等待相對(duì)較長(zhǎng)的時(shí)間。

方案三： 首頁(yè) index.html 資源添加 ETag和Last-Modified 參數(shù)

server {
    listen 8080;
	root /var/www/web/;
	location /index.html {
        etag on;
        if_modified_since exact;
        add_header Cache-Control "public, max-age=0";
        expires modified +1y;
        try_files $uri /index.html;
    }
	location / {
        try_files $uri $uri/ /index.html;
    }
}

• ETag：是服務(wù)器為資源生成的唯一標(biāo)識(shí)符（如哈希值或版本號(hào)），內(nèi)容變化時(shí)標(biāo)識(shí)會(huì)更新。
• Last-Modified： 服務(wù)器返回資源的最后修改時(shí)間戳
• 運(yùn)行邏輯：客戶端首次請(qǐng)求資源時(shí)，服務(wù)器返回 ETag 和 Last-Modified。后續(xù)請(qǐng)求中，客戶端可能同時(shí)發(fā)送 If-None-Match 和 If-Modified-Since。服務(wù)器優(yōu)先檢查 ETag 與 Last-Modified（若存在），直接返回 304，瀏覽器使用緩存文件；因 ETag 精度更高，若匹配，則會(huì)忽略 Last-Modified。
• 優(yōu)點(diǎn)：能檢測(cè)到內(nèi)容字節(jié)級(jí)別的變化或者文件系統(tǒng)時(shí)間戳的變化，從而讓用戶端使用新的文件；通過(guò)檢驗(yàn)文件的方式實(shí)施高效緩存策略，可有效利用客戶端緩存，提升網(wǎng)站性能并降低服務(wù)器壓力。
• 缺點(diǎn)：若多服務(wù)器間文件屬性或文件時(shí)間戳不一致，可能導(dǎo)致 ETag/Last-Modified 沖突（如果是一個(gè)jenkins編譯，將一個(gè)編譯包放到兩個(gè)服務(wù)器（服務(wù)器系統(tǒng)版本一致）中實(shí)現(xiàn)負(fù)載均衡，可以使用ETag，如果使用k8s等其他工具發(fā)布需要注意文件同步，可以使用分布式文件系統(tǒng)或同步工具）；
  高并發(fā)時(shí)每一次請(qǐng)求都會(huì)檢驗(yàn)請(qǐng)求的ETag會(huì)占用相對(duì)校對(duì)的CPU性能（針對(duì)目前在線理賠的并發(fā)量，可忽略不計(jì)）；
  太過(guò)于依賴本地緩存，如果請(qǐng)求頭校驗(yàn)通過(guò)但是本地緩存異常會(huì)造成未知異常（目前有人說(shuō)可能會(huì)出現(xiàn)的問(wèn)題，但是并未在某處真的搜索到相關(guān)bug內(nèi)容）；
  可以用：curl -I https://域名 來(lái)查看請(qǐng)求頭內(nèi)容

二、 jenkins發(fā)布流程優(yōu)化方案

• 運(yùn)行邏輯：每次發(fā)布 jenkins 時(shí)不刪除上一個(gè)版本的js文件，直接將新的js放在原有目錄下，達(dá)到新老版本js共存的目的，當(dāng)用戶使用瀏覽器緩存的界面讀取老版本的js不會(huì)因?yàn)槲募淮嬖诙鴪?bào)錯(cuò)。等待用戶瀏覽器識(shí)別到更新后會(huì)更新到新版本。

• 優(yōu)點(diǎn)：
  用戶不會(huì)因?yàn)榘l(fā)布拿不到j(luò)s文件而白屏，基本可以解決因?yàn)榘l(fā)布緩存而白屏的問(wèn)題。

• 缺點(diǎn)：
  用戶使用老版本的js進(jìn)入系統(tǒng)后，無(wú)法使用新功能，如果前后端代碼功能不一致會(huì)導(dǎo)致用戶操作失敗；如果用戶長(zhǎng)時(shí)間沒(méi)有觸發(fā)更新機(jī)制，會(huì)導(dǎo)致更新功能在一段時(shí)間內(nèi)用戶無(wú)法使用；

  隨著每次發(fā)布，服務(wù)器上的js文件會(huì)越來(lái)越多，當(dāng)達(dá)到一定數(shù)量級(jí)后會(huì)影響服務(wù)器對(duì)文件的讀取速度需要不定時(shí)人為處理久遠(yuǎn)的歷史版本（服務(wù)器腳本示例，注意不要復(fù)制使用，需要根據(jù)自己的項(xiàng)目確認(rèn)刪除的數(shù)據(jù)，數(shù)據(jù)無(wú)價(jià)刪除許謹(jǐn)慎：保留最近2個(gè)版本
  ls -t /path/to/dist/js/app.*.js | tail -n +3 | xargs rm -f）。

三、 使用版本號(hào)方案

通過(guò)后端更新版本號(hào)

• 運(yùn)行邏輯：后端在系統(tǒng)中開(kāi)放一個(gè)公開(kāi)接口用于接收并返回當(dāng)前版本號(hào)，前端需要給設(shè)備定義一個(gè)唯一設(shè)備號(hào)保存在瀏覽器；前端每次加載完 index.html 首頁(yè)模板后，在渲染js之前對(duì)后端發(fā)起一個(gè)版本號(hào)對(duì)比請(qǐng)求，后端日志保存前端提交請(qǐng)求的版本號(hào)與設(shè)備號(hào)并返回當(dāng)前系統(tǒng)版本，如果前端本地保存的版本與后端不一致，則前端使用Service Worker緩存控制通過(guò)workbox-webpack-plugin清除舊版本文件緩存，然后再刷新界面渲染js。

• 優(yōu)點(diǎn)：可以在發(fā)布代碼之后，通過(guò)日志查看是否有用戶依舊是老版本發(fā)起請(qǐng)求，可以通過(guò)參數(shù)查詢同一設(shè)備是否在進(jìn)入老版本后又重新進(jìn)入了新版本，同時(shí)擁有歷史日志可以判斷設(shè)備號(hào)屬于哪個(gè)用戶，并且可以人為在數(shù)據(jù)庫(kù)修改版本號(hào)來(lái)實(shí)現(xiàn)控制用戶刷新次數(shù)。

• 缺點(diǎn)：開(kāi)發(fā)測(cè)試工作量相對(duì)較大，每次發(fā)布需要人為修改數(shù)據(jù)庫(kù)版本號(hào)（或者寫成接口放在jenkins中自動(dòng)觸發(fā)）；

總結(jié) 

到此這篇關(guān)于前端發(fā)布緩存導(dǎo)致白屏幾種解決方案總結(jié)的文章就介紹到這了,更多相關(guān)前端發(fā)布緩存白屏解決內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論