告別冷啟動：Cloudflare Workers、Pages 與 V8 隔離區技術解密

我第一次看到「Workers 幾乎沒有冷啟動」這句話時，直覺反應是不太相信，畢竟每次呼叫函式都要重新準備執行環境，這件事在傳統無伺服器架構裡本來就是躲不掉的成本。

後來去翻官方文件才理解，Workers 從一開始就沒有打算走容器或虛擬機那條路。這篇要把 V8 隔離區到底做對了什麼、它跟 Cloudflare Pages 是什麼關係，以及 2026 年官方對這兩者的定位講清楚。

傳統無伺服器架構最讓人無奈的，就是那句「請稍等，正在為您啟動執行環境」。Cloudflare Workers 想解決的正是這一刻。

冷啟動問題從哪裡來

多數無伺服器平台的做法，是替每個工作負載準備一份完整的容器或虛擬機，裡面帶著自己的作業系統與語言執行環境。

請求久久沒進來，這份環境就會被回收；下一個請求進來時，平台得重新把整份環境準備好，這段等待就是所謂的冷啟動。

官方文件把這件事講得很直接：容器化的行程開機，成本就是要重新載入一整份系統層級的東西，這是架構本身就帶來的代價。

V8 隔離區：不必重開機的執行單元

Workers 的做法不是替每個工作負載準備一份完整環境，而是讓一個常駐的執行環境同時容納大量輕量的隔離區。

官方文件形容，單一份 Workers 執行環境可以同時容納成百上千個隔離區，在它們之間快速切換，而不是逐一重新啟動。

• 記憶體各自獨立：每個隔離區有自己的記憶體空間，彼此看不到對方的資料，即使同一台機器上跑著其他人的程式碼也不互相干擾。
• 啟動成本只付一次：常駐執行環境的開機成本，是整份環境共用分攤，不是每個隔離區各自重新負擔一次。
• 不是永久存在：隔離區仍可能因資源調度或安全考量被回收，不適合拿全域變數當成可靠的長期狀態保存位置。

Cloudflare Pages 其實跑在 Workers 上面

Cloudflare Pages 一開始定位是靜態網站託管，帶著 Git 整合與預覽部署，對前端團隊很友善。

當你在 Pages 專案裡加上後端邏輯，也就是 Pages Functions，官方文件說得很清楚，那層邏輯執行在 Workers 之上，Workers 的執行環境特性一併帶了過來。

換句話說，Pages 更像是替 Workers 包了一層貼近前端工作流程的部署介面，底層運算模型是同一套。

2026 年該怎麼選：官方的建議起點

Workers 後來加上了原生的靜態資產託管能力，也就是可以直接在 Workers 專案裡設定要發布的靜態檔案，不必額外綁 Pages。

官方也提供了正式的「從 Pages 遷移到 Workers」指南，並指出 Workers 能用到 Durable Objects、Cron Triggers 這類目前 Pages 專案拿不到的能力。

既有 Pages 專案不必因此緊急搬家，官方也沒有把 Pages 標成棄用。但如果是全新啟動的專案，官方傾向的起點已經是 Workers。

微前端與邊緣路由：什麼時候用得上

多團隊各自維護一塊前端，是很常見的組織現實，行銷頁、會員中心、部落格常常分屬不同專案與不同部署節奏。

用一支 Worker 擋在最前面做路徑判斷，符合條件就轉發到對應的來源，使用者感受到的是同一個網域下的完整網站，各團隊背後仍然獨立部署。

這個做法的價值是部署解耦，不是單純衝效能，決定要不要導入之前，先確認團隊分工是否真的需要這一層獨立性，不然只是多一層維運成本。

落地前的三個檢查點

1. 確認要用到的功能，例如 Durable Objects 或 Cron Triggers，是不是只有 Workers 支援，Pages 專案拿不到。
2. 凡是需要跨請求可靠保存的資料，不要放在隔離區的全域變數裡，改用 Durable Objects 或外部儲存服務。
3. 多團隊共用同一網域的情境，先確認是不是真的需要邊緣路由這層解耦，再決定要不要導入。