Cloudflare 於二零二六年十月九日宣布，Workers 與 Durable Objects 支援按需 CPU 與記憶體剖析，並可在儀表板以互動火焰圖檢視、下載剖析檔。開發者亦可經 CLI 或 API 對指定版本啟動剖析，目標是在真實生產流量下找出耗 CPU、佔記憶體的函式，而不只依賴本地 DevTools。來源真實性已驗證。

對香港與亞洲以邊緣 API、即時狀態與 Agent 連接層為核心的團隊而言，這把「生產環境為什麼突然變慢／被逐出」從推測變成可重現的火焰圖證據；同時官方亦列明流量門檻、鎖定視窗與連續剖析仍在開發中等限制，採購與 SRE 應按硬數字驗收，而非只看功能名稱。

Cloudflare／官方：Workers／Durable Objects 按需 CPU 與記憶體剖析上線——互動火焰圖對準生產流量；內部案例函式加速約二點七倍、P999 記憶體降約十五 MB

Cloudflare 官方網誌於二零二六年十月九日刊出〈Introducing on-demand CPU and memory profiling with flamegraphs for Workers and Durable Objects〉，作者為 Dominik Picheta。本文已核對該一級來源所列功能入口、執行限制與內部優化案例數字，來源真實性已驗證。以下數字均屬官方自述的內部案例，並非獨立第三方基準測試。

一、核心事件：生產環境按需火焰圖

技術細節

按 Cloudflare 官方公開表述，要點包括：

• 能力範圍：可對 Workers 與 Durable Objects 啟動 CPU 或 記憶體 按需剖析；在 Workers Observability 頁面以互動火焰圖檢視，並可下載剖析檔供後續分析。官方強調最佳做法是在生產環境剖析，因為本地流量形態與規模通常無法代表線上。
• 儀表板路徑：Cloudflare Dashboard → Build → Compute → Workers & Pages → 選取 Worker → Observability → 下拉選「Flamegraph」，可設定剖析時長、選擇版本，並分別請求 CPU 或記憶體剖析。官方提醒 Worker 需要足夠流量才容易成功取樣；應選有實際負載的版本。
• CLI 示例（官方博文）： cf workers versions profile latest --worker-id "$WORKER_ID_OR_NAME" --duration-ms 5000 --profile-type cpu > worker-cpu.pprof
• API 示例（官方博文）：對 …/workers/workers/<worker_name>/versions/latest/profile 送出 JSON，例如 {"duration_ms":5000,"profile_type":"cpu"}。
• TypeScript：若 Worker 以 TypeScript 實作，應啟用 source maps，否則火焰圖可能只顯示難讀的混淆函式名。
• Durable Objects：有別於無狀態 Worker 的隨機 isolate，Durable Objects 可依名稱指定物件；執行期會把剖析請求路由到擁有該 actor 的具體機器，對該 isolate 取樣。
• 與既有本地剖析的差異：Workers 早已支援經 Chrome DevTools 做本地剖析；此次重點是對線上執行中的 isolate 取樣，且不會為了剖析而另起新 isolate，以便觀察真實生產執行。

官方亦交代內部兩則優化案例（同篇博文）：

1. R2 binding Worker 的 CPU 剖析（約五十秒時長）：表格檢視顯示 genericR2JsonReplacer 佔逾 百分之五 CPU，且函式對 JSON 樹遞迴自呼叫，與 JSON.stringify 的走訪重疊，導致嵌套五層的值被處理五次；修正後該函式加快約 二點七倍。另發現重複呼叫昂貴的 metrics()——單次呼叫約佔剖析中 百分之一 CPU——改為快取第一次結果即可節省。
2. 記憶體超限：某內部 Worker 的 P999 記憶體約 一百三十三 MB，對照 Workers 一百二十八 MB 上限，頻繁出現「Exceeded Memory」被逐出。Heap 剖析顯示 Prometheus 相關路徑約佔分配的 百分之六十六點七，雖被以為已停用，實則仍在付記憶體成本。完全移除後官方列表：P50 七十→五十四 MB、P90 九十四→七十九、P99 一百一十三→九十七、P999 一百三十三→一百一十八 MB，約留下 十 MB 頭寸低於上限。

二、技術原理深度解析

這次能力的工程含義，是把「邊緣 isolate 可觀測性」從日誌／追蹤，延伸到 V8 取樣器可看見的函式級成本：

1. 先定位「哪一個 isolate」
   Workers 會就近路由並在流量高時於單一 metal 複製多個 isolate；Durable Objects 還可動態搬遷。剖析請求因此必須回答：要哪一個版本、該版本最近在哪個數據中心跑過、isolate 是否仍載入、是否專屬該帳戶，以及（對 DO）精確的 live primary actor。官方指多數情況由儀表板代填，亦可自行呼叫 API。

2. 鎖只包住剖析器生命週期
   以 CPU 剖析為例，流程是：取得 isolate 與鎖 → 建立 V8 CPU profiler 並以約 一毫秒 間隔取樣 → 釋放鎖讓正常請求繼續 → 等待指定時長 → 再取鎖停止 → 在臨界區外序列化結果。若整段時長都持鎖，JavaScript 無法執行，剖析本身就失去意義。

