目錄

• 戰略概覽
• 1. 何時使用 Pages 與 Workers
• 2. 免費版的重要限制

  • 不常見的提示
• 3. SPA 的經典問題：深層路由

  • 不常見的提示
• 4. 環境變數：公開不等於機密

  • 不常見的提示
• 5. 不要將整個 API 放在 SPA 中

  • 不常見的提示：不要為所有內容呼叫 Functions
• 6. 在部署末尾使用自訂網域名稱
• 7. 保護來源和 API
• 8. 利用 Preview Deployments

  • 不常見的提示
• 9. 使用 R2 儲存大檔案
• 10. 在開發期間避免激進的快取
• 11. 你應該監控的指標
• 推薦的起始架構
• 結論

戰略概覽

需求	工具	建議
部署前端	Cloudflare Pages	連接 Git 倉庫並自動部署
提供靜態檔案	Pages CDN	利用資產請求的免費和無限制特性
管理網域名稱	Cloudflare DNS	使用自訂網域名稱和代理記錄
保護應用程式	WAF Custom Rules	保護登入、註冊和敏感端點
建立小型 API	Pages Functions 或 Workers	用於輕量級邏輯和簡單端點
儲存檔案	R2	將圖像、PDF 和大檔案與前端分離
儲存簡單資料	KV 或 D1	用於設定、會話或原型
保護表單	Turnstile	僅在存在濫用的地方新增
處理 SPA 路由	_redirects 或 _routes.json	將未知路由發送到 index.html
管理機密	Variables and Secrets	永遠不要在前端套件中包含私鑰
驗證變更	Preview Deployments	在生產環境之前審查每個拉取請求
控制成本	限制和分析	分別測量 Pages Functions 和 Workers

1. 何時使用 Pages 與 Workers

對於傳統 SPA，最簡單的起點是 Cloudflare Pages。

Pages 適用於你的應用程式編譯為靜態檔案時：

npm run build

並產生如下資料夾：

dist/

工作流程如下：

1. 連接 Git 倉庫。
2. 選擇框架。
3. 定義建置指令。
4. 指定輸出資料夾。
5. 每次變更自動部署。

Cloudflare Pages 允許你為不同框架配置指令、輸出資料夾、環境變數和預設。(Build configuration)

當你需要以下功能時，使用 Workers：

• 自訂 API。
• 進階中介軟體。
• 身份驗證。
• 請求轉換。
• 在邊緣執行的邏輯。
• 將前端和後端結合在單一部署中的專案。

實用建議：

首先使用 Pages 部署前端，只有在有具體的後端需求時才新增 Workers 或 Pages Functions。

2. 免費版的重要限制

免費 Pages 計劃允許每月最多 500 次建置、一次同時建置、每個站台 20,000 個檔案、每個檔案最大 25 MiB。它還允許無限制的預覽部署。(Pages Limits)

這對於許多個人應用程式、MVP 和小型專案來說已經足夠。

但是，不建議直接上傳到 Pages：

• 大型影片。
• 安裝程式。
• 備份。
• 重型多媒體檔案。
• 大型圖像集合。

對於這些內容，最好使用 R2 或專用儲存，並讓 Pages 專門用於應用程式。

不常見的提示

計算你的建置產生的檔案數：

Get-ChildItem -Recurse dist | Measure-Object

應用程式在百萬位元組方面可能看起來很小，但由於來源對應、翻譯、字型或重複資產，可能會超過檔案限制。

3. SPA 的經典問題：深層路由

SPA 在從 / 導覽時可能完美運作，但如果用戶直接輸入：

/dashboard
/settings/profile
/projects/123

可能會顯示 404 錯誤。

發生這種情況是因為伺服器尋找名為 dashboard 或 settings/profile 的實體檔案，儘管這些路由應該由前端路由器解釋。

解決方案是將未知路由重新導向到 index.html。

在許多 Pages 專案中，你可以在公開資料夾中建立 _redirects 檔案：

