廚房裡常備的醬油與鹽，大多數人會放在灶台邊，不會每次要用都跑一趟儲藏室。瀏覽器裡的快取（Cache）做的正是同一件事，把等一下很可能還會再用到的資料先存在手邊，下次要用就不必重新跟來源要一次。也因為如此，「清除快取」聽起來像是把這些東西整批丟掉，不少人一聽就有點猶豫。
多數人只在網頁跑版、當機，或懷疑自己看到舊內容時，才想到要清除快取。但有人照著教學清了瀏覽器裡的快取，問題卻還是沒解決，原因就在於快取分成 2 層，一層在使用者自己的裝置上，由你自己管；另一層在網站那端的伺服器與 CDN 上，歸網站經營者管，清掉自己那份不代表對方那份也跟著清空。
快取是什麼？瀏覽器與伺服器之間的暫存機制
快取，簡單說就是把「等一下多半還會再用到的資料」預先存起來，下次要用時直接從手邊拿，不必重新跟資料的來源要一次。這份定義聽起來單純，但它同時發生在兩個完全不同的位置，搞清楚是哪一層，才知道問題該找誰處理。
MDN 在《Cache-Control header》這份文件裡，把快取明確分成 2 種。第一種是 private cache（私有快取，也叫 local cache 或 browser cache），存在於使用者自己的裝置上，可以為單一使用者存放個人化的內容。第二種是 shared cache（共用快取），存在於來源伺服器與使用者之間，例如 Proxy、CDN 這類中介角色，它儲存的是單一份回應、給多個使用者共用的內容。也因為是共用的，個人化內容原則上不該放進 shared cache，放了會有外洩給別人看到的風險。私有快取歸使用者自己能管，共用快取則要靠網站經營者處理，這組分類也決定了誰該負責解決哪一層的問題。
瀏覽器端與伺服器端快取暫存的內容並不相同
私有快取跟共用快取，不只是存放位置不同，存的東西也不一樣。瀏覽器裡的私有快取，存的多半是 HTML、CSS、JavaScript、圖片這類靜態資源的複本，也就是一個網頁組成畫面所需要的各種檔案。網站那一端的共用快取，存的則是網站經營者要管的東西，伺服器把整頁 HTML 或某個資料庫查詢的結果先算好、存起來，或是 CDN 把資源的複本放到離使用者更近的節點上。
Cloudflare 在《What is Caching？》這份說明裡指出，瀏覽器每次載入網頁都要下載相當多資料，為了縮短載入時間，瀏覽器會把網頁大部分內容存到裝置的硬碟上，下次再開同一個頁面，大部分內容已經在本機，頁面自然會快很多；這些檔案會一直留著，直到 TTL（存活時間）到期，或硬碟的快取空間滿了，使用者也可以自己動手清掉。同一份說明也定義了 CDN 快取，CDN 把圖片、影片、網頁這類內容，快取在比來源伺服器更靠近使用者的 proxy 伺服器上，使用者發出請求時，CDN 會先看自己有沒有存這份內容，有（cache hit）就直接給，沒有（cache miss）才去跟來源伺服器要，拿到之後存一份，下次就能直接用。光是 Cloudflare 自己，在全球就有 335 個以上的城市設有這樣的節點。
快取新鮮度決定瀏覽器是否重新請求資料
存起來的東西不會就這樣一直被拿來用，每一份快取內容都有新鮮（fresh）與過期（stale）之分。新鮮的回應可以在後續請求裡直接重複使用；過期之後不能原樣照用，得跟來源伺服器重新驗證（revalidate）一次，確認資料有沒有變動。這也是為什麼快取有時候會自動更新，你完全不需要動手去清。
MDN 的定義裡，max-age=N 這個指令表示一份回應在產生後 N 秒內都算新鮮；而 no-cache 常被誤會成「不要快取」，實際上它的意思是可以存，但每次重複使用前都要先驗證過，真正的「不要存」要用 no-store 才對。web.dev 在《使用 HTTP 快取，避免不必要的網路要求》裡補充了驗證的具體做法，伺服器可以用 ETag（內容的雜湊值指紋）或 Last-Modified（以時間判斷）告訴瀏覽器「你存的那份跟我現在這份是不是同一份」，如果相同，伺服器只需要回傳一個很小的 304 Not Modified 回應，不必把整份內容再傳一次。這一套驗證機制，正是「為什麼有時候明明清了快取，還是看到舊內容」以及「快取會自己更新」背後的技術原理。
快取的核心目的是減少向伺服器重複要求資料的次數
快取存在的理由其實很直接，透過網路去要一份資源，既慢又耗資源。web.dev 在《使用 HTTP 快取，避免不必要的網路要求》這份文件裡開頭就點出，大型回應要在瀏覽器和伺服器之間多次來回傳輸，一個頁面得等所有重要資源都下載完才能真正載入完成。如果使用者用的是有流量限制的行動數據方案，每一次不必要的網路請求，都是在花使用者自己的錢。
瀏覽器的 HTTP 快取，就是擋掉這些不必要請求的第一道防線。文件裡也老實承認，這不是最強大或最有彈性的做法，但它有一個很大的優勢，所有瀏覽器都支援，而且不需要額外的開發工作就能生效。對一般使用者來說，這代表網頁載入得更快；對用行動數據上網的人來說，感受尤其明顯，少下載一次就是少花一次流量。
一般使用者該清瀏覽器快取的三種情境
清除快取不是網路故障的萬用重灌大法，而是有幾個明確、有效的使用時機。Google 官方在《清除快取和 Cookie》這份說明裡，列出建議清除快取和 Cookie 的 3 個理由。第一，解決網站載入或格式設定的問題，瀏覽器存的那份舊資源，如果跟網站現在實際的版本兜不起來，畫面就容易出現跑版、樣式跑掉、按鈕位置不對這類異常。第二，確保造訪的網站是最新版本，明明網站內容已經更新，畫面卻還是舊的，多半就是瀏覽器手上那份複本還沒過期。第三，釋出裝置的本機儲存空間，快取存久了會占用不少硬碟或手機容量，清掉能立刻讓出空間。
這 3 種情境，分別對應 3 種你自己就能感覺到的現象：畫面跑版或按鈕位置跑掉、明明改了卻怎麼整理都看不到最新版本、裝置容量亮紅燈。判斷的關鍵很簡單，遇到上面 3 種情境之一再清就好，平常不需要沒事就清一次。
Chrome、Firefox 與 Safari 清除快取的操作位置
知道什麼時候該清之後，接下來是操作本身。以下 3 款常見瀏覽器，清除快取的入口都藏在隱私設定裡，路徑各不相同。
Chrome 透過刪除瀏覽資料視窗清除快取與 Cookie
Chrome 電腦版清除快取的路徑，照 Google 官方說明是：開啟 Chrome，點右上角的「更多」圖示，選「刪除瀏覽資料」，接著選擇要清除的時間範圍（例如「過去 1 小時」或「不限時間」），勾選要移除的資訊類型，最後按「刪除資料」就完成。
有個小細節值得留意，如果是在登入 Chrome 帳號的狀態下刪除 Cookie，Chrome 會自動重新整理 Google 的登入 Cookie，讓登入狀態繼續維持，所以真的要把 Google 的 Cookie 一併清掉，得先登出 Chrome 帳號再操作。Google 也提供了一個更快的捷徑，直接在網址列輸入「刪除瀏覽資料」，點擊跳出的動作選項，就能直接開啟那個清除視窗，不用再一層一層點選單。
Firefox、Safari 各自的清除路徑
Firefox 的路徑跟 Chrome 不太一樣。根據 Mozilla 官方支援文件《How to clear the Firefox cache》，操作步驟是：點選選單按鈕，進入「設定」，切到「隱私與安全性」面板，在「Cookie 與網站資料」區塊點「清除資料」，時間範圍選「全部」，並確認只勾選「暫存的快取檔案與頁面」，不要連其他項目一起勾，才不會把登入狀態也一起清掉。快捷鍵在 Windows 是 Ctrl+Shift+Delete，Mac 是 Cmd+Shift+Delete。
Safari 則分電腦版跟行動版。根據 Apple 官方支援文件，Mac 版是在 Safari App 裡點「歷史記錄」，選「清除歷史記錄」，或是到「管理網站資料」逐一或整批移除；iPhone 跟 iPad 版則是進「設定」，點「App」，選「Safari」，再選「清除瀏覽記錄與網站資料」。3 款瀏覽器的入口位置雖然不同，但邏輯都一樣，先找到隱私或安全性相關的設定，快取清除選項就藏在裡面。
清除瀏覽器快取後，首次重新載入通常比平常慢
清完快取之後，不少人第一次重新整理網頁，會發現畫面比平常慢一點，甚至有些網站要求重新登入，這些都是正常現象，不代表操作出了差錯。
Google 官方說明列出清除快取和 Cookie 之後會發生的 2 件事，第一是網站上部分設定會被清掉，例如原本已經登入的網站，得重新輸入帳號密碼再登入一次；第二是圖片等內容必須重新下載，部分網站的載入速度可能會變慢。Cloudflare 在《What is Caching？》裡補充了背後的機制，瀏覽器快取被清空之後，接下來每個載入的網頁，對瀏覽器來說都像是第一次造訪這個頁面一樣，因為本機沒有任何存檔可以直接拿來用，所有資源都得重新跟伺服器要一次，這正是清除瀏覽器快取之後，載入速度暫時變慢的原因。
不過這個變慢只是暫時的。只要繼續正常瀏覽，瀏覽器會把用到的資源重新存回快取，原本先存起來、下次直接用的效果會慢慢恢復，通常瀏覽個幾頁，速度就會回到清除之前的水準。
快取和 Cookie 儲存的是不同種類的資料
快取跟 Cookie 常常出現在同一個清除介面裡，兩個選項並排勾選，不少人因此以為它們是同一件事，清了快取等於把所有網站都登出。實際上兩者存的東西完全不同。
Google 官方說明分別對兩者下了定義：「Cookie 是您造訪過的網站所建立的檔案，這類檔案會儲存瀏覽資料，提供更便捷的上網體驗」；「快取會暫存部分網頁內容（例如圖片），下次您造訪時便能加快網頁開啟速度」。簡單說，Cookie 存的是使用者是誰、登入狀態與偏好設定，快取存的是網頁本身的資源複本，兩者職責不一樣。也因為這樣，同一個網站的顯示異常，有時候光清快取不夠，得連 Cookie 一起清掉才會真的生效，這也是為什麼清除介面常常把兩者放在一起讓人一次勾選。
清除快取不會刪除網站本身，也不會讓頁面消失
清除快取不會把網站內容也一起清掉，這是不少人常見的疑慮。快取存的一直都只是本機端的複本，清除它，頂多是讓瀏覽器改成重新跟伺服器要一份資料，網站在伺服器上的實際內容完全不受影響。
Cloudflare 對這個效果的說明很直接，瀏覽器快取一旦被清空，之後載入的每個網頁，都會像使用者第一次造訪這個頁面一樣。重點是重新載入，不是內容消失。網頁本身仍然完整存在於伺服器上，只是使用者這一端暫時沒有現成的複本可以直接用，得多下載一次而已。合起來看就是一句話，清除快取只是讓瀏覽器多跑一趟去要資料，不是把資料從網站上刪掉。
瀏覽器快取歸使用者管，伺服器、CDN 快取歸網站經營者管
前面談的都是使用者自己裝置上的私有快取。如果你是網站經營者，伺服器與 CDN 那端的共用快取才是你要負責的另一條線，光叫訪客清瀏覽器快取，很多時候根本解決不了問題。
MDN 對 shared cache 的定義是，它存在於來源伺服器與使用者之間，例如 Proxy、CDN 這類中介角色，儲存的是單一份回應，重複提供給多個使用者使用。這代表就算某個使用者把自己的瀏覽器快取清得再乾淨，只要 shared cache 那一層還在提供舊版本的回應，所有訪客，不只是清過快取的那一位，看到的都會是同一份舊內容。這種情況得由網站經營者主動處理，不是叫使用者清快取就能解決的。
伺服器快取把整頁 HTML 預先產生並儲存備用
伺服器快取在做的事，是把原本需要即時運算（讀資料庫、跑程式邏輯）才能生成的頁面，先算好、存成靜態檔案。下次同樣的請求進來，伺服器直接把存好的檔案送出去，不必再重新跑一次運算，回應速度自然快很多。
以 WordPress 為例，官方開發文件對核心的物件快取（Object Cache）有明確定位，它的用途是省下對資料庫的往返查詢，把快取內容存在記憶體裡，用一組 key 命名，方便之後取用。不過文件也指出一個常被忽略的細節。預設的物件快取，set() 方法不使用到期時間($expire)參數，因為快取「will automatically expire for each time a page is accessed and PHP finishes」，也就是每次頁面請求跑完，這次累積的快取就自動清空，不會保留到下一次請求。
CDN 節點快取讓資源從離訪客最近的地方送出
伺服器快取解決的是同一台主機不用重複運算，CDN 快取解決的則是另一個問題，訪客不用千里迢迢連到主機實際所在的地方。
Cloudflare 的說明裡，CDN 把內容快取在比來源伺服器更靠近終端使用者的 proxy 伺服器上，因為距離更近，CDN 能更快把內容送出去。請求命中快取（cache hit）時，直接由 CDN 節點回應；沒命中（cache miss）才會去問來源伺服器，拿到內容之後在 CDN 存一份，供下一次使用。這些快取內容會一直留在 CDN 裡，直到 TTL 到期，或是被使用者手動清除（purge）。伺服器快取跟 CDN 快取疊在一起，才是完整的多層快取架構，一層省運算，一層省距離。
WordPress 內建物件快取預設非持久，只在單次請求內有效
如果你的網站是用 WordPress 架的，「明明改了內容，前台還是沒變」這個困擾，會比其他平台更常遇到，原因就出在上一節提到的那句原始碼註解。
WordPress 官方開發文件寫得很清楚。核心的物件快取，set() 方法不使用到期參數，是因為快取每次頁面請求跑完就會自動清空，這是 WordPress 核心的預設行為，不是外掛或主機的問題。換句話說，WordPress 開箱即用的快取，只在單次頁面請求的執行過程中有效，這次執行完就歸零，不會保留到下一次有人造訪。要讓快取內容能跨請求保留（persistent），得額外接上 Redis、Memcached 這類外部物件快取，或是安裝頁面快取外掛，把整頁輸出存成靜態檔案。
WordPress 另外還有一套 Transients API，運作邏輯不太一樣。官方文件〈Transients〉說明，這套機制是透過 set_transient()，把資料連同到期秒數一起存進資料庫的 wp_options 資料表，到期之前都能用 get_transient() 取回。不過文件也提醒，Transient 有可能在到期時間之前就先消失，例如換了物件快取的實作方式，或資料庫升級，所以程式設計上應該要有拿不到就重新產生的備援邏輯。這兩份文件合起來說明一件事，WordPress 沒有開箱即用、能跨頁面保留的快取，網站經營者得裝快取外掛或接上持久物件快取，才能真正省下重複運算。
網站更新後，快取只清異動範圍即可
網站內容一有更新，不少經營者的直覺反應是把整站快取全部清空，也就是常說的 Purge Everything。這個做法能確保訪客立刻看到最新內容，但代價也不小，所有節點都得強迫重新跟來源伺服器要一次資料，短時間內會拖慢載入速度，等於把省下重複運算的好處先犧牲掉一輪。
Cloudflare 官方文件〈Purge cache〉列出好幾種清除方式，包括依單一檔案（也就是依網址）清除、依 cache-tag 清除、依主機名稱清除、依網址前綴清除，以及清除全部。文件把依單一檔案清除列為建議做法。邏輯很直接，一次更新通常只動到某幾個網頁或某段路徑，把那些網址對應的快取清掉就夠了，其他還新鮮、沒被異動到的內容不受影響，不用跟著陪葬。這種精準清除，比整站清空更不會造成短暫的全站變慢，也是多數 CDN 服務不分方案等級都支援的基本功能。
會員專屬頁面沒設定成私有快取，資料可能外流給其他訪客
最後一個提醒，比內容沒更新更嚴重，也更容易被忽略，如果網站因人而異的個人化內容，不小心被放進共用快取，可能會被送給別的訪客看到。
web.dev 在《更新 HTTP 快取，藉此提升安全性和隱私防護》這份文件裡給出明確建議。要保密個人化的回應，得做 2 件事。第一，防止 Proxy、CDN 這類中介快取存下這份資源，做法是設定 Cache-Control: private；第二，如果回應內容會因為 Cookie（例如登入憑證）而不同，要設定 Vary: Cookie，讓快取知道這份回應不能原樣拿去重複使用。文件也直接點出風險所在：「當資源存取權因 Cookie 而異時，風險就會升高。如果未採取預防措施，中介快取可能會針對未使用 Cookie 要求的請求，傳回使用 Cookie 要求的回應」。白話說，就是某位使用者登入後看到的個人化頁面，如果被中介快取存了下來，有可能被原樣送給沒登入、甚至是另一位使用者看到。
這份文件建議，高流量、會處理個人資料的網站，應該把這件事排進優先檢查項目，預設就要明確定義好 Cache-Control 跟 Vary，不要讓系統用隱含猜測的方式決定一份回應該不該被快取、能不能被共用。
快取做的事，其實就是把先存起來、下次直接用這份方便，拆成使用者跟網站經營者各自要處理的兩塊。作為一般使用者，遇到畫面跑版、內容看起來過舊，或裝置空間吃緊，清一次瀏覽器快取通常就能解決，清完偶爾變慢一下也是正常現象，很快就會恢復。作為網站經營者，光靠使用者清快取，解決不了伺服器端和 CDN 端的問題，更新內容之後精準清除異動範圍、把個人化頁面的私有快取標頭設定好，才是真正該做好的事。下次再看到「清除快取」這個選項，至少能分清楚它清的是哪一層，能不能解決眼前遇到的狀況。