3. 火焰圖與表格互補
   火焰圖以矩形寬度對應 CPU 時間或記憶體用量；官方建議多抓幾次，並用表格檢視快速找出「最常出現／最寬」的函式。這與僅看聚合延遲百分位不同：後者告訴你「慢了」，前者告訴你「慢在哪個呼叫棧」。

4. 已知限制與路線圖

   • 必須主動啟動：可能錯過短暫異常視窗。
   • 記憶體剖析只反映剖析視窗內的分配；啟動期大量配置可能看不到。
   • 官方表示已在開發 連續剖析（continuous profiling），讓樣本自動累積、之後再於儀表板探索。
     這些限制應寫進 SRE runbook，避免假設「有火焰圖＝永遠能事後重播事故」。

三、平台與生態影響

• 對 Workers 生態：可觀測性從日誌、Traces、Issues，再補上生產 CPU／記憶體火焰圖，縮短「邊緣函式暴增成本卻找不到罪魁」的排查鏈。
• 對 Durable Objects／有狀態邊緣：可對指定物件取樣，有利即時房間、租戶狀態機、長連線代理等場景對症下藥。
• 對效能與成本治理：官方以內部 R2／記憶體案例示範：即使「看似合理」的 JSON 取代器或「以為已關」的指標程式，也可能吃掉數個百分點 CPU 或把 P999 推過硬上限。
• 對工具鏈：CLI／API／儀表板三入口並列；TypeScript 專案若未開 source maps，火焰圖可讀性會大打折扣。

四、日常應用場景

1. 開發者與技術團隊

把按需剖析納入發佈後驗證：金絲雀版本若 CPU 或記憶體百分位異常，先對該版本抓五至五十秒火焰圖，對照 source maps 鎖定函式，再決定回滾或熱修。低流量預覽環境可能抓不到有效樣本，應在有真實負載的版本操作。

2. 企業與隱私敏感行業

金融、醫療、跨境合規工作負載常把關鍵 API 放在邊緣以降低延遲，同時受記憶體上限與成本約束。生產火焰圖可把「Exceeded Memory／逾時」從工單敘事變成可附檔的證據，方便變更顧問與資安問卷交代根因，而不是只貼聚合圖。

3. 一般用戶／產品負責人

若產品建於 Workers 託管後端，可要求工程團隊在重大功能上線後附上至少一次生產 CPU 與記憶體剖析摘要（最寬函式、是否開啟 source maps、對照版本號）。這不取代負載測試，但能捕捉「只在真流量路徑才出現」的浪費。

4. 香港與亞洲市場視角

香港團隊常見以 Workers 做 API 閘道、Webhook、即時狀態與 Agent 工具層，並同時面對流量尖峰與嚴格變更窗口。按需火焰圖讓本地無法重現的問題，可在最近 PoP 的真實 isolate 上取證；若貴司正把邊緣工作負載、高可用與零信任存取一併納入雲端與安全基線，可參考 YSK Limited 的雲端遷移與網絡安全：https://ysk.hk/services/cloud-security （官網刊 99.99% SLA）。

五、專業評價與潛在考量

優勢

• 一級來源為 Cloudflare Blog（二零二六年十月九日），功能入口、CLI／API 示例與內部案例數字（二點七倍、百分之五／一 CPU、P999 一百三十三→一百一十八 MB、一百二十八 MB 上限等）可逐項核對。
• 對準生產而非只本地 DevTools，符合邊緣流量「就近、多副本、DO 可搬遷」的真實拓撲。
• 與既有 Observability／Issues 能力互補：日誌說「發生了什麼」，火焰圖說「CPU／記憶體花在哪」。

需要留意的地方

• 低流量 Worker 可能難以剖析；官方明確不另起 isolate 只為取樣。
• 記憶體剖析看不到視窗外（含啟動期）分配；連續剖析尚未上線。
• 內部案例數字來自 Cloudflare 自家高流量服務，外推到小型 Worker 時幅度可能不同，應以自身剖析為準。
• 同日另有 Deno 團隊加盟消息（已另文報道）；本篇僅涵蓋按需剖析，勿與運行時合併路線圖混為同一產品公告。

結語

Cloudflare 把 Workers／Durable Objects 的生產 CPU 與記憶體火焰圖做成按需能力，並以內部 R2 與記憶體超限案例展示可量化的優化空間。對依賴邊緣執行的香港與亞洲團隊，這是可立刻寫進發佈與事故流程的觀測工具；同時應正視流量門檻、視窗限制與連續剖析仍在開發中的現實。若你需要把邊緣工作負載、可觀測性與網絡安全防護一併納入雲端基線，可參考 YSK Limited 的雲端遷移與網絡安全服務：https://ysk.hk/services/cloud-security

參考來源

1. Cloudflare Blog〈Introducing on-demand CPU and memory profiling with flamegraphs for Workers and Durable Objects〉（2026-10-09）：https://blog.cloudflare.com/workers-on-demand-profiling/
2. Cloudflare Workers Docs — DevTools／可觀測性（本地剖析既有能力對照）：https://developers.cloudflare.com/workers/observability/dev-tools/
3. 發現路徑：鎖定清單 Cloudflare Blog RSS https://blog.cloudflare.com/rss/