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

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

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

方案二： 首頁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)點： 單頁面應(yīng)用設(shè)置首頁模板強制不緩存，用戶瀏覽器不會緩存 index.html 文件，每次都會向服務(wù)器拉取新的首頁模板，確保用戶不會使用歷史模板。
• 缺點： 用戶不緩存首頁，每次都會拉取，導(dǎo)致每次進入系統(tǒng)都會等待相對較長的時間。

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

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

• 運行邏輯：每次發(fā)布 jenkins 時不刪除上一個版本的js文件，直接將新的js放在原有目錄下，達到新老版本js共存的目的，當(dāng)用戶使用瀏覽器緩存的界面讀取老版本的js不會因為文件不存在而報錯。等待用戶瀏覽器識別到更新后會更新到新版本。

• 優(yōu)點：
  用戶不會因為發(fā)布拿不到j(luò)s文件而白屏，基本可以解決因為發(fā)布緩存而白屏的問題。

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

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

三、 使用版本號方案

通過后端更新版本號

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

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

• 缺點：開發(fā)測試工作量相對較大，每次發(fā)布需要人為修改數(shù)據(jù)庫版本號（或者寫成接口放在jenkins中自動觸發(fā)）；

總結(jié) 

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

最新評論