Cloudflare Workers 的 _redirects：先排靜態規則，再處理動態路徑
把 _redirects 放進 Cloudflare Workers 的 Static Assets 專案後，最容易被忽略的不是 301 還是 302，而是「這一行有沒有真的被採用」。近期 Workers SDK 的公開 issue 有人回報動態規則溢出與排序造成的意外結果；它是社群的排查訊號，不代表每個專案都會發生同一個 bug。真正可依據的仍是 Cloudflare 對 _redirects 的規格：靜態規則應在前，規則數也有明確上限。
這篇要解決的是：當網站同時有舊網址、尾斜線整理與萬用字元路由時，如何讓重新導向規則可讀、可測，也能在規模變大前知道該換工具。
先判斷請求會不會經過 _redirects
_redirects 是 Static Assets 的純文字設定檔，通常會放在框架的 public/ 或 static/ 目錄，隨建置輸出一起部署。它只會套用到由靜態資產回應的請求；如果請求先交給 Worker 程式碼處理，即使路徑符合，這個檔案的規則也不會生效。
因此，遇到「本機看起來正確、部署後沒有跳轉」時，先回答兩件事：
- 這個路徑在部署環境中是靜態資產，還是由 Worker
fetch()自行回應？ - 建置輸出中是否真的包含這個
_redirects檔案？
第二點可以在 CI 的產物或本機輸出目錄確認；第一點則要回到部署架構。不要因為檔案放在 repository 裡，就假設執行期一定會讀取它。
規則順序要先靜態、後動態
Cloudflare 文件明確指出，同一來源路徑有多條規則時，最上面的規則先套用，並建議靜態 redirect 放在動態 redirect 前面。所謂動態規則包含 * splat 和 :name placeholder；它們的涵蓋範圍較大，放在前面時可能搶先匹配原本應交給精確路徑的請求。
可以把檔案刻意分成三段：
# 1. 精確的歷史網址：先放最上面/old-pricing /pricing/ 301/docs/quickstart /docs/getting-started/ 301
# 2. 有限且可預期的參數路徑/blog/:year/:slug /posts/:slug 301
# 3. 最後才放萬用字元/legacy/* /archive/:splat 301這不是保證所有路徑設計都正確，而是讓 review 時能看出每條規則的優先序。若某個精確路徑被萬用字元吃掉，調整位置比新增另一條例外規則更容易維護。
在提交前做一份小型匹配表
把想保留的入口列成表，再逐項確認預期目的地與狀態碼。這份表可以留在 PR 說明、測試文件，或交給部署後的 smoke test。
| 請求路徑 | 預期目的地 | 為什麼要測 |
|---|---|---|
/old-pricing | /pricing/ | 驗證精確規則沒有被後面的萬用字元覆蓋 |
/blog/2025/hello | /posts/hello | 驗證 placeholder 與目的地引用正確 |
/legacy/a/b | /archive/a/b | 驗證 splat 的深層路徑仍被帶入 |
| Worker API 路徑 | 原本 API 回應 | 確認沒有誤以為 _redirects 能改寫 Worker 程式碼回應 |
部署後可用不跟隨跳轉的 HTTP 請求檢查 Location 和狀態碼，例如：
curl -I --max-redirs 0 https://example.com/old-pricing這裡的 example.com 必須換成自己的測試網域；不要直接把 production 的所有舊網址交給未審核的萬用規則。
規則變多時，不要硬塞進一個檔案
Cloudflare 目前限制 _redirects 最多 2,000 條靜態規則、100 條動態規則，合計 2,100 條；每一條宣告最長 1,000 個字元。接近上限時，先盤點哪一類規則正在成長：大量一對一的歷史網址、少量參數化的路徑，或需要依條件判斷的導流。
大量一對一的 mapping 適合評估 Bulk Redirects；需要由程式根據請求決定的邏輯，則應放回 Worker 程式碼或其他明確的 routing 層。重點是讓每一層只負責自己能驗證的事，而不是把所有導流需求都堆進 _redirects。
萬用字元不是安全網
*會貪婪匹配字元。新增萬用規則前，至少測一個預期命中的路徑和一個本來不該被轉走的精確路徑；否則錯誤通常會以「某頁突然找不到」的形式才被發現。
把重新導向當成可回歸測試的路由表
這次最值得保留的做法，是把精確規則、參數規則和萬用規則分段，並為每次修改保留幾個代表路徑。當規則數接近限制或需求變成條件式導流，再遷移到 Bulk Redirects 或 Worker 程式碼。這樣出問題時，你能先確認請求是否由 Static Assets 處理、哪一條規則先匹配，而不是從頭猜部署平台是否讀到檔案。
常見問題
Q: _redirects 可以改寫所有 Worker 路由嗎？
A: 不可以。Cloudflare 文件說明，這個檔案的規則不會套用到由 Worker 程式碼回應的請求。若路由由 fetch() 處理，應在程式碼或其他 routing 設定中實作相對應邏輯。
Q: 動態規則可以放在檔案最前面嗎？
A: 語法上可以，但風險較高。Cloudflare 建議靜態規則優先；同一來源有多條規則時，最上方的規則會先套用。把廣泛的 * 或 placeholder 規則放在後面較容易檢查。
Q: 超過 _redirects 上限時該怎麼做？
A: 不要假設規則會自動擴充。先區分大量一對一 mapping 與程式化條件，再評估 Cloudflare Bulk Redirects 或把明確邏輯放進 Worker。遷移前要保留既有路徑的測試表。
參考資料：
回報錯字、失效連結，或告訴我你想看的延伸主題。