Web 瀏覽器快取機制深度研究（一）：禁止快取、條件請求、Last-Modified 應用實戰

前言：快取是把雙刃劍

網路上教你「如何禁止快取」的文章滿天飛，但「瀏覽器如何利用快取、如何處理快取」的深度解析卻鮮見。本文基於實測與原碼分析，系統梳理快取行為細節。

核心問題清單

1. 如何禁止瀏覽器快取（基礎知識點）
2. 瀏覽器訪問已快取資源時，**何時發請求、何時直接用快取**？關鍵在於瀏覽器預設快取設定
3. 超連結導航到已快取資源，是否發請求？動態頁面不可快取、靜態頁面應快取，瀏覽器**如何判斷動靜態**？
4. 發請求後，Server 可能回 304 Not Modified 讓瀏覽器繼續用快取，實際效益與處理細節？
5. Server 端快取：回應內容可能是舊版本快取，如何控制？

HTTP 協定層面的快取控制標頭

HttpServlet.getLastModified() 實作指南

protected long getLastModified(HttpServletRequest req) {
    // 返回自 1970-01-01 00:00:00 的毫秒數
    // 負數表示不支援/未知
}

• 覆寫此方法返回資源實際修改時間
• Container 依此自動在回應加入 Last-Modified 標頭
• 瀏覽器下次請求帶 If-Modified-Since，Container 自動比對決定回 200 或 304

IE 快取設定對行為的影響

工具 → 網際網路選項 → 一般 → 臨時網際網路檔案 → 設定：

• 每次造訪網頁：永遠發請求（繞過快取）
• 自動（預設）：依標頭判斷，動態頁通常不快取、靜態頁快取
• 從不：永遠用快取（極危險）

絕大多數用戶用「自動」預設值，**伺服器端正確輸出快取標頭是唯一可控手段**。

動態 vs 靜態資源的快取策略

• 動態頁面（JSP/Servlet/ASP/PHP...）：
  Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Expires: 0
• 靜態資源（HTML/CSS/JS/圖片）：
  Cache-Control: public, max-age=31536000（一年）
  配合 Last-Modified/ETag 支援條件請求

下一篇預告

Server 端快取技術（頁面片段快取、資料物件快取、分散式快取 Memcached/Redis 整合）與實戰案例分析。