Cloudflare Workers 可在請求到達 WordPress 主機前執行 JavaScript 或 TypeScript，適合處理重導、標頭、簡單路由、驗證和邊緣回應。它不是 WordPress 外掛，也不會直接存取 PHP 執行環境。程式若修改錯誤的請求、Cookie 或快取設定，可能破壞登入、API 和結帳，因此要把用途維持精確。
選擇適合放在邊緣的工作
短而可預測的邏輯最合適，例如舊網址重導、主機名稱正規化、特定標頭、維護頁或輕量 API 代理。需要 WordPress 使用者權限、資料庫內容或複雜商業規則的工作，通常仍應留在來源應用。
理解 Request 與 Response 流程
Worker 的 `fetch` handler 接收 Request，檢查 URL、方法和標頭，再回傳 Response 或以 `fetch()` 送往來源。傳入 Request 多數屬性不可直接修改；改寫時應建立新的 Request，並保留必要內容。
建立測試 Worker
先用控制台、Playground 或 Wrangler 建立測試專案，將路由放在測試子網域。不要第一個版本便套用整個正式網域。測試正常頁、404、查詢參數、登入和 API，再逐步縮小或擴大路由範圍。
以網址物件安全分析路徑
將請求 URL 解析成結構化物件，再比較 hostname、pathname 和 search parameters，避免以寬鬆字串包含造成誤匹配。路徑大小寫、結尾斜線、編碼字元和多語言前綴都要列入測試。
重導要選擇正確狀態碼
永久搬遷才使用永久重導，短期活動、測試或尚未確認的改動應使用暫時重導。避免同時由 Worker、WordPress、外掛和來源伺服器建立相同規則，否則容易出現循環或多次跳轉。
保留查詢參數前先分類
分析參數、搜尋、篩選、語言和付款資料作用不同。重導時可保留必要參數，移除已確認無用的追蹤參數；不要一律清空，也不要把敏感參數轉送到不同網域。修改前建立白名單和測試案例。
小心轉送 Cookie 與 Authorization
Worker 可讀寫標頭，但登入 Cookie、Authorization 和應用程式憑證屬於敏感資料。若程式自動跟隨到另一個主機名稱的重導，標頭可能被一併轉送。跨網域請求應使用手動重導策略並建立明確允許清單。
不要錯誤快取動態 WordPress
只有 GET 和 HEAD 類請求適合一般快取考慮，登入、購物車、會員頁、預覽和帶個人 Cookie 的回應要繞過。Worker 可修改 cache key 和 TTL，但不能因追求命中率便忽略來源的 private 或 no-store 意圖。
與 Cache Rules 分清責任
簡單網址和 TTL 條件優先使用 Cache Rules，較複雜的程式化處理才用 Worker。兩者同時存在時，要知道哪一層先決定快取和哪些設定會覆蓋。每條規則記錄擁有者，避免日後只修改其中一邊。
為失敗保留來源回退
邊緣程式應處理例外並回傳可理解結果。若非必要功能失敗，可安全轉回原始請求；安全驗證失敗則應拒絕而不是默默繞過。避免無限遞迴呼叫自己或因來源逾時持續重試。
使用環境變數保存設定
網域、功能開關和非敏感配置可放在環境設定，密鑰則使用 Secret。不要把 API token、WordPress Application Password 或付款憑證寫入程式碼和版本庫。正式與測試環境使用不同 Secret。
設定相容日期和版本管理
Workers runtime 會隨平台更新，專案應設定 compatibility date，程式碼保存在 Git，部署前查看差異。不要只在控制台直接修改而沒有版本紀錄。每次部署都保留可快速回復的已知良好版本。
監察錯誤、延遲與請求量
查看 Worker 日誌、例外、CPU 時間、來源回應和狀態碼分佈。重導暴增可能是循環，來源請求下降也可能是錯誤封鎖而非快取成功。為登入、結帳和 API 建立獨立合成測試。
先在少量路徑灰度上線
從單一舊網址、測試文章或內部子網域開始，確認 SEO、快取和轉換無異常，再擴展到整組路徑。重大路由修改選擇低流量時段，並準備停用 route 或回復版本的程序。
結語
Workers 與 WordPress 配合的可靠原則是：把短而無狀態的邏輯放到邊緣，將身份和資料庫規則留在來源。精確匹配路徑、保護敏感標頭、避免快取動態頁，再以版本、監察和灰度部署控制風險。
