話不多說，這個坑就是：瀏覽器緩存。前段時間在一個平臺上線前的一個晚上，在做最後的業務檢查時發現進入游戲頁面時一個白屏bug，看了以後是js控制的頁面高度變為0所以沒顯示正常。。。嚇得我趕緊改了一番，按照流程在上線前是要走QA的，然而這時候測試妹紙已經累的不行先回去了（這幾天累的有點病）。於是沒回去的 ...
話不多說，這個坑就是：瀏覽器緩存。
前段時間在一個平臺上線前的一個晚上，在做最後的業務檢查時發現進入游戲頁面時一個白屏bug，看了以後是js控制的頁面高度變為0所以沒顯示正常。。。
嚇得我趕緊改了一番，按照流程在上線前是要走QA的，然而這時候測試妹紙已經累的不行先回去了（這幾天累的有點病）。於是沒回去的幾個人自己測一通，咦沒什麼問題，好走你!上線!
於是過了一天平臺正式對外時公司有人測出還是白屏。。。
又檢查了一遍代碼，做了些修改後走測試後上線了。我讓運維同志幫忙刷cdn，不過有些人還是不正常顯示，話說這個游戲頁面是前後端混合開發的，我準備在php頁面改js時間戳時被組長制止，說讓後端改。於是後端改了時間戳後大家都說正常了。
所以說改時間戳是最靠譜的做法啦。
說完了故事來總結一下吧：
1.可以在頁面頭部讓瀏覽器別緩存本頁面資源，每次打開都是直接訪問伺服器獲取，（不過是只有部分瀏覽器支持，然而也很少人這麼做，所以大家知道下就好）：
2.通俗的講，平時工作中說的加時間戳不一樣是加一個一大段代表某個時候的數字，而是加一個區別於修改前的版本就好，因為加了以後瀏覽器會把他當一個新文件對待而不去拉取緩存，例如原來是：
修改後你可以這樣加：
- <!-- 方式一 --> <!-- 方式二 -->
當然並不局限於js，css/媒體資源都可以或者都需要這麼做。
3.瀏覽器緩存是web緩存中的一員，關於他的詳細介紹我這菜雞還是不說了，找了一篇文章。
摘抄一段：
哪些請求不能被緩存？
無法被瀏覽器緩存的請求：
- HTTP信息頭中包含Cache-Control:no-cache，pragma:no-cache，或Cache-Control:max-age=0等告訴瀏覽器不用緩存的請求
- 需要根據Cookie，認證信息等決定輸入內容的動態請求是不能被緩存的
- 經過HTTPS安全加密的請求（有人也經過測試發現，ie其實在頭部加入Cache-Control：max-age信息，firefox在頭部加入Cache-Control:Public之後，能夠對HTTPS的資源進行緩存，參考《HTTPS的七個誤解》）
- POST請求無法被緩存
- HTTP響應頭中不包含Last-Modified/Etag，也不包含Cache-Control/Expires的請求無法被緩存
