有兩種:
在這種機制下，瀏覽器會先尋找本地緩存，如果命中，就不會向服務器請求，會返回壹個200狀態碼，並附上磁盤緩存或內存緩存的字樣。
在該機制中，強緩存失效後，瀏覽器會用緩存標識符向服務器發送請求，服務器根據標識符決定是否使用緩存。
第壹點是“瀏覽器會帶有緩存logo”。這個標誌是什麽？有兩種。
嗯，原則上現在凡是用nginx的基本都會自動實現ETag和Last-Modified，也就是說這部分實現機制已經是默認了！妳不需要處理它。
好了，問題來了。如何處理前端SPA應用的緩存問題？
現在的SPA不是Vue就是React或者Angular。
默認情況下，我們會看到:
即所有資源第壹次進入緩存，然後第二次進入緩存。如無意外，協商緩存將被執行。
SPA緩存之所以有問題，是因為index.html是304，所以客戶端讀取的可能是本地的沒有修改，所以繼續讀取本地磁盤緩存。
怎麽解決問題？
這裏有壹個特點。SPA是webpack打包的，壹般默認會有壹個contenthash值，也就是當對應的文件發生變化時，這個contenthash值會發生變化，然後打包的文件名也會發生變化，也就是說只有發生變化的文件才會改變文件名，沒有變化的文件不會發生變化。
如果需要處理特殊文件，比如為文本類型的文件設置較長的緩存時間或者其他，可以參考上面的語法，單獨添加映射。
修改後，服務nginx重新加載，瀏覽器可以看到不同之處:
Index.html始終為200，它直接從服務器讀取，而所有其他靜態文件都從內存或磁盤緩存讀取。
好的，那麽如果接下來有更新，可以想象改變的文件是
由於index.html壹直請求服務器，所以獲得的portal js壹定是最新的，也就是說如果沒有變化，它就取本地強緩存，如果有變化，它就請求最新的，然後請求就取本地強緩存。
問題解決了。
解決前端SPA緩存問題: