Cloudflare Workers 邊緣運算完整教學：用 Serverless 打造全球低延遲後端 API

如果你跟我一樣，受夠了每次部署後端 API 都要煩惱伺服器地區、冷啟動延遲、還有那個永遠搞不定的 auto-scaling 設定，那 Cloudflare Workers 可能會讓你眼睛一亮。這東西的概念很簡單：把你的程式碼丟到全球超過 300 個邊緣節點上跑，使用者從哪裡發 request，就從最近的節點回應。聽起來很美好對吧？實際用起來，我覺得確實解決了不少痛點。

什麼是 Cloudflare Workers？

Cloudflare Workers 是建構在 V8 引擎上的 Serverless 運算平台。跟 AWS Lambda 或 Google Cloud Functions 不一樣的地方在於，它不是跑在某個特定區域的資料中心，而是分散在 Cloudflare 的全球邊緣網路。每次請求進來，會由離使用者最近的節點處理，延遲通常可以壓到個位數毫秒。

你可以把它想成：傳統 Serverless 是「選一個機房幫你跑」，Workers 是「全世界的機房同時幫你跑」。這個架構特別適合需要低延遲的 API 服務、A/B 測試分流、或是做全球性的內容個人化。如果你之前有碰過 Bun Runtime 後端開發，你會發現 Workers 的 JavaScript 執行環境有些類似的味道，但多了邊緣部署的天然優勢。

為什麼選擇邊緣運算？

老實說，不是每個專案都需要邊緣運算。如果你的使用者全在台灣，一台放在東京的 VM 就夠了。但如果你在做面向全球的 SaaS、API Gateway、或是任何對延遲敏感的服務，邊緣運算的優勢就很明顯：

• 冷啟動極快：Workers 的啟動時間大約在 0-5ms，對比 Lambda 的數百毫秒到數秒，差距很大
• 全球一致的低延遲：不用自己搞多區域部署，Cloudflare 幫你搞定
• 免費額度慰慨：每天 10 萬次請求免費，對 side project 來說很夠用
• 內建 KV、D1、R2：儲存方案齊全，不用另外接第三方服務

搭配 Docker Multi-Stage Build 的容器化部署經驗，你會發現 Workers 把「部署」這件事簡化到了極致——根本不需要 container。

開發環境建置與 Wrangler 設定

Wrangler 是 Cloudflare Workers 的官方 CLI 工具，所有開發、測試、部署都靠它。先裝起來：

# 安裝 Wrangler CLI
npm install -g wrangler

# 登入你的 Cloudflare 帳號
wrangler login

# 建立新專案
wrangler init my-edge-api
cd my-edge-api

初始化後會產生一個 wrangler.toml 設定檔，這是整個專案的核心設定：

name = "my-edge-api"
main = "src/index.ts"
compatibility_date = "2026-03-01"

[vars]
ENVIRONMENT = "production"

[[kv_namespaces]]
binding = "CACHE_KV"
id = "your-kv-namespace-id"

[[d1_databases]]
binding = "DB"
database_name = "my-edge-db"
database_id = "your-d1-database-id"

這邊要注意 compatibility_date 的設定，它決定了你的 Worker 使用哪個版本的 runtime API。建議設成專案開始的日期，之後要升級再改。

第一支 Worker：Hello World 到路由設計

Workers 的進入點很單純，就是一個 fetch event handler。但真正的專案不可能只有一個 endpoint，所以我們需要做路由。這裡示範一個輕量的路由寫法：

// src/index.ts
export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
    const url = new URL(request.url);
    const path = url.pathname;

    // 簡易路由
    if (path === "/api/health") {
      return new Response(JSON.stringify({ status: "ok", region: request.cf?.colo }), {
        headers: { "Content-Type": "application/json" }
      });
    }

    if (path.startsWith("/api/users") && request.method === "GET") {
      return handleGetUsers(env);
    }

    if (path.startsWith("/api/cache") && request.method === "GET") {
      const key = url.searchParams.get("key");
      return handleCacheGet(env, key);
    }

    return new Response("Not Found", { status: 404 });
  }
};

注意 request.cf?.colo 會回傳處理這個請求的邊緣節點代碼（像是 TPE 代表台北、NRT 代表東京），拿來做 debug 很方便。如果你的路由邏輯比較複雜，也可以考慮用 itty-router 這個輕量框架。

KV 儲存實戰：打造快取層

Workers KV 是一個全球分散式的 key-value store，讀取延遲極低，適合拿來做快取。如果你之前研究過 Redis 快取策略，會發現 KV 的思維很類似，但不需要自己管理 Redis 叢集。

async function handleCacheGet(env: Env, key: string | null): Promise<Response> {
  if (!key) {
    return new Response("Missing key parameter", { status: 400 });
  }

  // 先查 KV 快取
  const cached = await env.CACHE_KV.get(key);
  if (cached) {
    return new Response(cached, {
      headers: {
        "Content-Type": "application/json",
        "X-Cache": "HIT"
      }
    });
  }

  // 快取沒有，從 D1 查
  const result = await env.DB.prepare(
    "SELECT data FROM items WHERE key = ?"
  ).bind(key).first();

  if (!result) {
    return new Response("Not Found", { status: 404 });
  }

  const data = JSON.stringify(result);

  // 寫入 KV 快取，設定 TTL 3600 秒
  await env.CACHE_KV.put(key, data, { expirationTtl: 3600 });

  return new Response(data, {
    headers: {
      "Content-Type": "application/json",
      "X-Cache": "MISS"
    }
  });
}

KV 有個特性要注意：它是 eventually consistent 的，寫入後全球同步大約需要 60 秒。如果你的場景需要強一致性，應該改用 Durable Objects。

D1 資料庫整合：SQL on the Edge

D1 是 Cloudflare 自家的 SQLite 邊緣資料庫，目前還在持續進化中，但已經堪用了。建立資料表很直覺：

# 建立 D1 資料庫
wrangler d1 create my-edge-db

# 執行 migration
wrangler d1 execute my-edge-db --command "CREATE TABLE IF NOT EXISTS users (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  name TEXT NOT NULL,
  email TEXT UNIQUE NOT NULL,
  created_at TEXT DEFAULT (datetime('now'))
);"

在 Worker 裡操作 D1：

async function handleGetUsers(env: Env): Promise<Response> {
  try {
    const { results } = await env.DB.prepare(
      "SELECT id, name, email, created_at FROM users ORDER BY created_at DESC LIMIT 50"
    ).all();

    return new Response(JSON.stringify({ users: results }), {
      headers: { "Content-Type": "application/json" }
    });
  } catch (err) {
    return new Response(JSON.stringify({ error: "Database query failed" }), {
      status: 500,
      headers: { "Content-Type": "application/json" }
    });
  }
}

D1 的查詢語法就是標準 SQL，對有 SQLite 或 PostgreSQL 經驗的開發者來說幾乎零學習成本。

部署上線與效能調校建議

部署到全球只需要一行指令：

# 本地開發測試
wrangler dev

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

幾個我實際踩過坑的經驗分享：

1. Worker 大小限制：壓縮後 5MB（付費方案），免費版 1MB。不要把整個 ORM 塞進去，保持精簡
2. CPU 時間限制：免費版每次請求 10ms，付費版 30 秒。重計算任務不適合放在 Workers
3. 善用 ctx.waitUntil()：非同步任務（例如寫 log、更新快取）放在這裡，不會阻塞回應
4. Custom Domains：可以綁定自己的網域，搭配 Kubernetes Gateway API 做更複雜的流量管理

如果你需要處理的不只是 HTTP API，也可以考慮搭配 Deno 2 後端開發來處理比較重的運算任務，Workers 負責邊緣層的路由和快取。

結語：邊緣運算是後端的未來嗎？

我的看法是：邊緣運算不會取代傳統後端，但它正在成為現代架構中不可或缺的一層。Cloudflare Workers 把邊緣部署的門檻降到了幾乎為零——不用管伺服器、不用設定 CDN、不用煩惱 scaling。對於 API Gateway、快取層、認證中間件這類場景，它幾乎是目前最優的選擇。

如果你正在規劃新的後端架構，我強烈建議把 Workers 納入考量。就算不是整個後端都搬上去，光是拿來做邊緣快取和路由分流，就能讓你的使用者體驗提升一個等級。動手試試看吧，從一個簡單的 wrangler init 開始，你會發現邊緣運算比你想像的容易上手得多。