訪客瀏覽器
誰在回應：同一部裝置的 browser cache。
常見現象：只有這部裝置舊；私人視窗或另一裝置可能不同，但登入、貨幣與 session 也會影響。
先做：DevTools hard reload；私人視窗只作線索。
WooCommerce 更新後仍見舊價？Cloudflare 清 URL 後要驗的三層快取
WooCommerce 更新完成，產品頁仍見舊價、舊庫存或舊版面。很多團隊第一反應是再 purge Cloudflare；但有時清了邊緣仍舊，因為清錯層，或 origin 本身已是舊內容。
本文只處理更新後的快取殘留；未更新或要驗收單路徑，先讀 staging 隔離清單 與 更新後回歸測試。
先看邊界
purge 是移除快取副本，不是修正內容。 origin 的價格、庫存、模板或資料庫未更新，清幾次 CDN 都不會變正確 [2]。
先分清三層快取
應用程式／頁面快取
誰在回應：主機頁面快取、外掛、object cache、片段快取。
常見現象：後台已更新，前台 HTML 仍舊；CF-Cache-Status 可能是 MISS、BYPASS 或 DYNAMIC。
先做：清頁面快取，檢查排除規則。
Cloudflare CDN
誰在回應：Cloudflare 邊緣節點。
常見現象：多個網絡位置仍舊；purge 後首個請求回 origin。
先做：按實際 URL purge，核對 cache key。
Origin 是來源，不是快取層。 先把資料與版面改對；但後台正確不等於前台 HTML 正確。purge 會移除邊緣副本，之後請求向 origin 取最新版本並重新加入 [2]；瀏覽器副本不受影響 [3]。
更新後排查：由來源（origin）往外，不要由 purge 開始
編輯建議：以下次序是為避免重複清錯層，不是 Cloudflare 或 WooCommerce 規定的流程。
- 先確認 origin 資料。後台核對售價、庫存、SKU、可變選項與模板／區塊狀態；錯了先修。後台正確不等於前台 HTML 正確。
- 驗前台生成的 HTML。用主機預覽／origin 檢查工具或已授權 staging，核對新價格、SKU 或版本標記；不要在正式站用繞過快取或安全控制的 query 參數。
- 先清應用程式／頁面快取。只清受影響頁面，確認外掛／主機排除規則，再重驗前台 HTML；這一步要在 Cloudflare purge 之前。
- 記錄 URL 與 Cloudflare 標頭。記下 locale、路徑、query；看
CF-Cache-Status、Age、Cache-Control。HIT 表示邊緣回應；MISS 表示當下無副本、向 origin 取；BYPASS／DYNAMIC 表示未被 Cloudflare 快取 [4]。Age只是副本在快取內的時間，會因 revalidation／purge 重置，不是內容版本；BYPASS／DYNAMIC 可能帶 origin 的 Age [4]。 - 按 URL purge，不要先 purge everything。Cloudflare 建議 single-file（by URL）[1]。路徑大小寫有別，host 轉小寫；query、locale 版本逐一確認 [2]。
- 自訂 cache key 要補 headers／cookies。缺少 header／cookie 會以空值處理該 cache key 部分；可用 API 帶齊，或改用 prefix／tag／purge everything [2]。Cache Rule 只匹配 GET 時，也可能不匹配 PURGE [2]。
- 重取並核對內容。purge 後可能先 MISS、其後 HIT，取決於並發請求、cache eligibility 與位置，不是固定次序 [2][4]。HIT 不代表舊，MISS 不保證最新。仍舊就回查 origin／頁面快取；必要時才 purge everything，留意 origin 壓力 [6]，不要連續 purge [7]。
- 瀏覽器層只作線索。私人視窗／另一裝置會受登入、貨幣、地區、session 影響，不能單憑差異斷定 cache。優先在 DevTools hard reload／disable cache；清除網站資料會登出並可能失去購物車。Edge purge 不清瀏覽器 [3]。
手機版：由來源往外排查
- 1. Origin（來源）
不是快取層；先看後台價格、庫存、SKU 與模板。後台正確不等於前台 HTML 正確。
- 2. 應用程式／頁面快取
先清受影響頁面並重驗前台 HTML，然後才處理 Cloudflare。
- 3. Cloudflare CDN
看
CF-Cache-Status；Age只代表快取時間，不是內容版本。按 URL purge；cache key 要補 headers／cookies。 - 4. 訪客瀏覽器
用 DevTools hard reload／disable cache；私人視窗只作線索，登入、貨幣、地區與 session 也會造成差異。
驗證：核對實際價格、SKU、庫存或版本字串，不要只看 HTTP 200。
仍見舊內容：回查 origin 與頁面快取，不要連續 purge；MISS 再 HIT 不是固定次序。
五個常見誤判
不要盲快取購物車、結帳與帳戶
WooCommerce 官方要求把 Cart、My Account、Checkout 排除在頁面快取之外，因為它們顯示當前顧客與購物車的專屬資料 [5]。任何按 session、登入、貨幣、語言或客戶群變化的回應也一樣：先確認 exclusion、cookie 與 cache key，不確定就不要放進共享 HTML 快取。
更新後要重核 Cloudflare Cache Rules、主機頁面快取與外掛的排除規則。錯誤快取購物車／結帳頁可令顧客看到過期內容或舊總額，個人化狀態亦可能出錯 [5]；這不是清一次 CDN 可以補救的效能問題。
編輯建議：若懷疑共享快取涉及購物車、結帳或帳戶內容，先修正 bypass／exclusion，再清受影響共享副本，並用兩個獨立 session 重測；不要只用 purge 當修復政策。本文不主張你已發生這類事故。
更新後快速記錄表
| 項目 | 記錄甚麼 | 用途 |
|---|---|---|
| URL | 完整路徑、query、locale | 避免清錯變體 |
| 預期內容 | 新價格、SKU、庫存或版本字串 | 不靠「感覺」判斷 |
| 瀏覽器 | 相同登入／貨幣／地區下停用快取重載結果 | 排查 browser cache |
| 頁面快取 | 外掛／主機 purge 結果 | 分辨 application cache |
| Cloudflare | CF-Cache-Status、Age | 分辨 edge cache |
| 來源（Origin） | 後台資料與模板狀態 | 確認來源正確，不是快取層 |
把每次更新的 URL、預期內容與 purge 範圍寫在同一張表；下一次更新時，先看上一次的記錄，不要靠記憶。
常見問題
清了 Cloudflare，為何仍見舊價？
先後台、前台 HTML、頁面快取，最後看 CF-Cache-Status。HIT 可能是另一 cache key 變體未清；MISS／BYPASS 問題可能在 origin 或頁面快取 [2][4]。
purge 後見到 MISS 再 HIT，是否未清乾淨？
不一定。可能先 MISS 再 HIT，但並發、eligibility 與位置影響次序 [2][4]。HIT 不證明新鮮，MISS 不保證最新；核對內容。
可以只清產品頁 URL 嗎？
可以，Cloudflare 建議先用 by URL [1]；但你要清的是實際回應的完整 URL，並考慮 query、locale 與自訂 cache key。若快取規則含 header／cookie 或只匹配 GET，單一 URL purge 未必覆蓋 [2]。
購物車、結帳與我的帳戶可以快取嗎？
不應。官方要求排除 Cart、My Account、Checkout [5]；個人化回應同樣。若已共享快取，先修政策再清副本重測。
瀏覽器快取要怎樣清？
優先 DevTools hard reload／disable cache；私人視窗只作線索（登入、貨幣、地區、session）。清網站資料會登出、可能失去購物車。Edge purge 不清瀏覽器 [3]。
Age 可以判斷內容新舊嗎？
不可單憑 Age。它是副本在快取內的時間，會因 revalidation／purge 重置；BYPASS／DYNAMIC 可能帶 origin Age [4]。核對價格、SKU、庫存或版本字串。
來源
更新後，先分清是哪一層快取
Managed-WP.™ PRO 提供 WordPress 專業代管服務。若你正處理 WooCommerce 更新後的舊價、舊版面或快取殘留，先把 URL、預期內容、頁面快取與 Cloudflare 狀態記錄下來，再按實際環境與團隊確認支援範圍。
前往客戶入口編輯說明：本文由 Managed-WP.™ PRO 編輯團隊根據上述官方文件整理；標示「編輯建議」的內容是實務建議，不是 Cloudflare、WooCommerce 或主機商的保證。版本、介面與快取行為可能變更，請以你的實際環境及供應商文件為準。