**[url=
在web**中，css/js/image等靜態檔案不僅占用大量的網路頻寬，而且給伺服器端的cpu和io系統帶來極大的負載，是影響伺服器吞吐量的重要因素。要解決這個問題，乙個有效辦法是在客戶端對靜態檔案進行快取。快取有可能會導致靜態檔案不能在客戶端即時更新，而某些**恰恰需要客戶端的js/css等快取檔案必須即時更新，否則會對使用者體驗帶來影響。在web 2.0時代，這更是乙個不容忽視的問題。
那麼，怎麼樣才能實現即減少網路流量和伺服器負載，又能在必要時即時更新客戶端快取的目的呢？
啟用客戶端快取
在http/1.0的年代，可以通過設定http頭中的expires欄位來告訴瀏覽器快取的有效時間。但這個時間是在伺服器端生成，在客戶端檢驗，因此如果伺服器和客戶端的時間不同步，那就有可能產生問題。此外，在有效時間截止之前，瀏覽器會直接使用本地快取內容，不會與伺服器溝通以檢測檔案是否更新，因此會導致更新不即時的情況。
http/1.1協議引入了cache-control這個新的http頭欄位，以瀏覽器訪問伺服器時的時間為基準，用相對於這個基準的時間來作為快取應該失效的時間，這就解決了伺服器和客戶端時間不同步有可能產生的問題。在快取失效後，
快取失效後的檔案內容驗證
一旦設定的快取失效時間已到，那麼瀏覽器就需要向伺服器發出請求，來驗證伺服器端的內容是否確實做了修改。
在http/1.0年代，驗證是通過last-modified這個http頭欄位，根據檔案的最後修改時間來判斷的。但last-modified的最小時間單位是秒，所以如果檔案的修改發生在一秒鐘之內，那麼這種機制就起不到效果了。
為了解決這個問題，http/1.1協議引入了e-tag欄位，可以自定義檔案修改的標誌。apache中的e-tag預設設定為根據inode、檔案大小、最後修改時間來確定。
進行驗證時，瀏覽器把檔案的上一次修改時間或者e-tag值傳送給伺服器，伺服器根據這個值來判斷瀏覽器的快取是否需要更新。如果需要更新，那麼把檔案的內容傳送給瀏覽器，否則只傳送304頭，表示檔案為修改。
快取內容的即時更新
有些**可能會要求客戶端快取的js/css/image檔案能夠即時更新，即一旦伺服器端的檔案做了修改，客戶端在下次訪問時就能獲得更新，而不需要等快取失效。
乙個簡單的方法是給每個靜態檔案加上字尾，比如是最後修改時間作為字尾，那麼對乙個abc.jpg檔案的引用可能就變成手工生成這個字尾比較麻煩，如果**使用指令碼語言程式設計，那麼可以把引用靜態檔案的html指令碼改為動態程式語言，比如，把
禁用客戶端html檔案快取
由於版本控制或 更新造成前端 修改後沒有實施生效可能發生的情況 vue react或其他專案 更新公升級了之後 index.html檔案的檔名沒變 可是引入的css js檔名稱變了 這個時候由於nginx對靜態檔案的快取，就可能訪問出之前的老的index.html這個入口檔案 都是我們專案更新，大多...
解決客戶端快取的問題
快取分為服務端快取和客戶端快取，服務端快取一般都是讓運維去清理一下快取，剩下來的快取就需要前端或者前端和後台協同解決了。瀏覽器的快取真的是讓人又愛又恨，他可以幫助我們加快頁面響應速度，同時也會帶來開發中的困難。當瀏覽器讀取相同的檔名時，瀏覽器會去讀取快取中的檔案，而不是從服務端讀取檔案，這樣就造成了...
基於XML檔案的客戶端校驗
所謂客戶端校驗，就是在提交請求之前對使用者輸入資訊進行校驗。在struts2應用中使用客戶端校驗需要 1 將輸入頁面的表單元素全都改為struts2標籤來生成表單 2 為 action login validate true name username label username name pas...