Cloudflare 開發者平台總覽：邊緣運算與 Workers 入門 | Cloudflare 完整教學

這是 Cloudflare 完整教學系列的第一篇。在正式動手寫 Worker 之前，我們先鳥瞰整片地圖：什麼是邊緣運算（Edge Computing）、為什麼 Cloudflare Workers 值得你投入、V8 Isolates 如何做到近乎零的冷啟動，以及 Bindings 生態如何把 KV、R2、D1、Durable Objects、Queues 與 AI 串成一個完整的開發者平台。

前言

Cloudflare Workers 是一個部署在 Cloudflare 全球 330+ 個節點上的無伺服器（Serverless）邊緣運算平台，讓你的程式碼在離使用者最近的地方執行。

如果覺得抽象，可以這樣類比：傳統的雲端架構像是全國只有一間位於台北的總店，無論你人在哪裡，點餐都得專程跑一趟台北；而邊緣運算則像是把分店開遍全台每一個街角——你走到樓下就能取餐。程式碼不再擠在單一資料中心，而是被複製到全世界的網路邊緣節點（Point of Presence，簡稱 PoP），哪裡有請求，就在哪裡就近回應。

為什麼這件事重要？因為距離就是延遲。一位台灣的使用者去存取部署在美國東岸的服務，光是網路封包來回的往返延遲（Round-Trip Time，簡稱 RTT）就可能超過 150 毫秒，這還沒算上伺服器實際處理的時間。當你的應用需要多次來回（登入、查資料、載入頁面），這些延遲會層層堆疊，使用者感受到的就是「卡卡的」。集中式架構還有另一個痛點：面對突發流量時，單點的擴展成本高、可用性也脆弱。邊緣運算把這兩個問題一次解決——就近運算降低延遲，全球分散天然具備高可用與抗流量突波的能力。

這篇導論屬於「廣度優先」，目標是讓你在腦中建立整個平台的地圖，深入的子題會留給後續文章逐一展開。讀完本篇，你會掌握：

• 邊緣運算與 Cloudflare Workers 的定義，以及它解決了什麼問題
• 為何 V8 Isolates 能做到小於 1ms 的冷啟動，這和 AWS Lambda 差在哪
• Bindings 生態的設計哲學，以及 KV、R2、D1、DO、Queues、AI 各自的定位
• 整個 Cloudflare 開發者平台的全貌，以及本 50 篇系列的學習路線

核心概念

平台全貌：一張圖看懂 Cloudflare 開發者平台

Cloudflare 開發者平台不只是「一個跑函式的服務」，而是以 Workers 為運算核心，向外延伸出儲存、非同步、AI 與前端托管的完整生態。整張地圖大致長這樣：

┌──────────────────── Cloudflare 開發者平台 ────────────────────┐
│                                                              │
│   ┌──────────── 運算核心 ────────────┐                        │
│   │   Workers（V8 Isolates）         │  ← 你的程式碼在這裡執行  │
│   │   Durable Objects（有狀態協調）   │                        │
│   └──────────────┬──────────────────┘                        │
│                  │  透過 env.XXX（Bindings）存取               │
│      ┌───────────┼───────────┬───────────┬──────────┐        │
│      ▼           ▼           ▼           ▼          ▼        │
│  ┌───────┐  ┌───────┐  ┌───────┐  ┌────────┐  ┌────────┐    │
│  │  KV   │  │  R2   │  │  D1   │  │ Queues │  │   AI   │    │
│  │鍵值儲存│  │物件儲存│  │SQLite │  │非同步  │  │邊緣推理│    │
│  │       │  │(無出口)│  │關聯式  │  │訊息佇列│  │  LLM   │    │
│  └───────┘  └───────┘  └───────┘  └────────┘  └────────┘    │
│                                                              │
│   ┌──────────── 非同步 / 編排 ────────────┐                   │
│   │  Queues（訊息佇列）Workflows（多步驟） │                   │
│   └───────────────────────────────────────┘                 │
│                                                              │
│   ┌──────────── 前端 / 托管 ────────────┐                     │
│   │  Pages（全端框架）Assets（靜態資源）  │                     │
│   └─────────────────────────────────────┘                   │
│                                                              │
└──────────────────────────────────────────────────────────────┘

這張圖的重點只有一句話：Workers 是計算核心，其他一切都透過 Bindings 掛載上來。 理解了這個結構，後面 49 篇文章你就知道每一塊拼在哪裡。

