Cloudflare Workers Error 1102 怎麼查？先分 CPU 與記憶體

先分清楚 CPU time 和記憶體#

Cloudflare 的 Workers limits 文件目前列出每個 isolate 128 MB 的記憶體限制；CPU limit 則依方案與設定而異。這些是平台條件，不應硬編碼成應用程式的唯一安全邊界；部署前仍要重新查看官方 limits 頁面與目前方案設定。

從回報 1102 的 invocation 開始#

先把同一次失敗的資訊保存下來：

• request path、HTTP method、部署 version 或 script name；
• 發生時間、status、輸入大小和是否為特定 tenant／使用者；
• Workers Logs 顯示的 CPU、exception 或 resource 欄位；
• 失敗前是否經過 JSON parse、影像／文件轉換、SSR 或多次 subrequest。

接著建立一個最小的輸入矩陣，而不是只重送原本那個 production request：

Cloudflare 建議用本機 DevTools CPU profile 找 CPU-heavy code，也可用記憶體 profile 觀察配置與保留物件。量測時要把 parsing、transformation、serialization 分開記錄；只量整個 fetch() 的總時間，通常看不出是哪一段超過限制。

CPU 路徑：減少同步工作#

如果 invocation log 顯示 CPU 隨輸入或某個功能一起上升，先檢查程式在網路呼叫前後做了什麼。fetch() 的 network wait 不等於 CPU time；真正會消耗 CPU 的是呼叫前後的迴圈、解析、轉換和序列化。

優先順序可以是：

1. 避免同一份資料重複 parse、normalize 或 stringify。
2. 資料形狀允許時，用 indexed lookup 取代每筆都掃完整陣列。
3. 大型集合拆成有上限的 batch，不要在一個同步迴圈中處理全部資料。
4. 穩定且可重用的計算結果放入合適的 cache，但先確認失效和一致性策略。
5. 單一 request 不應承擔長時間工作時，改用 Queue、Workflow 或另一個執行邊界。

如果工作本來就是 CPU-bound，且仍符合單一 request 的產品需求，可以評估 paid plan 的 CPU-time 設定。調高上限後要用同一組輸入重新測試；方案變更不能替無上限迴圈、過大的同步轉換或應該非同步化的工作背書。

記憶體路徑：先抓 buffering#

最容易造成 isolate memory 壓力的程式，通常看起來很直白：把 request body 讀成完整字串或 ArrayBuffer，再建立一份大型 JSON object，最後又同時保留轉換後結果。若輸入大小不受控，這幾份資料可能在同一時間存在。

下面是應用程式層的簡單輸入護欄；10 MiB 只是示例政策，不是 Cloudflare 的平台上限：

1
const MAX_BYTES = 10 * 1024 * 1024; // application policy, not a platform limit
2
const contentLength = Number(request.headers.get('content-length') || 0);
3

4
if (contentLength > MAX_BYTES) {
5
  return new Response('Payload too large', { status: 413 });
6
}
7

8
// For an unknown content length, enforce the same limit while reading request.body.

Content-Length 不一定存在，也不應被當成唯一防線。未知大小的 body 要在讀取 stream 時累計 bytes，超過應用程式政策就停止；格式允許時使用 ReadableStream 或 TransformStream，避免同時保存完整輸入和完整輸出。也要檢查 global scope 是否意外保留大型陣列或跨 request 累積的快取。

若 request 在 Worker 執行前就因 edge、zone、API 或 origin 的 request-size limit 被拒絕，那是 413 路徑，不是 1102 記憶體錯誤。相反地，Worker 已被呼叫並在處理資料時超過 runtime resource limit，才應沿著 1102 的 CPU／memory 路徑排查。部署前的 startup 問題則是另一個範圍，可參考 Wrangler check startup 的 bundle 與全域初始化排查。

用邊界矩陣驗證修正#

修正後不要只看一次成功 response。至少保留以下證據：

如果改完後 1102 次數下降，這是有用的訊號，但仍要檢查下一個更大 payload、錯誤回應是否可預期，以及 log 是否能保留下一次定位所需的 resource 資訊。不要只把成功率改善解讀成「記憶體問題已永久消失」。

判斷 Error 1102 的核心順序很簡單：先分類，再量測，最後才改程式或方案。CPU 問題要減少同步工作、分批或拆出執行邊界；記憶體問題要限制資料量、串流處理並縮短大型物件的生命週期。Workers Logs 加上一組可重現的輸入邊界，才足以支持下一步決策。

常見問題#