SPA頁面緩存再優化二

部署到線上的步驟：

拿到打包以後的文件，刪除服務器上的文件，再放上去的。

測試1：

更改js文件，刪除並上傳新包。

額外發現1：若是用戶在上傳期間，仍然在系統以內，此時即便將服務器上的包刪除掉，用戶不會跳出系統，只會在控制檯上報錯。

報錯內容：

只是在報錯服務器上沒有指定的html文件

額外發現2：

已經被緩存了的頁面html 剛進頁面時會進行從服務器200取到，隨後刪除服務器的包，已經被緩存下來的html頁面是能夠正常操做的。

此時再上傳新包，用戶仍然在已經緩存的頁面裏，按照老系統正常跑。訪問未緩存的頁面，再看引用的js與css文件，仍是在使用老的js與css，並非最新的，只是html由於是從服務器上取來的，因此取到的html是最新的。

在發現1的狀況下，再將刪除的包恢復，這時又能夠正常訪問了，控制檯再也不報錯，不過系統仍是在請求老的js文件。

 用戶在登陸界面上操做時，仍然這樣。

 

用戶若是點擊退出，會取到最新部署的包。

用戶點擊收藏在瀏覽器上的地址，也會從新獲取包。

用戶從新輸入網址，也會從新從新獲取包。

從官網測試連接跳轉，會從新獲取包

 

測試2：

用戶在系統以外，更新系統。是沒有緩存的。

 

綜上獲得的結論

當單頁面的系統在從新部署更新時，此時正在瀏覽網頁，而且已經在網頁內的用戶，始終會使用老的js與css文件，一直在使用已經緩存了的靜態資源。

全部的緩存問題焦點都在index.html上，只要index.html刷新便可從新獲取代碼。

解決方案：

1：在路由跳轉時即刷新index頁面

缺點：無論有沒有更新部署，頁面都會獲得刷新。

2：在打包以後的dist文件夾裏插入一個js文件，做爲版本監控，每次路由轉變/發送請求時，對這個js文件作回調，而且這個js文件，不被引入index內。

3：在服務端給予一個版本號的返回接口，每次發送請求時，先檢查版本號，版本號不正確了 就刷新頁面。

4：這是一個比較簡單又暴力的方法

 <title>XXXXX</title>
  <script type="text/javascript">
      var url=window.location.href,oldTime,roleSesstion = window.sessionStorage.getItem('partnerNo');
      oldTime = (url.indexOf('?v')==-1) ? 0 : (url.match(/v=(\S*)#\//) ? url.match(/v=(\S*)#\//)[1] : url.match(/v=(\S*)/)[1]);
      if(((new Date()).getTime()-oldTime)>600000 && !roleSesstion) {
          window.location.href = '?v=' + (new Date()).getTime()
      }
  </script>

　　

 

這個是直接在進入網站以前，在index.html頁面上加上了一個時間戳做爲版本控制，這樣就能夠在網址的請求地址上看見增長了一個參數，而因爲index頁面是被緩存的，因此加了參數請求，也只是會報304，親測有效，能夠嘗試。