做一個活動報名網站，除了活動介紹頁，通常還需要報名表、後台名單、封面圖片與附件下載。換成傳統架構，就得準備網站主機、後端程式、資料庫與檔案儲存，再處理部署、更新和容量問題。
Cloudflare Pages、D1 與 R2 可以把這些需求組成一套免伺服器（Serverless）架構：Pages 提供網站前端，Pages Functions 執行後端邏輯，D1 儲存結構化資料，R2 儲存圖片與附件。開發者仍然要寫程式，但可以把主機管理交給平台。
這個組合吸引人的地方，在於靜態內容可以透過全球網路傳送，動態功能又有一定的免費使用空間。對剛起步的產品、內容網站與中小型應用來說，值得把它列入架構選項。
選型補充：截至 2026 年 10 月 1 日查核時，Cloudflare 官方已建議新專案優先採用 Workers。本文仍以 Pages 為主，說明這套組合的運作方式；若正要開新專案，也可以評估 Workers Static Assets 搭配 D1、R2。Cloudflare Pages 官方說明
1. 免伺服器，免掉的是哪些工作？
Serverless 的意思是不用自行配置與維護執行程式的伺服器。機器仍然存在，只是由平台負責底層環境，開發者透過部署程式碼與設定資源來提供服務。
以這個網站為例，不必先租一台 Linux 主機，再安裝網站伺服器與資料庫服務。前端部署到 Pages，動態請求交給 Pages Functions。Functions 使用 Cloudflare Workers 執行環境，可處理表單、身分驗證與 API 等工作。Pages Functions 官方說明
省下主機維運，不代表應用程式就不用管理。資料權限、輸入檢查、備份還原、錯誤追蹤與費用監控，依然是開發團隊要負責的事。
2. Pages、D1、R2 各自負責什麼？
圖中的箭頭表示請求與資源存取方向，回應沿原路回傳。公開圖片可以經由獨立的資源網域讀取；私人附件則由後端確認權限後提供。
| 元件 | 在網站裡的角色 | 活動報名網站範例 |
|---|---|---|
| Pages | 提供前端頁面與靜態資源 | 活動介紹、報名畫面、CSS、JavaScript |
| Pages Functions | 執行後端程式 | 驗證報名內容、查詢名單、判斷下載權限 |
| D1 | 儲存可用 SQL 查詢的資料 | 活動、報名紀錄、附件資訊 |
| R2 | 儲存檔案本體 | 活動封面、PDF、使用者上傳的附件 |
Pages 提供畫面，Functions 接上動態功能
Pages 可部署建置完成的網站檔案，也能串接 Git 儲存庫，自動建置並部署更新。前端可以使用 Vue、React，或一般 HTML、CSS、JavaScript；實際建置設定仍要依框架調整。Pages Git 部署指南
讓網站成為全端應用的關鍵，是 Pages Functions。瀏覽器呼叫 /api/registrations 時，由 Function 檢查資料並寫入 D1。瀏覽器不需要、也不應持有 Cloudflare 管理憑證。
Functions 可以透過資源綁定（Bindings）使用 D1 與 R2。例如把資料庫綁定名稱設為 DB、檔案儲存桶設為 FILES，後端即可透過 context.env.DB 與 context.env.FILES 存取資源。這些物件提供給伺服器端程式使用。Functions 資源綁定說明
D1 管資料，R2 管檔案
D1 是採用 SQLite SQL 語法的託管式關聯資料庫，適合放需要搜尋、篩選與關聯查詢的紀錄。例如查某場活動有哪些人報名，或列出某位會員上傳過的附件。D1 官方說明
R2 是物件儲存服務，可把檔案存進儲存桶（Bucket），再以物件名稱讀取。它提供 Workers API 與相容 S3 的存取方式，適合存放圖片、PDF 等檔案。R2 入門說明
實作時，可以讓 D1 儲存一筆附件紀錄：包含擁有者、原始檔名、檔案大小，以及 R2 的物件名稱，例如 uploads/registration-123/document.pdf。檔案本體放在 R2。後台查名單時只讀取資料，使用者點下載時才取得檔案。
3. 使用者按下「送出報名」後，發生什麼事？
這是一張概念畫面，並非已上線網站的截圖。假設報名者填好姓名與聯絡方式，接著按下送出：
前端將表單內容送到 Pages Functions 的 API。
Function 檢查必要欄位、活動是否開放，以及是否已經報名。
通過檢查後，將報名紀錄寫入 D1。
後端回傳結果，前端顯示報名成功或需要修正的欄位。
活動封面則走另一條路：瀏覽器向公開圖片網域請求檔案，由快取或 R2 提供。單純看圖片不必每次都呼叫報名 API。
如果報名還要附檔，可以先把附件寫入 R2，再把檔案資訊寫入 D1。這時需要設計失敗處理：檔案上傳成功、資料庫寫入失敗時，應刪除未使用檔案或安排清理。不要把跨 D1、R2 的兩次寫入，當成會自動一起成功或一起取消的操作。
對有名額限制的活動，也不能只在畫面顯示「剩下 1 位」就認定安全。多人同時送出時，後端仍要確保名額檢查與資料更新的正確性。
4. 高速的來源：讓不同請求走適合的路
Pages 會把網站檔案部署到 Cloudflare 的全球分散式網路，減少使用者取得靜態內容時的距離。這類協助分散傳送內容的網路，稱為內容傳遞網路（CDN）。這對活動介紹頁、樣式檔與前端程式特別有幫助。Pages 平台說明
公開的 R2 檔案若要透過 Cloudflare 快取加速，可設定自訂網域，並確認檔案類型與快取規則。r2.dev 是供開發使用的網址，不適合作為正式網站的資源入口，也不提供這條自訂網域的快取路徑。R2 公開儲存桶與快取說明
動態資料的速度則要另外看。D1 沒有啟用讀取複本時，查詢會送到主要資料庫所在位置；即使前端與 Function 靠近使用者，資料庫往返仍可能增加延遲。D1 的全球讀取複本可改善跨區讀取，但要搭配 Sessions API 使用，寫入仍由主要資料庫處理。D1 全球讀取複本說明
所以，要讓網站快，除了選平台，也要做好圖片尺寸、前端程式大小、SQL 索引與 API 設計。活動清單可以考慮短時間快取；個人的報名紀錄則要避免進入共用快取。這些是應用設計上的取捨，不能只靠「部署在邊緣」就保證所有請求都很快。
5. 免費額度有多少？先把計算單位分清楚
以下整理自 2026 年 10 月 1 日查閱的官方文件。各項額度的週期與適用範圍不同，上線前仍應確認最新條款。
| 服務 | 免費額度或限制 | 計算時要注意 |
|---|---|---|
| Pages 靜態請求 | 免費且不限請求數 | 必須沒有觸發 Functions；見 Functions 計價 |
| Pages 建置 | 每月 500 次 | 免費方案同時執行 1 次建置；見 Pages 限制 |
| Pages Functions／Workers Free | 每日共 100,000 次請求 | 同一帳號共用，並非每個網站各有一份；見 Functions 計價 |
| D1 讀取 | 每日 5,000,000 列 | 按實際掃描列數計算；見 D1 計價 |
| D1 寫入 | 每日 100,000 列 | 索引更新也可能增加寫入量；見 D1 計價 |
| D1 儲存 | 帳號合計 5 GB | 免費方案單一資料庫最多 500 MB、最多 10 個資料庫；見 D1 限制 |
| R2 Standard 儲存 | 每月 10 GB-month | 是按時間計算的儲存量；見 R2 計價 |
| R2 Class A 操作 | 每月 1,000,000 次 | 包含上傳與列出物件等操作；見 R2 計價 |
| R2 Class B 操作 | 每月 10,000,000 次 | 包含讀取物件等操作；見 R2 計價 |
| R2 對外資料傳輸 | R2 本身不收取出口流量費 | 儲存、操作與串接服務仍各自計算；見 R2 計價 |
「一個人開一次網頁」不等於「一次後端請求」
以下是方便理解的假設情境，並非實測容量：每天有 3,000 人瀏覽網站，每人觸發 4 次 API，合計就是每天 12,000 次 Functions 請求。若首頁的 HTML、CSS、JavaScript 直接由 Pages 提供，這些靜態請求不會占用同一份 Functions 額度。
相反地，如果把所有資源都導進 Function，就可能讓原本的靜態流量也消耗動態請求額度。可透過 Pages 的 _routes.json 指定哪些路徑需要 Functions，並確認建置結果符合預期。Functions 路由說明
D1 算的是讀取列數，不是 API 次數
一次查詢只回傳 10 筆資料，過程卻可能掃描很多列。索引能減少不必要的掃描，通常也有助於速度。應查看實際查詢的 rows_read 與 rows_written，再估算用量；不要把「每日 500 萬列」直接當成「每日 500 萬次查詢」。D1 計量方式
R2 免費傳輸，仍要計算儲存與操作
R2 的免費額度適用於 Standard 儲存，不適用於 Infrequent Access。持續存放 10 GB 一整個月，約為 10 GB-month；額度並非每月可以新增 10 GB、再無限累積。讀取量很大時，即使不收出口流量費，仍可能產生操作費。R2 計價
使用 R2 前需啟用 R2 訂閱並完成結帳流程，超過免費額度的使用量依計價方式收費。R2 啟用方式
6. 從前端網站接成全端應用
建立這套架構時，可以依下面的順序進行。這是建置流程說明，實際指令與框架設定請依官方指南調整。
先部署前端。 完成活動介紹頁、報名表與後台畫面，確認本機可以建置，再透過 Pages 的 Git 整合設定建置指令與輸出目錄。Pages Git 部署指南
接著建立資料與檔案資源。 D1 可先設計 events、registrations、attachments 三張表；R2 則建議將公開封面與私人附件分開儲存，讓公開範圍容易確認。
把 D1、R2 綁定到 Functions。 設定 DB 與 FILES 後，由 API 統一處理資料。正式環境與預覽環境應使用不同資源，避免測試報名寫進正式名單。綁定設定完成或變更後，要重新部署才會生效。Functions 資源綁定說明
依功能建立 API 路徑。 例如：
| API | 工作 | 存取原則 |
|---|---|---|
GET /api/events |
查詢公開活動 | 只回傳已公開欄位 |
POST /api/registrations |
建立報名 | 檢查輸入、名額與重複送出 |
GET /api/admin/registrations |
後台查詢名單 | 驗證管理者身分與權限 |
GET /api/files/:id |
下載私人附件 | 先查 D1 的擁有者資訊，再讀 R2 |
這些路徑是本文的設計範例，Cloudflare 不會自動替網站建立報名或管理功能。採用檔案式路由時，可以把 Functions 放在專案根目錄的 functions 下，再依官方規則對應網址。Functions 路由說明
最後驗證完整流程。 用 Wrangler 的 Pages 本機開發功能測試前端與 Functions，再於獨立測試資源上確認部署後的行為。除了成功報名，也要驗證重複送出、無權限下載、附件過大與寫入失敗等情況。Pages 本機開發指南
7. 適合哪些網站？什麼時候需要重新評估？
從這些元件的分工來看，活動報名、作品集後台、內容管理、小型會員服務與文件下載平台，都是可以評估的應用情境。它們通常以網頁、短時間 API、資料查詢與檔案存取為主，容易拆成這套架構。
但若應用仰賴長時間執行的程式、完整作業系統環境，或重度影像運算，就需要另外設計執行方式。Workers 執行環境有 CPU 時間、記憶體等限制，不能直接視為一台不限用途的主機。Workers 平台限制
免費額度也有實際邊界。D1 免費方案達到每日讀寫上限後，查詢會回傳錯誤；容量用滿則會影響新增資料。D1 超額處理說明 單一資料庫若接近 500 MB，也應開始評估付費方案與資料成長方式。D1 容量限制
對一個剛起步的活動網站，可以先完成「看活動、送報名、查名單」這條流程，再加入圖片、附件與會員功能。運作一段時間後，根據實際 API 數量、資料庫掃描量、儲存量與回應速度決定是否升級。這樣才能把高免費額度轉成實際的成本優勢，也讓後續調整有數據可依據。