Cloudflare Worker 從 1MB 漲到 64MB：免費版跟付費版同規格，這 64 倍空間能塞什麼？

一句話總結：Worker 部署上限統一為 64 MiB 未壓縮體積，免費版與付費版同規格；塞什麼、不能塞什麼、與純靜態站的關係，一次整理。

做過 Serverless 專案的人都遇過那個瞬間：功能寫完了，wrangler deploy 敲下去，紅字告訴你 bundle 超過上限。接下來的兩小時不是在寫程式，是在跟 webpack 套件分析圖搏鬥，把一個本來就該存在的依賴拆成動態載入，只為了擠進那條線。

Cloudflare 在 2026 年 9 月 4 日的 changelog 裡改寫了這條線。官方文件現在寫的是：Worker size 上限 64 MiB，未壓縮體積，免費方案與付費方案同規格，而且沒有壓縮上限這回事。

舊制是怎麼卡的

改版前，免費方案的 Worker 壓縮後上限是 1MB，付費方案 10MB。注意關鍵詞：壓縮後。Cloudflare 量的是 gzip 之後的體積，這催生了一整套壓縮黑科技：把 JSON 打包成 base64 字串再自己解、依賴樹手動 tree-shake、甚至有人用自訂字典先壓一遍。

我不是說那些技巧沒有價值，而是它們解決的是平台的人為限制，不是真實問題。你花在擠壓縮率的每一分鐘，本來可以拿去寫功能。

新制的三個重點

第一，64 MiB 是未壓縮體積。所有壓縮技巧一夜失效，因為 Cloudflare 只看你 bundle 展開後的大小。反直覺嗎？其實更誠實了：以前 gzip 之後 0.9MB 的 bundle，實際執行時在記憶體裡展開可能是 8MB，平台收下你，V8 引擎照樣要扛那 8MB。

第二，免費方案第一次跟付費方案同規格。64 MiB 橫跨兩個方案，沒有「付費解鎖更大的包」這件事。

第三，官方文件同時提醒：更大的 bundle 會影響 startup time。這句話很重要，後面會回來。

同一批公告的另一面

帳要兩面記。同一波平台調整裡，D1 免費方案的額度也收緊了。一邊放大部署空間、一邊縮減資料庫免費額度，Cloudflare 在把免費層的形狀從「儲存」往「運算」搬。具體數字以官方 D1 文件為準，免費專案如果有依賴 D1 的，這次值得檢查一遍。

64MB 時代，社群往邊緣搬了什麼

以前 1MB 的世界裡，能塞的是一個手寫的路由、幾個 fetch、禱告依賴別太多。64MB 的世界完全不同，而且真正的受惠者是 WebAssembly：過去一個 25MB 的 wasm 模組連付費方案的 10MB 壓縮上限都上不了船，現在直接整包進場。

Wasm 大件解禁，這是 64MB 的主戰場。 SQLite 編譯成 wasm 後可以直接住在 Worker 裡，libsql 這類分支把讀取延遲壓到零跨網路。社群甚至有人把 PocketBase 整個後端編譯成 wasm 塞進 Worker，一個「資料庫加認證加即時 API」的小型後端就在邊緣跑起來，這場實驗的討論串還在官方 repo 裡。圖片編解碼（resvg 這類 SVG 轉 PNG 的 wasm）本來就是 Workers 的招牌應用，現在還有空間塞得更肥。

自架 Chat 前端整包進場。 以 NextChat 為代表的自架 ChatGPT 前端，架構是靜態頁面加一支 API 代理 Worker，這個模式在 Cloudflare 上早就成熟；LobeChat 這類插件生態更大的選擇也有免資料庫的客戶端模式可以走 Pages。64MB 之前，前端 bundle 加上依賴常常撞牆，現在整包部署是常規操作。

Cron Triggers 定時工，免費方案就有。 Workers 內建排程觸發，五分鐘到一天任你排。典型的定時工：RSS 摘要聚合、監控告警打 Webhook、資料庫定時備份到 R2、快取預熱、價格監控。這些過去要開一台小 VPS 跑 crontab 的工作，現在一支 Worker 加一行 cron 設定就搞定，而且不用管機器活著沒。

媒體處理的誠實帳。 FFmpeg.wasm 的核心大約 25 到 32MB，bundle 層面 64MB 確實塞得下。但塞得下不等於跑得動：Worker 的 128MB 記憶體與 V8 isolate 的執行模型，讓完整的影音轉檔在 Workers 上仍然窒礙，社群的實測結論也是輕量操作可行、重活兒要另請高明或改用專門的轉檔 API。把這段放進來，是因為「bundle 上限放寬」最容易讓人以為所有 wasm 都能跑，這裡是邊界。

不壓縮的大框架。 Next.js 風格的完整 server bundle、重量級 SDK 群，這些「正常大小」的東西終於可以正常部署。已經有人實測 6MB 以上的壓縮包順利上線，放進新制完全不是問題。

三個沒變的東西

64MB 是部署上限，不是性能護身符。三個舊限制原封不動：

Worker startup time 上限 1 秒。官方文件說得很白，bundle 越大啟動越慢，塞滿 64MB 的 Worker 冷啟動表現自己負責。

執行記憶體 128MB、CPU 時間上限，都沒有跟著漲。塞得下不等於跑得動。

對純靜態站來說

老實說，這條新聞對我自己的主站沒有直接影響。calpa.me 是純靜態的 Astro 站，架在 Cloudflare Pages 上走 Git 自動部署，不部署任何 Worker script。靜態資產的限制走的是另一張表：每個版本 20,000 個檔案、單檔 25MiB，我的 360 頁遠遠碰不到。

但它在觀察名單上。Cloudflare 最近把 Pages 的能力持續收編進 Workers 生態，部署上限統一化之後，「靜態站改走 Workers Builds」這條路的可行性又高了一些。之前寫過 Cloudflare Pages 的部署實踐和 Birthday Week 2026 的總整理，這次的上限調整可以視為那條收編路線的又一塊磚。

什麼時候值得遷移？等 Cloudflare 公布 Pages 的淘汰時程，或者本站真的需要 D1、Durable Objects 這類運算功能的那天。在那之前，純靜態的奢侈就是：平台的軍備競賽與我無關。

上線前的檢查清單

如果你的專案還在 1MB 時代的壓縮黑科技裡掙扎，這次升級的檢查順序是：先把所有「為了壓縮而生」的駭客手法拆掉（base64 打包、自訂字典、動態載入美化），因為它們不再有回報；接著確認 bundle 未壓縮體積真的在 64MB 內，wrangler deploy 的輸出會直接告訴你數字；最後跑一次冷啟動測試，大 bundle 的 startup time 是新制的隱形成本。

1MB 時代我們學會的是怎麼把東西變小，64MB 時代要學的是怎麼問：塞這麼多，啟動還快嗎？

限制放寬從來不是免費的，它只是把判斷的責任從平台還給開發者。這種帳，值得用實測慢慢記。

如果你的專案也在 Cloudflare 生態裡，歡迎寫信到 partner@calpa.me 交流部署心得，或到 GitHub 看更多實驗。