Cloudflare Cache Rules 可按網址、Cookie、主機名稱和檔案類型決定哪些內容可進入邊緣快取。WordPress 若設定得宜，可以減少主機負載和縮短回應時間；若把會員頁、購物車或管理畫面快取，卻可能向訪客顯示錯誤內容。安全做法是先排除動態請求，再逐步快取公開頁面。
先理解瀏覽器快取與邊緣快取
瀏覽器快取保存在訪客裝置，Edge Cache 則保存在 Cloudflare 節點。兩者的有效時間可以不同。更新網站後，即使已清除 Cloudflare，訪客瀏覽器仍可能保留舊檔；設定規則時要分開考慮 Browser TTL 和 Edge TTL。
確認 Cloudflare 代理已啟用
Cache Rules 只會處理經過 Cloudflare 代理的網站流量。先檢查主網域與 www 紀錄、SSL 模式和來源網站是否正常，再觀察回應標頭。若 DNS 紀錄只作解析而沒有代理，規則即使存在也不會產生預期快取效果。
先建立動態路徑排除規則
將 WordPress 登入、後台、預覽和其他個人化路徑設為 Bypass cache。常見範圍包括 `wp-login.php`、`wp-admin`、預覽參數和網站自訂的會員中心。不要只複製範例；實際路徑可能因外掛、語言版本或安全設定而不同。
WooCommerce 必須排除交易流程
購物車、結帳、我的帳戶、加入購物車請求和付款回傳屬於動態內容。若全頁快取沒有排除，可能出現購物車數量錯誤、登入狀態混亂或付款流程失敗。先列出商店實際使用的路徑與參數，再進行訪客和會員測試。
使用 Cookie 判斷登入與購物狀態
WordPress 登入和 WooCommerce 購物流程會建立特定 Cookie。Cache Rules 可在請求包含相符 Cookie 時略過快取，避免把個人化頁面當成公用版本。條件應精確匹配必要名稱，不要因一個常見字串而排除所有請求。
規則順序由精確排除開始
較精確的 Bypass 規則應在廣泛的公開頁面快取規則前評估。建立後檢查規則順序，確認登入、購物和 API 排除沒有被其他設定抵消。每次只調整少量規則，並保存修改原因，出現問題時才能快速回復。
公開頁面不要直接無限快取
文章、分類頁和靜態頁可考慮 Eligible for cache，但仍應設定合理 Edge TTL。新聞或價格經常更新的網站要用較短時間；內容穩定的教學頁可較長。TTL 不是越長越快，過長會增加更新後清除快取的依賴。
尊重來源 Cache-Control
來源主機或快取外掛可能已回傳 `Cache-Control`。Cloudflare 可以依照來源指示，也可由規則覆蓋 Edge TTL。若來源使用 `private` 或 `no-store`，通常代表內容不適合共用快取；覆蓋前必須知道這些標頭由哪個功能產生。
分開處理靜態檔案
版本化的 CSS、JavaScript、字型和圖片適合較長快取，因為檔名或查詢參數在更新時會改變。未版本化的檔案則要保守，否則修正後訪客仍會載入舊版本。檢查主題和外掛是否正確更新資源版本。
小心處理 Query String
追蹤參數通常不應產生大量不同快取副本，但搜尋、篩選、語言、預覽和加入購物車參數會改變內容。調整 Cache Key 前先列出網站實際使用的參數。忽略錯誤參數可能把不同頁面合併成同一快取內容。
使用回應標頭檢查結果
以登出視窗連續載入同一公開頁面，查看 Cloudflare 快取狀態和 Age；再測試登入、購物車與排除路徑是否顯示 Dynamic 或 Bypass 類結果。單次載入不足以判斷，因為第一次通常需要從來源取得內容。
更新內容後精確清除
文章更新、價格調整或重要版面修改後，優先清除受影響網址。只有大規模部署或規則錯誤時才清除全部快取，因為全清會令大量訪客同時回到來源主機。若使用自訂 Cache Key，要確認單一網址清除是否符合預期。
在無痕模式測試個人化內容
分別用未登入訪客、一般會員、管理員和購物顧客測試。檢查工具列、帳戶名稱、購物車、幣別、語言和表單 nonce。任何使用者資料出現在另一個工作階段，都代表應立即停用相關快取規則並清除快取。
結語
WordPress Cache Rules 的可靠順序是：先排除後台、登入、Cookie 和交易流程，再為公開內容設定適當 TTL，最後以回應標頭及多種身份驗證。快取速度建立在內容隔離正確之上，不能以個人化資料風險換取更高命中率。