值得強調的是，這些服務並不是各自獨立的產品「拼盤」，而是共享同一套執行環境與計費模型的整合平台。你不需要為了加一個資料庫去另一個雲商註冊帳號、設定 VPC、串接網路——在 Cloudflare 上，加一個 D1 資料庫或一個 R2 儲存桶，只是在設定檔多寫幾行、跑一次 wrangler 指令的事。這種「一站式」的整合體驗，正是它相較於自行拼裝 AWS 各項服務最大的差異。

為何選 Cloudflare Workers

市面上的 Serverless 選項不少——AWS Lambda、Vercel Functions、Deno Deploy 等等，為什麼值得特別花 50 篇文章來學 Cloudflare Workers？可以歸納成四個理由：

• 極速冷啟動：得益於 V8 Isolates（下一節詳談），Workers 幾乎沒有冷啟動問題，這對需要穩定低延遲的 API 至關重要。
• 全球原生分散：一次部署，程式碼自動活在全球 330+ 個節點上，不需要為每個地區手動配置。
• 完整平台生態：從資料庫、物件儲存、佇列到 AI 推理，全部整合在同一個平台、同一套工具鏈裡，不用東拼西湊。
• 對開發者友善的計價：Free 方案每天 10 萬次請求足以支撐一個小型專案上線；Paid 方案每月 5 美元起，且沒有出口頻寬費用——這對回傳大量資料（如檔案下載、串流）的服務是巨大的成本優勢。

這四點加起來，讓 Workers 特別適合 API 服務、身份驗證中介層、A/B 測試、短網址、請求代理與轉換等場景。當然它也有不適合的地方（例如長時間 CPU 密集運算、需要長駐的 TCP 伺服器），這些界線我們會在文末的心智模型與後續文章中一一釐清。

V8 Isolates：一句話點出差異

Workers 的所有特性——極速、便宜、全球分散——都源自它的執行模型：V8 Isolates（隔離區）。

一般的 Serverless 平台（例如 AWS Lambda）以**容器（Container）**或 microVM 為執行單位，每次冷啟動都得建立環境、啟動 runtime、載入程式碼，最快也要 100ms 以上。而 V8 Isolates 完全不同：

V8 進程本身始終在運行，建立一個新的 Isolate 只是在既有進程內分配一塊獨立的記憶體上下文，冷啟動時間小於 1ms。

一個 V8 進程可以同時運行成千上萬個 Isolates，每個 Isolate 之間記憶體完全隔離、互不干擾。這就是為什麼 Workers 能做到近乎零的冷啟動、極低的記憶體基線，又能安全地服務眾多租戶。

其中「按 CPU 時間計費」是很多人忽略的關鍵：Worker 等待 KV、D1、fetch() 等 I/O 回應的時間不計費。對 I/O 密集型的 API 服務來說，實際帳單往往遠低於 Lambda。舉個具體的例子，一個請求可能總共花了 450 毫秒才回應完，但其中真正消耗 CPU 的 JavaScript 執行只有 8 毫秒，剩下的都在等資料庫和外部 API——按牆上時鐘時間計費的平台會收你 450 毫秒的錢，Workers 只算那 8 毫秒。

順帶一提，Isolate 的隔離不只帶來效能，也帶來安全性。每個 Isolate 擁有完全獨立的記憶體空間，Isolate A 的變數無法被 Isolate B 讀取或竄改，惡意程式碼也無法跨越邊界攻擊其他租戶。這讓 Cloudflare 能在同一台機器上安全地服務成千上萬個不同客戶的 Worker，同時維持極低的隔離成本——這是傳統以「一個容器一個租戶」思維設計的平台難以企及的密度。

Bindings：把整個生態串起來的膠水

如果 Isolates 是引擎，那 **Bindings（綁定）**就是把引擎接上整個平台的傳動軸。

Binding 是 Worker 與外部資源之間的一個「具名連接」。你不用在程式碼裡寫任何 Account ID、API Token 或連線字串——這些底層憑證由 Cloudflare 在執行期注入，程式碼完全看不到。你只需要透過 env 物件上的名稱來存取資源：

// env.CACHE 就是一個 KV Binding，底層憑證你永遠碰不到
const value = await env.CACHE.get("my-key");

截至 2026 年，Workers 支援 20 多種 Binding。以下是你在本系列會反覆遇到的核心成員：

這些服務單獨看都只是一項功能，但透過 Bindings 掛在同一個 Worker 上，就能組合出強大的應用：用 D1 存資料、KV 當快取層、R2 放使用者上傳的檔案、Queues 處理背景任務、Workers AI 做智慧摘要——全部在同一段程式碼、同一個邊緣節點裡協同運作。

