WordPress 物件快取會暫存資料庫查詢或計算結果，減少同一請求內重複工作。核心預設快取通常只存在於單次頁面請求；加入 Redis、Memcached 或其他持久後端後，資料可跨請求重用，降低資料庫負載和流量高峰時的回應時間。
分清不同快取層
瀏覽器快取保存訪客裝置的靜態檔；頁面快取保存完整 HTML；OPcache 保存已編譯 PHP；物件快取保存程式使用的資料物件。各層用途不同，啟用 Redis 不等於已完成頁面或 CDN 快取。
先量度真正瓶頸
記錄 TTFB、資料庫查詢、CPU、記憶體、慢請求和快取命中率。若瓶頸來自外部 API、大圖片或慢 PHP 程式，物件快取未必有明顯改善。
確認主機提供快取服務
持久物件快取需要伺服器端後端，例如 Redis 或 Memcached，不能只在 WordPress 安裝外掛便假定生效。向主機確認服務位址、連接方式、記憶體限制、持久性和監察工具。
選擇合適後端
Redis 功能完整並常見於 WordPress 主機；Memcached 結構較簡單。選擇應依主機支援、維護能力、現有架構和外掛相容性，而不是只看名稱或網上速度排行。
使用可靠 Object Cache 外掛
外掛通常透過 `object-cache.php` drop-in 連接後端。檢查維護狀態、WordPress 版本支援、多站點、群組清理和故障行為，並避免同時啟用兩個物件快取實作。
為每個網站設定獨立前綴
多個網站共用同一 Redis 或 Memcached 時，必須使用唯一 key prefix 或資料庫隔離。否則不同網站可能讀到相同鍵值，造成設定、登入狀態或內容互相污染。
保護快取服務連線
不要把 Redis 或 Memcached 直接暴露到公網。限制在本機或受控私有網絡，使用驗證及加密能力時正確設定，並把連線秘密放在受保護伺服器設定。
在 staging 先啟用
複製相近資料量和外掛組合，啟用後測試登入、編輯、搜尋、表單、會員、購物車、結帳、排程和 REST API。動態網站比純內容網站更需要完整流程驗證。
檢查 Site Health 與狀態
確認 WordPress 偵測到 persistent object cache，外掛顯示已連線，並查看命中、未命中、記憶體、淘汰和錯誤。只看到外掛已啟用不能證明後端正在工作。
理解快取必須可重建
物件快取不應成為唯一資料來源。清空或遺失後，WordPress 應能由資料庫重新建立內容，只會暫時增加負載。若清空造成資料永久遺失，代表外掛或自訂程式設計有問題。
避免頻繁全站清理
`flush all` 會同時移除大量熱資料，可能造成資料庫瞬間承受重建流量。優先使用外掛提供的精準失效或群組清理，只有故障、部署或確認需要時才全清。
監察記憶體與淘汰
快取空間不足會持續淘汰舊項目，命中率下降並增加資料庫負擔。設定合理記憶體上限和淘汰策略，監察使用量、連線數、延遲及高峰行為。
處理快取服務故障
測試 Redis 或 Memcached 停止時網站是否可降級到資料庫，而不是完全白畫面。建立告警、重啟和停用 drop-in 程序，並保留不依賴 WordPress 後台的主機存取。
配合資料庫優化
物件快取可減少重複查詢，但不會修復巨大 autoload options、缺少索引或低效外掛。持續檢查慢查詢、資料表增長和高成本請求，避免用快取掩蓋根因。
上線後比較成效
在相同流量和測試路徑比較 TTFB、資料庫查詢、CPU、命中率及錯誤。若改善有限或記憶體壓力增加，調整設定或移除，不要只因 Site Health 建議便強行保留。
參考資料
[WordPress 官方：Cache](https://developer.wordpress.org/advanced-administration/performance/cache/)
[WordPress 官方：WP_Object_Cache](https://developer.wordpress.org/reference/classes/wp_object_cache/)
