Cloudflare Workflows 可以替每條流程設並行上限：超過的自動排隊不丟棄，資料庫不再被灌爆

一句話看懂：Cloudflare Workflows 現在可以替每條流程各自設定「最多同時跑幾個」，超過的會自動排隊，不會被丟掉。

先用白話講：並行上限是什麼？

想像一間只有 10 個座位的拉麵店。客人再多，店裡同時也只坐 10 個人，其他人在門口排隊，有人吃完才換下一位。這樣廚房不會被訂單淹沒，每碗麵的品質也顧得住。

Cloudflare Workflows 是 Cloudflare 提供的「多步驟背景工作」服務：把一件要做很久的事（例如匯入資料、寄一批通知）拆成好幾步，中間失敗會自動重試。每啟動一次，就是一個「執行個體」。

並行上限就是那 10 個座位：同一時間最多讓幾個執行個體一起跑。

發生什麼事

Cloudflare 在 11 月 10 日的更新日誌宣布，可以替單一 Workflow 設定並行上限。重點如下：

• 在設定檔的 workflows 綁定加上 concurrency.limit，重新部署就生效
• 超過上限的執行個體不會被拒絕，而是排隊，等前面的跑完或進入等待狀態後自動開始
• 上限必須是正整數，且不能高於帳號上限（Workers Free 是 100，Workers Paid 是 50,000）
• 調低上限不會中斷已經在跑的個體
• 沒設上限的 Workflow，仍然可以用到帳號的全部額度

這解決了什麼問題

官方提到的兩個用途正是這些：保護撐不住太多同時連線的資料庫或第三方 API，以及把負載平均分給各條流程。

給開發者的技術細節

以「同時最多 10 個」為例，在 wrangler.jsonc 這樣寫：

{
  "workflows": [
    {
      "name": "my-workflow",
      "binding": "MY_WORKFLOW",
      "class_name": "MyWorkflow",
      "concurrency": { "limit": 10 }
    }
  ]
}

• 需要 Wrangler 4.127.0 以上
• 每次部署都要帶這段設定：官方特別提醒，部署時沒帶 concurrency.limit，該 Workflow 的上限會被移除
• 依 Limits 文件，處於等待狀態的個體不計入並行數，所以流程裡在等待的那段時間不會佔位子
• 也可以設在 exports 宣告的 Workflow 上

我的看法

接案時很常遇到這種情況：背景工作本身沒問題，出事的是它呼叫的對象。小型資料庫的連線數有限，簡訊、金流、通訊軟體的 API 大多有每秒或每分鐘的流量限制，一次放太多工作出去，對方直接拒絕，還得自己寫重試和排隊。

這次更新等於把「排隊」這件事交給平台處理，設定檔加一段就好，對小團隊很實用。

要提醒的是「漏帶設定就移除上限」這個行為。如果專案有多份設定檔，或是由 CI 自動部署，建議把這段設定列進檢查項目，否則哪天上限默默消失，要等資料庫被灌爆才會發現。

名詞小辭典

• Workflow（工作流程）：把一件長時間的工作拆成多個步驟依序執行，失敗時可從中斷的步驟重試。
• 執行個體（Instance）：Workflow 每被啟動一次，就產生一個獨立的執行個體。
• 並行（Concurrency）：同一時間一起執行的數量。
• Wrangler：Cloudflare 的命令列工具，用來開發與部署 Workers 相關專案。

資料來源

• Cloudflare Changelog：Set a concurrency limit for each Workflow（2026-11-10）
• Cloudflare Workflows 文件：Limits