觀點 · 資訊分享

Cloudflare Workers 大小上限放寬到 64 MiB：免費方案不再卡 3 MB，但 1 秒啟動限制還在

Cloudflare 拿掉 Workers「壓縮後 3 MB（免費）／10 MB（付費）」的部署上限，改成只看未壓縮的 64 MiB，所有方案一樣。依賴多的框架比較好部署，但全域程式碼仍要在 1 秒內跑完。

一句話看懂：Cloudflare Workers 拿掉「壓縮後 3 MB／10 MB」的部署上限，改成所有方案都只看未壓縮的 64 MiB，大型框架比較好部署，但 1 秒啟動限制還在。

Worker 上限改成 64 MiB資訊圖卡：不管壓縮後多大，只看未壓縮的 64 MiB，免費付費同標準

先用白話講：Worker 的大小限制是什麼？

想像你要寄一箱行李搭飛機。以前航空公司規定「真空壓縮後不能超過 3 公斤」，結果大家拼命壓縮；現在改成「不管怎麼包，攤開來總重不超過 64 公斤就好」，而且經濟艙和商務艙同一個標準。

Cloudflare Workers 是一種把程式放在全球邊緣節點執行的無伺服器服務，你寫的程式和用到的套件會被打包成一個檔案上傳。這個檔案太大，部署就會被擋下來。

Cloudflare 在 9 月 4 日的更新日誌宣布：

同一天 Cloudflare 也宣布，企業方案客戶可以在網站的網路設定頁面，自行把請求內容的大小上限（Maximum Upload Size）調到最多 5 GB，不用再找客服。

部署前可以先用 dry-run 看大小：

wrangler deploy --outdir bundled/ --dry-run

輸出中的 Total Upload 是未壓縮大小，算進 64 MiB 上限；gzip 數字只是參考，已經不是限制
啟動時間：Worker 要在 1 秒內解析並執行完全域範圍（處理函式以外的頂層程式碼），超過會出現錯誤編號 10021，Wrangler 會自動產生 CPU 剖析檔幫你找原因
官方建議的瘦身方式：拿掉用不到的套件、把設定檔與大型資料改放 KV、R2、D1 或靜態資源、用 Service Bindings 把功能拆成多個 Worker

接案做小工具時，很多人會把東西放在 Workers 免費方案上，而壓縮後 3 MB 的上限一直是隱形天花板：加個 PDF 處理、Markdown 解析或 AI SDK，就可能突然部署失敗，只好開始拆 Worker 或換方案。這次改成只看未壓縮 64 MiB，對小專案是實打實的放寬。

不過大小放寬不等於可以亂塞。1 秒啟動上限還在，套件越大、頂層初始化越重，越容易在部署時被擋。我會建議把大型套件的初始化放進處理函式裡，用到再載入，也順便留意冷啟動對使用者體驗的影響。

以前的 3 MB 跟現在的 64 MiB 可以直接比嗎？

不能直接比。舊的 3 MB 是壓縮後的大小，新的 64 MiB 是未壓縮的大小。程式碼通常壓縮率很高，所以實際放寬幅度要看你的套件內容，但壓縮後的限制已經完全拿掉。

怎麼知道我的 Worker 有多大？

執行 wrangler deploy --outdir bundled/ --dry-run，輸出中的 Total Upload 就是未壓縮大小，這才是計算 64 MiB 上限的數字；後面的 gzip 只是參考。

套件塞很大會有什麼副作用？

Worker 啟動時要在 1 秒內解析並執行完全域程式碼，套件越大、頂層初始化越重，越容易超時。官方建議把初始化移到處理請求時或建置階段，設定檔與大型資料改放 KV、R2、D1。

作者

接案做系統開發、網站與主機託管。觀點裡的文章都是我自己寫的,寫的是做專案時第一手遇到的事。