如果你想在 Cloudflare 上部署一個 API，Cloudflare Workers 通常是最適合開始理解的產品。
小編先給結論：Workers 是一個執行 JavaScript、TypeScript 等程式的 Serverless 平台。程式會部署到 Cloudflare 的全球網路，由平台處理執行環境與擴展；你可以先從一個很小的 HTTP handler 開始，逐步加入資料庫、物件儲存、佇列或其他服務。
Workers 解決什麼問題？
傳統做法通常是準備一台或一組伺服器，讓 API 在固定的區域執行，再自行處理部署、擴展、TLS、網路與監控等工作。
Workers 把其中一部分基礎設施工作交給 Cloudflare。官方將它定位為能在 Cloudflare 全球網路上建置、部署與擴展應用程式的 Serverless 平台。
這裡的「Serverless」不是沒有伺服器，而是開發者不必直接管理那些伺服器。你主要負責程式碼、設定與它需要使用的服務。
Workers runtime 底層使用 V8，也提供許多現代 Web API。對前端工程師來說，Request、Response、URL 等介面會相當熟悉；對後端工程師來說，則可以把它理解為一個以 HTTP 請求為入口的輕量執行環境。
「邊緣執行」代表什麼？
Workers 函式會在 Cloudflare 的全球網路上執行，而不是只固定在某一台由你管理的中央伺服器。這讓它很適合處理需要靠近使用者或靠近 Cloudflare 網路入口的工作，例如：
- API 與 Webhook
- 驗證、重新導向與請求改寫
- BFF（Backend for Frontend）
- 靜態網站旁邊的動態路由
- 在請求進入後端前進行快取或基本的流量控制
不過，「邊緣」不代表每個請求都一定在地理位置上最接近使用者的機器執行，也不代表資料存取延遲會自動消失。當 Worker 需要讀取資料庫或呼叫外部 API 時，資料的位置、網路路徑與服務本身的延遲仍然重要。
因此，比較準確的理解是：Workers 讓你的程式進入 Cloudflare 的全球網路，並提供更接近請求入口執行程式的選項。
一個最小的 Worker
一個最基本的 Worker 只需要匯出一個物件，並提供 fetch handler：
export default {
async fetch(request, env, ctx) {
const url = new URL(request.url);
if (url.pathname === "/health" && request.method === "GET") {
return new Response(
JSON.stringify({ ok: true, service: "my-worker" }),
{
headers: {
"content-type": "application/json; charset=UTF-8",
},
},
);
}
return new Response("Not Found", { status: 404 });
},
};當 Worker 收到 HTTP 請求時，Workers runtime 會呼叫 fetch。這個 handler 會收到三個參數：
- request：目前的 HTTP 請求
- env：由設定提供的環境變數與服務 Binding
- ctx：與這次請求生命週期相關的執行環境
上面的範例只處理 GET /health。符合條件時回傳 JSON，其他路徑則回傳 404。這個例子刻意保持簡單，因為先理解「請求進來、程式判斷、回應出去」的流程，比一開始加入多個外部服務更重要。
用 Wrangler 建立與部署
官方目前建議可以使用 C3 建立新的 Worker 專案：
npm create cloudflare@latest -- my-first-worker
cd my-first-worker建立過程會讓你選擇範例、語言與是否部署。若只是第一次學習，可以先選擇 Hello World 範例與 Worker only 模板。
在本機啟動開發伺服器：
npx wrangler dev確認程式運作後，再部署到 Cloudflare：
npx wrangler deployWrangler 是 Cloudflare Workers 的命令列工具，負責協助建立、開發、測試與部署專案。實際部署到 workers.dev 或自訂網域時，仍要依照你的帳號與網域設定完成相關步驟。
env 與 Binding 是什麼？
當 Worker 只回傳固定文字時，env 可能還用不到；但實際應用通常需要讀取其他資源。
Workers 使用 Binding 將 Worker 與其他資源連接起來。例如：
- D1：SQL 資料庫
- R2：物件儲存
- KV：Key-Value 儲存
- Durable Objects：具狀態的協調與儲存
- Queues：非同步訊息佇列
這些服務不是直接被硬編碼成某個全球變數，而是透過設定提供給 Worker，然後從 env 取得。這種設計讓程式碼與部署環境之間的關係更清楚，也方便在本機與正式環境使用不同資源。
小編建議第一次練習時，先完成不依賴外部儲存的 API，再加入一個 Binding。這樣比較容易分辨問題究竟來自 Worker 本身、部署設定，還是外部服務。
什麼時候適合使用 Workers？
Workers 很適合以下情境：
- 想快速部署一個 API 或 Webhook endpoint
- 想在 Cloudflare 網路入口處執行驗證與請求改寫
- 想讓前端與後端 API 使用相近的部署平台
- 想逐步建立一個由運算、儲存與非同步服務組成的應用程式
- 想把小型服務拆成容易部署與獨立擴展的元件
但如果應用需要持久狀態、複雜查詢或長時間背景工作，通常不應只依賴 Worker 程式本身。這時可以依需求評估 D1、R2、Durable Objects、Queues 或 Workflows 等配套服務。
也不要把模組層級的記憶體當成可靠資料庫。Worker 的執行環境不應被視為一個永遠存活、只由你使用的傳統伺服器；需要保留的資料應交給適合的持久化服務。
建議的學習順序
如果你是第一次接觸 Workers，可以依照這個順序練習：
- 用 fetch handler 回傳純文字與 JSON。
- 使用 URL 與 HTTP method 建立簡單路由。
- 加入環境變數與 Secret。
- 選擇一個 Binding，例如 D1 或 R2。
- 加入錯誤處理、測試與日誌。
- 再評估 Durable Objects、Queues 或 Workflows 等更進階服務。
這個順序的重點不是一次學完所有產品，而是先建立一個清楚的執行模型：請求從哪裡進來、Worker 在哪裡執行、程式如何取得外部資源，以及回應如何回到使用者手上。
結語
Cloudflare Workers 的核心價值，不只是「不用管理伺服器」，而是讓 HTTP 程式可以直接成為 Cloudflare 全球網路的一部分。
先從一個只處理 /health 的 API 開始，你就能逐步理解 Runtime、部署、路由與 Binding。等這些基礎建立後，再加入 D1、R2、Durable Objects 或 Queues，會比一開始同時學習整套 Cloudflare 產品更容易掌握。
延伸閱讀：
No comments yet