/* /index.html 200

代碼 200 表示瀏覽器應該接收 index.html 的內容，而不會將路由轉換為可見的重新導向。

不常見的提示

不要對靜態檔案或 API 無差別地套用此回退。配置不當的設定可能會將真正的錯誤，如：

/api/users
/assets/logo.svg
/favicon.ico

轉換為 index.html 的 HTML 回應。

始終測試：

• 主路由。
• 內部路由。
• 不存在的路由。
• 瀏覽器重新整理。
• 直接分享的連結。
• 從行動裝置存取。

4. 環境變數：公開不等於機密

SPA 在瀏覽器中執行。因此，建置期間包含的任何變數最終都可能對用戶可見。

公開以下內容是有效的：

VITE_API_URL
NEXT_PUBLIC_API_URL
PUBLIC_SUPABASE_URL

但你永遠不應該公開：

DATABASE_PASSWORD
STRIPE_SECRET_KEY
JWT_PRIVATE_KEY
CLOUDFLARE_API_TOKEN

公開變數可用於配置前端。機密應保留在 Pages Functions、Workers 或你的後端中。

Cloudflare 允許從專案面板為生產和預覽配置不同的變數。(Pages Bindings)

不常見的提示

建立兩個獨立的環境：

Preview → 測試 API
Production → 真實 API

這樣，你可以審查拉取請求，而測試前端不會修改真實資料。

此外，透過 .nvmrc、.node-version 或 NODE_VERSION 明確設定 Node.js 版本。這可以防止建置環境的變更意外破壞部署。(Pages Build Image)

5. 不要將整個 API 放在 SPA 中

SPA 不應直接與需要私鑰的服務通訊。

不安全的架構：

SPA → 使用私鑰的外部服務

推薦的架構：

SPA → Worker 或 Pages Function → 外部服務

Worker 可以：

• 驗證接收的資料。
• 檢查身份驗證。
• 套用速率限制。
• 隱藏憑證。
• 正規化回應。
• 記錄錯誤。

Pages Functions 作為 Workers 執行，其請求計入 Workers 配額。在免費計劃中，組合配額為每天 100,000 次請求。(Pages Functions Pricing)

不常見的提示：不要為所有內容呼叫 Functions

如果你在 Pages 專案中新增 Function 而不配置路由，你可能會為只應提供靜態檔案的請求執行動態邏輯。

配置路由，使 Function 僅回應：

/api/*

並將資產保留為靜態內容。Cloudflare 允許定義包含和排除路由來控制哪些請求呼叫 Functions。(Pages Functions Routing)

6. 在部署末尾使用自訂網域名稱

首先在以下位置測試應用程式：

my-app.pages.dev

然後連接：

app.example.com

這樣可以輕鬆分離：

app.example.com       → 生產
staging.example.com   → 測試
api.example.com       → API
assets.example.com    → 大檔案

為 HTTP 和 HTTPS 流量啟用 Cloudflare 代理，但將不相容 Web 代理的服務（如某些郵件記錄）保留為 DNS-only。

7. 保護來源和 API

如果前端在 Pages 上但 API 位於另一台伺服器上，也要保護該來源。

建議措施：

• 不必要地不暴露後端 IP。
• 在 API 上套用身份驗證，而不僅僅是在前端。
• 驗證 CORS。
• 限制對 /api/login、/api/register 和 /api/reset-password 的請求。
• 在被攻擊的表單上使用 Turnstile。
• 在封鎖用戶之前套用 Managed Challenge。

Cloudflare 的自訂規則允許執行封鎖或質詢請求等操作。在免費計劃中，有數量和功能限制，因此建議為關鍵路由保留它們。(Custom Rules)

8. 利用 Preview Deployments

對小團隊最有用的功能之一是每個拉取請求都有一個預覽 URL。

推薦的工作流程：

拉取請求
   ↓
預覽部署
   ↓
視覺和功能測試
   ↓
合併到生產

這對於 SPA 特別重要，因為它允許檢測：

• 傳回 404 的路由。
• 缺失的環境變數。
• CORS 錯誤。
• 行動裝置上的損壞變更。
• 快取問題。
• 身份驗證失敗。

不常見的提示

在你的應用程式中包含一個指示環境的小視覺標籤：

Preview · commit a81f2c

這樣，在審查期間沒有人會混淆測試 URL 和生產 URL。

9. 使用 R2 儲存大檔案

SPA 套件應該只包含執行應用程式所需的內容。

保留在 Pages 之外：

• 用戶上傳的圖像。
• 影片。
• PDF。
• 專案檔案。
• 備份。
• 產生的匯出。

R2 專為物件儲存設計，可與 Workers 或你自己的 API 一起使用。在 Cloudflare 的目前產品中，免費計劃包括 R2 的儲存和操作配額。(Cloudflare Plans)

簡單的架構如下：

SPA → Worker → R2

Worker 產生受控的 URL，並防止儲存桶成為完全開放的存取點。

10. 在開發期間避免激進的快取

Cloudflare 可以長時間快取前端檔案。這在生產環境中是積極的，但在開發時可能會令人挫折。

為了避免問題：

• 為 CSS 和 JavaScript 使用帶版本號的名稱。
• 不要快取私人回應。
• 清除特定 URL 而不是清除所有內容。
• 在快速變更期間使用開發模式。
• 檢查 CF-Cache-Status。
• 記住瀏覽器快取可能在 Cloudflare 清除後仍然存在。

免費計劃允許快取規則、快取清除和快取分析，儘管限制比高級計劃低。(Cache Features by Plan)

11. 你應該監控的指標

對於 SPA，僅測量造訪次數是不夠的。

觀察：

• 主 JavaScript 載入時間。
• 快取回應的百分比。
• 內部路由的 404 錯誤。
• API 的 4xx 和 5xx 錯誤。
• Function 請求。
• Workers 的每日使用量。
• 每個請求的 CPU 時間。
• 身份驗證錯誤率。
• 套件大小。
• 表單放棄率。

免費 Workers 計劃有每天 100,000 次請求和每個請求 10 毫秒 CPU 的限制。小函數可能工作良好，但處理圖像、驗證複雜用戶或執行繁重計算的函數可能會超過該限制。(Workers Limits)

推薦的起始架構

Cloudflare DNS
      ↓
Cloudflare Pages
      ↓
靜態 SPA
      ↓
Pages Functions / Workers
      ↓
外部資料庫或 D1
      ↓
檔案用 R2

對於 MVP，你可以從以下開始：

• 用於前端的 Pages。
• 用於 API 的 Worker 或 Pages Function。
• 用於資料庫的 Supabase、Neon 或 D1。
• 用於檔案的 R2。
• 用於敏感表單的 Turnstile。
• 用於審查變更的 Preview Deployments。

結論

Cloudflare 的免費層級對於部署 SPA 特別有趣，因為它結合了靜態託管、CDN、HTTPS、自訂網域名稱、預覽和無伺服器函數。

最高效的策略是：

1. 首先在 Pages 上部署前端。
2. 正確解決 SPA 路由。
3. 將公開變數與機密分離。
4. 僅對動態邏輯使用 Functions 或 Workers。
5. 將大檔案儲存在 R2 中。
6. 保護登入、註冊和 API。
7. 測量消耗、錯誤和效能。
8. 僅在存在實際限制時擴展。

Cloudflare 不會自動取代整個後端，但它確實允許使用模組化架構建構功能性、安全且相當經濟的 Web 應用程式。