前端提緩存策略的話，無非就是瀏覽器對資源的緩存。HTTP緩存策略只是為了解決客戶端和服務端信息不對稱的問題而存在的，客戶端為了加快速度會緩存部分資源，但是下次請求時，客戶端不知道這個資源有沒有更新，服務端也不知道客戶端緩存的是哪個版本，不知道該不該再返回資源，其實就是一個信息同步問題，HTTP緩存策略就是來解決這個問題的。
緩存示意圖
- 大致流程
- 瀏覽器第一次請求的時候，本地如果沒什么緩存都沒有。會先加載資源，緩存到本地。
- 第二次請求的時候，瀏覽器很具這個資源的http頭信息來判斷是否緩存過期（強緩存）。如果沒有過期（有強緩存，也可以使用強緩存）就直接拿本地緩存，不會發送請求。
- 如果沒有強緩存，或者強緩存已經過期，進入協商緩存，瀏覽器和服務器去協商當前緩存是否可以用。
- 協商緩存是，瀏覽器會把資源請求發送給到服務器，服務器來判斷瀏覽器緩存是否是可用。如果服務器匹配上，返回304，告訴瀏覽器，是可以使用的。瀏覽器拿到這個狀態，繼續從緩存加載資源。
- 如果未命中協商緩存，服務器和瀏覽器沒有匹配上，那就返回最新的資源給到瀏覽器，并更新緩存。
強緩存
- 看是否是強緩存，statue是否是200，并且資源是否from memory cache/disk cache。如果是基本上可以定位是強緩存。
- 強緩存有兩個關鍵字段，expires和cache-control兩個字段控制。
- expires是絕對時間，cache-control是相對時間。之所以有了expires，還要出cache-control字段，是因為有可能服務器和本地的時間是不一致的，因此需要后面cache-control：max-age=10，如果等于10，代表10s以后，就失效。如下圖，這個就是一個強緩存。
image.png
協商緩存
- 如果匹配不到強緩存，這時候就需要請求服務器，需要服務器來判斷當前瀏覽器的緩存是否有效。
- 協商緩存有etag和last-modified兩個字段。
- last-modified相對應的有一個 if-modified-since屬性，if-modified-since是客戶端發起的，把上次服務器返回的last-modified的值帶上，一起發送給服務器，交由服務器去判斷這個 緩存是否可以。
- etag相對應if-none-match屬性，if-none-match和上面的道理一樣，是客戶端發起，把上次服務器返回的etag帶上，一起發送給服務器。
- 由于last-modified的時間沒辦法精確到毫秒，所有會有一些時間上的誤差，因此etag的優先級是最高的，etag可以理解為git提交的版本號一樣，是獨一無二的，只有資源修改了，才會生成一個tag出來。
image.png
image.png
