原問題是：
一般瀏覽器對靜態資源的快取導致的更新不及時問題，我們是怎麼處理的？有哪幾種方式？
為什麼會產生這些方式？（其實就是各種方式的優劣）
之前大家可能都知道 一般的公司對於靜態資源以及快取的處理方式無非就這麼幾種。
1 在靜態資源後面加乙個版本號 v=1.111
類似於上面這種方式。
2 為了準確的確定檔案是否修改，將後面的版本號修改為檔案摘要（主要根據檔案內容生成的乙個值）。
類似於上面這種，後面的紅框表示的部分就是根據檔案的摘要生成的key.
3 直接將資源檔名使用檔案摘要或者說某個固定的字串加上乙個檔案摘要拼接成乙個檔名。
類似上面這種方式，最後面紅圈內表示的**是根據檔案摘要來生成的，這裡需要區別和第二種方式，第二種方式是拿來放在url後面作為乙個引數，但檔名沒有改變。而這裡直接選擇修改了檔名。
那麼問題來了？ 以上三種方式的區別是什麼？為什麼最後會最終演變為第三種方式？
1 第一種方式，需要維護版本號，如果在乙個檔案中，存在多個資源，那麼沒有被修改過的資源檔案也會被修改版本號，導致不必要的資源載入。（當然，如果需要加上時間戳之類的，就已經不屬於第乙個的範圍了）
那麼發布以上兩個檔案的順序就成問題了。
如果先發資源檔案：
如果之前訪問過頁面，那就會有儲存有本地快取，那麼由於訪問的還是快取檔案，不會出現問題。但如果是新使用者，那麼就會訪問到新的資源檔案，很有可能導致頁面錯亂。而等到頁面html也發布之後，頁面又恢復了正常。
ps: 當然有的人可能會說，發布就那麼一會的時間，有必要那麼在乎這些一點點時間麼？
如果你這麼想，那麼我只能說，我無話可說。
發上兩種都是屬於覆蓋式資源發布，不管如何處理，都會存在這樣的問題。那麼解決方案就是第三種。非覆蓋式發布。
3 第三種方式，應該是最完美的解決方案：
1 首先發資源檔案，由於檔名已經不一樣了，所以不會覆蓋掉之前存在的資源檔案，客戶端依舊可以安全的訪問。
2 再發客戶端檔案，在客戶端檔案一旦發布成功，那麼就會立馬切成新的特性，中間可以做到無縫銜接。
這就是所謂的非覆蓋發布的方案。
Spring框架訪問靜態資源處理方式
spring框架訪問靜態資源處理方式 web.xml配置如下 web org.springframework.web.servlet.dispatcherservlet contextconfiglocation xml startup 1 startup web context component...
Ajax快取的幾種處理方式
當ajax請求的介面如果沒有發生變化的情況下，那麼會快取中讀取資料，不會再向伺服器請求資料，如果介面的位址發生了改變那麼會再次向伺服器請求資料 1.通過url新增字尾的方式 本來請求的位址是 home action?加查詢引數字尾後 home action?ran match.random 2.通過...
繼承同名靜態成員處理方式
問題 繼承中同名的靜態成員在子類物件上如何進行訪問？靜態成員和非靜態成員出現同名，處理方式一致。1.訪問子類同名成員 直接訪問即可 2.訪問父類同名成員 需要加作用域 include using namespace std 繼承中的同名靜態函式處理方式 class base static void ...