Bindings 的設計還有一個常被忽略但極為實用的好處：同一個綁定名稱在不同環境指向不同資源。你在開發、測試、正式環境都寫 env.DB，但底層的 D1 資料庫可以是三個不同的實例。程式碼完全不用改，只要在設定檔切換環境即可。這讓「一份程式碼、多環境部署」變得自然而然，也避免了把正式環境的連線字串誤寫進程式碼的風險。至於真正敏感的密鑰（例如第三方 API Token），Cloudflare 提供 Secrets 機制，透過 wrangler secret put 加密儲存，同樣以 env.XXX 的形式在程式碼裡使用，但絕不會出現在設定檔或版本控制中。

關鍵術語速記

• PoP（Point of Presence）：Cloudflare 的邊緣節點，全球 330+ 個。
• Isolate：V8 的獨立執行實例，Workers 的執行單位。
• Binding：Worker 存取外部資源的具名安全通道，掛在 env 上。
• wrangler：Cloudflare 官方 CLI，用來開發、部署與管理 Worker。
• fetch handler：處理 HTTP 請求的進入點，也是最常用的 handler。

實作範例

概念講完，我們用最小的程式碼把它落地。這個 Worker 只做一件事：回應請求，示範 fetch handler 的樣貌。就算你還沒安裝任何工具，也能先看懂它的骨架。

先看主程式 src/index.ts：

// src/index.ts
// 這是 ES Modules 語法，也是 Cloudflare 官方唯一推薦的寫法。
// export default 匯出一個物件，裡面的 fetch 就是處理 HTTP 請求的進入點。

export default {
  // 三個參數：
  //   request — 進來的 HTTP 請求（標準 Web Request 物件）
  //   env     — 所有 Bindings 的入口（KV、D1、AI... 都掛在這）
  //   ctx     — 執行上下文，可用 ctx.waitUntil() 跑背景任務
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
    const url = new URL(request.url);

    // 首頁：回傳一段歡迎文字
    if (url.pathname === "/") {
      return new Response("Hello from the edge! 你好，邊緣運算世界。", {
        headers: { "Content-Type": "text/plain; charset=utf-8" },
      });
    }

    // API 端點：回傳 JSON，附上目前處理請求的 Cloudflare 節點資訊
    if (url.pathname === "/api/status") {
      const data = {
        status: "ok",
        colo: request.cf?.colo ?? "unknown", // 處理此請求的 PoP 代碼（如 TPE）
        timestamp: new Date().toISOString(),
      };
      return new Response(JSON.stringify(data), {
        headers: { "Content-Type": "application/json" },
      });
    }

    // 其他路徑：回傳 404
    return new Response("Not Found", { status: 404 });
  },
} satisfies ExportedHandler<Env>;

逐段拆解：

• export default { ... }：這是 ES Modules 語法。舊的 Service Worker 寫法（addEventListener('fetch', ...)）官方已標示為棄用（Deprecated），新專案一律用這種。
• async fetch(request, env, ctx)：fetch 是處理 HTTP 請求的 handler。除了 fetch，Workers 還支援 scheduled（Cron 定時）、queue（消費佇列）、email（收信）等 handler，這些會在後續文章逐一登場。
• env：所有 Bindings 的統一入口。這個範例還沒用到任何 Binding，但一旦你在設定檔加了 KV 或 D1，就能透過 env.XXX 存取。
• request.cf?.colo：Cloudflare 在每個請求上附帶的中繼資料，colo 是處理這次請求的 PoP 代碼——這正是「邊緣運算」的具體證據：你的程式碼真的在離使用者最近的節點上跑。

接著是設定檔 wrangler.jsonc。2026 年 Cloudflare 已全面改用 wrangler.jsonc（取代舊的 wrangler.toml），支援註解、閱讀更清楚：

{
  // $schema 提供編輯器自動補全與驗證
  "$schema": "./node_modules/wrangler/config-schema.json",
  "name": "my-first-worker",
  "main": "src/index.ts",
  // compatibility_date 決定 Worker 使用的 runtime 行為版本
  // 新專案建議設為建立當天的日期
  "compatibility_date": "2026-08-01",
  // 啟用 Node.js 相容層，讓部分 Node API 可用（多數情況下建議開啟）
  "compatibility_flags": ["nodejs_compat"],
  // 開啟可觀測性，之後在 Dashboard 就能看到結構化日誌
  "observability": { "enabled": true }
}

