關於瀏覽器的緩存，有了Etag，last-Modified還有必要存在嗎???

01-13

Last-Modified與ETag是可以一起使用的，伺服器會優先驗證ETag，一致的情況下，才會繼續比對Last-Modified，最後才決定是否返回304。現在我知道因為last-modified只能精確到秒級所以etag才比last-modified的優先順序高，如下圖所示

可現在我的問題主要是：etag都不同了，last-modified肯定也不同了吧，沒有必要再判斷啊，覺得有些多此一舉，求解惑....

你的理解和圖都錯了。

圖上說的「Etag? -&> 否」是指沒有 ETag，而不是 ETag 不同。

而圖上的錯誤則是，RFC 規定，如果 ETag 和 Last-Modified 都有，則必須一次性都發給伺服器，沒有優先順序。

最後，如果伺服器輸出了 ETag，沒有必要再輸出 Last-Modified。

lm 的問題不在於精確程度而在於一致性。比如客戶端服務端時間一直性，比如負載均衡設備之間的一致性。這些問題使我們傾向於只使用etag 而不是lm。所以基於此未來確實可以幹掉 lm。因為沒人喜歡他

Google之

我也是Ted ：Etag是lastModifed的補充，有些動態生成的內容就可以用hash做etag控制緩存了

生成Etag是需要後台寫一個演算法生成的，比如取文件的hashCode或MD5，多一點運算。

取文件的lastModified更快，並且是web伺服器自動支持的。默認使用lastModified，有需要的情況下才用Etag，什麼是有需要的情況？下面提供一個場景：

同一url的資源，在不同條件下返回不同的內容：

一個後台管理系統，提供換膚功能，當皮膚從「質感」換到「扁平」時，實際上是切換了一個css，頁面上大部分控制項的樣式都改變了，變為了「扁平」風格，

但發現&標籤引入的圖片沒有被css調整為"扁平"風格的，

如：界面左上角的logo圖，界面右上角的默認頭像，圖片404錯誤的替代圖，某幾個icon……

怎麼讓這些圖片換掉？我們的做法是

後台對特定路徑的圖片資源的訪問進行監聽，根據當前選擇的皮膚返回不同的圖片。

同是&

在「質感」皮膚下，返回的是伺服器上 /web/zcms/resources/raised/404.png

在「扁平」皮膚下，返回的是伺服器上 /web/zcms/resources/flat/404.png

既然對瀏覽器來說圖片路徑沒有變化，那是不是直接在緩存里取出來就成了？換扶效果還能完成嗎？

這時候就要祭出Etag，將圖片文件的hashCode作為Etag值返回。raised/404.png 和 flat/404.png 的hashCode是不同的，換膚後瀏覽器一看resources/404.png文件頭裡Etag和緩存的不一樣，就知道不能用緩存里的了，要去伺服器上取新的圖片。

Etag比lastModified更加嚴謹，如果資源發生變化，Etag就會發生變化，就會把最新的資源給客戶端返回去，而lastModified不識別s（秒）單位里的修改，所以如果資源在s（秒）單位里發生了修改，那lastModified也不會發生改變，這樣如果只用了lastModified，客戶端得到的資源就不是最新的；但是設定了Etag之後，每次客戶端發出請求，服務端都會根據資源重新生成一個Etag，對性能有影響

Etag是lastModifed的補充，有些動態生成的內容就可以用md5做etag控制緩存了

lastmodified只是更省事