微信的登錄，掃二維碼碼之後，可以通過微信給的code去(qù)獲取用戶的微信信息，顯示出對應的帳号列表（列表頁），選擇登錄之後跳轉至相應的頁面。
測試的時候發現，如果在跳轉後的頁面，點擊浏覽器返回，還是會顯示登錄帳号列表。這時候登錄是會失敗的，因爲已經登錄過，沒有了半登錄态，應該需要重新掃碼登錄才行。
所以列表頁是完全不能被緩存的，而浏覽器的前進後退，默認會從緩存裏讀取，完全不發請求。
打開Chrome的開發者工(gōng)具調試的時候發現，如果勾選Network的Disable cache，浏覽器後退的時候，結果頁不會被緩存。如果不勾選則緩存頁面。用戶是不會主動開啓這個選項的，所以需要通過Headers控制頁面的緩存。
Request
勾選與不勾選Disable cache的差别在于
Request Headers的Cache是否會被設置爲Cache-Control: no-cache、Pragma: no-cache
Response
有設置Cache爲Cache-Control: no-cache, must-revalidate。但是爲什麽頁面還是會緩存了呢？
而Request爲浏覽器發送，不能進行設置，隻能從Response着手。
解決方案爲設置Cache爲Cache-Control: no-store, no-cache, must-revalidate
no-cache與no-store
“no-cache”表示必須先與服務器确認返回的響應是否發生(shēng)了變化，然後才能使用該響應來滿足後續對同一(yī)網址的請求。因此，如果存在合适的驗證令牌 (ETag)，no-cache 會發起往返通信來驗證緩存的響應，但如果資源未發生(shēng)變化，則可避免下(xià)載。
相比之下(xià)，“no-store”則要簡單得多。它直接禁止浏覽器以及所有中(zhōng)間緩存存儲任何版本的返回響應，例如，包含個人隐私數據或銀行業務數據的響應。每次用戶請求該資産時，都會向服務器發送請求，并下(xià)載完整的響應。
再次觀察頁面的請求，發現雖然設置了no-cache，但是沒有設置ETag可以進行校驗，最終還是從緩存裏讀取。
關于HTTP，還是需要不斷的學習，才能深入理解并使用。