有了這兩個檔案，部署只需要一行指令：

# 本地開發：在 http://localhost:8787 模擬完整的 Workers 執行環境
npx wrangler dev

# 部署到全球邊緣網路
npx wrangler deploy

wrangler deploy 執行完，你的 Worker 就同時活在全球 330+ 個節點上了——不需要設定伺服器、不需要選區域、不需要配置負載平衡。這就是無伺服器邊緣運算的體感。

順帶一提，本地的 wrangler dev 使用一個叫 Miniflare 的模擬器，能在你自己的電腦上重現完整的 Workers 執行環境，包括 KV、D1、R2、Queues 的本地實作。也就是說，你在開發階段完全不需要連上網、不會動到正式資源，就能寫程式、跑測試、除錯，等一切就緒再一鍵部署。這種「本地即完整環境」的開發體驗，是 Workers 上手門檻低的重要原因之一。

常見錯誤與最佳實踐

導論階段最該先破除的一個迷思，是把 Workers 當成傳統的 Node.js 伺服器。這個錯誤的心智模型會讓你在後面踩一連串的坑。

誤解一：以為可以用模組層級變數保存狀態。

因為 Isolate 隨時可能被回收重建，模組層級的可變變數不可靠：

// ❌ 危險：requestCount 可能在任意請求後被重置為 0
let requestCount = 0;

export default {
  async fetch(): Promise<Response> {
    requestCount++; // 這個數字完全不可信
    return new Response(`Count: ${requestCount}`);
  },
};

// ✅ 正確：持久狀態要存進 KV、D1 或 Durable Objects
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const count = parseInt((await env.COUNTERS.get("requests")) ?? "0") + 1;
    await env.COUNTERS.put("requests", String(count));
    return new Response(`Count: ${count}`);
  },
};

反過來說，不可變的常數（例如編譯好的正規表達式、設定物件）放在模組層級是安全且推薦的，能跨請求重用、提升效能。

誤解二：以為有本地檔案系統。

Workers 沒有 /tmp、沒有 fs。要存檔案請用 R2，要存資料請用 D1 或 KV。

誤解三：以為所有 Node.js 套件都能跑。

即使開了 nodejs_compat，child_process、原生 .node 模組、原始 TCP Socket 等仍不支援。正確心態是：優先使用 Web Platform APIs（fetch、ReadableStream、crypto），把 Workers 想成「一個實作了 Web 標準的邊緣執行環境」，而不是縮水版的 Node。

建立正確的心智模型後，一條實用的選型準則是：

需要全球低延遲的 HTTP 回應？    → Workers（fetch handler）
需要持久狀態 + 強一致性？       → Workers + Durable Objects
需要定期排程任務？              → Workers（scheduled handler）
需要處理非同步訊息？            → Workers（queue handler）
需要多步驟、可恢復的長任務？    → Workflows
需要全端框架（如 Next.js）？    → Cloudflare Pages

小結

這篇導論，我們一起鳥瞰了 Cloudflare 開發者平台的全貌：

• 邊緣運算把程式碼搬到離使用者最近的 PoP，消除長距離延遲。
• Cloudflare Workers 以 V8 Isolates 為核心，做到小於 1ms 的冷啟動，並按 CPU 時間計費。
• Bindings 是串起整個生態的膠水，透過 env 安全地存取 KV、R2、D1、Durable Objects、Queues、Workers AI。
• 正確的心智模型：Workers 是「實作 Web 標準的邊緣執行環境」，不是傳統 Node 伺服器。

這是本系列的第 001 篇。下一篇《第一個 Worker》會帶你從零安裝 wrangler、用 npm create cloudflare 建立專案，並實際把你的第一個 Worker 部署上線、在瀏覽器看到回應。

作為系列導讀，接下來 50 篇會沿著六大主題路線推進：

1. 基礎入門：第一個 Worker、wrangler 工具鏈、路由與 handler。
2. 儲存三劍客：KV、R2、D1 的實戰用法與取捨。
3. 有狀態運算：Durable Objects、WebSocket、即時協作。
4. 非同步與編排：Queues、Workflows、Cron 排程。
5. AI 與進階能力：Workers AI、Vectorize、Agents SDK。
6. 上線與維運：測試、可觀測性、CI/CD 與最佳實踐。

想深入官方細節，可以隨時參考 Cloudflare Workers 官方文件。準備好了嗎？我們下一篇正式開始動手寫程式碼。