Cloudflare Pages 評測：邊緣部署平台
2.2 Pages 與 Workers 的共生關係
要談 Pages，就不能不談 Cloudflare Workers。可以這樣理解：Workers 是 Cloudflare 的邊緣運算引擎，而 Pages 是建構在 Workers 之上的「前端部署體驗層」。
當你在 Pages 專案裡建立一個 functions/ 目錄，並在裡面放入對應路由的檔案時，Pages 會自動把這些檔案編譯成 Workers 腳本，部署到邊緣網路。你不需要自己寫 wrangler.toml 設定服務綁定，Pages 會用一個圖形化介面幫你處理。這對不熟悉 Workers 生態的人來說，是一個相當友善的入口。
反過來說，如果你的專案複雜度已經超出了一般前端應用的範疇，例如需要長時間執行的排程任務、需要處理大量 WebSocket 連線、或者需要更細緻的路由控制，那你可能會發現純 Workers 的彈性更大。Pages 和 Workers 之間並不是取代關係，而是兩種不同粒度的工具，端看你的需求落在哪裡。
2.3 建置管線與部署生命週期
Cloudflare Pages 的部署流程大致可以拆成幾個階段：
第一，原始碼取得。你可以選擇連接 GitHub、GitLab 或 Bitbucket 儲存庫，讓 Pages 在每次推送時自動觸發建置；也可以透過 Wrangler CLI 或 Direct Upload API，直接把建置好的 dist 資料夾上傳上去，跳過 Pages 的建置環境。
第二，建置。Pages 會在一台 Ubuntu 容器裡執行你指定的建置指令，例如 npm run build。這個環境有預先安裝好的常見工具鏈，包含 Node.js 的多個版本、Python、Ruby、Go、Hugo、Jekyll 等，你也可以透過環境變數指定 NODE_VERSION 之類的參數。
第三，部署。建置產物會被分發到 Cloudflare 的邊緣網路。每次推送都會產生一個獨立的部署，並對應一組預覽網址。
第四，發布。你可以把某個部署「晉升」為正式環境，或者指定某個分支（通常是 main）自動對應到正式網域。整個過程都有版本紀錄，可以隨時回滾。
這個流程本身和 Vercel、Netlify 高度相似，差異主要在細節體驗與整合深度上，後面會逐一比較。
三、實際操作：從零開始部署一個專案
接下來進入實測環節。我以一個使用 Astro 建置的部落格專案作為測試對象，同時也測了 Next.js（靜態匯出模式）與 Vite + React 的組合，藉此觀察 Pages 在不同框架下的表現。
3.1 前置準備與 Git 整合
進入 Cloudflare Dashboard 後，選擇「Workers & Pages」→「Create」→「Pages」→「Connect to Git」，授權 GitHub 或 GitLab 之後，就可以挑選要部署的儲存庫。整個授權流程相當直覺，沒有什麼卡關的地方。
選定儲存庫後，Pages 會嘗試偵測你的框架，並自動填入建置指令與輸出目錄。以 Astro 為例，它會建議 npm run build 搭配輸出目錄 dist；Next.js 靜態匯出則會偵測到 out。這個自動偵測的準確度不錯，但偶爾還是會猜錯，建議手動確認一次。
有一點值得一提的是，Pages 允許你在同一個專案下設定多個環境（Production 與 Preview），並為兩者設定不同的環境變數。這對於需要區分正式與測試 API 端點的專案來說很方便，不需要自己用分支邏輯去判斷。
3.2 建置設定與環境變數
建置設定的欄位不多，主要就是：建置指令、輸出目錄、根目錄、以及環境變數。環境變數可以標記為「加密」（Secret），一旦設定為加密，之後就無法在介面上查看內容，只能覆蓋。這一點和 Vercel 的做法類似。
在建置環境方面，Pages 目前提供 v1、v2、v3 等不同版本的建置映像，v3 是較新的版本，基於更新的 Ubuntu LTS，預設的 Node.js 版本也比較新。你可以在設定裡切換。這個設計的用意是讓舊專案不會因為環境更新而突然建置失敗，算是一種保守但務實的做法。
實測下來，Astro 專案的建置時間大約落在 40 到 70 秒之間（視專案大小與依賴數量而定），Next.js 專案則約 90 到 150 秒。這個速度和 Vercel 相比略慢一些，但差距不算顯著，而且免費方案每月有 500 次建置額度，對多數個人專案或小型團隊來說相當夠用。
3.3 預覽部署與分支策略
每當你推送程式碼到非正式分支，Pages 就會自動產生一個預覽部署，網址格式大致是 <分支名>.<專案名>.pages.dev，再加上一串雜湊值。如果是 Pull Request，Pages 也會在 PR 上留言附上預覽連結，這一點對於團隊協作很實用。
比較特別的是，Pages 的預覽部署預設是可以被任何人存取的（除非你另外設定 Cloudflare Access 保護）。這代表如果你在預覽環境放了測試資料或未公開內容，要留意一下存取控制。Vercel 在這方面有提供「Vercel Authentication」的選項，Pages 則需要自己串 Cloudflare Access，稍微多一道手續。
3.4 直接上傳與 Wrangler CLI
如果你不想讓 Pages 代管建置流程（例如你的建置環境很特殊，或者你在 CI 裡已經建置好了），可以使用 Wrangler CLI 直接上傳：
npx wrangler pages deploy dist --project-name=my-project
這個方式的好處是彈性極大，你可以在任何 CI 環境裡建置，再把結果推上去。缺點是你得自己處理版本管理與分支對應，Pages 的自動預覽功能就不會那麼自動。對於已經有成熟 CI/CD 流程的團隊，這是一條值得考慮的路線。
四、功能深度評測
接下來進入功能層面的細節。這部分我會聚焦在幾個實際開發時最常碰到、也最能看出平台成熟度的功能上。
4.1 Pages Functions：在邊緣執行的後端邏輯
Pages Functions 是整個平台的靈魂。它的使用方式非常直覺：在專案根目錄建立 functions 資料夾，裡面的檔案結構會自動對應到 URL 路由。例如 functions/api/hello.js 會對應到 /api/hello。每個檔案匯出一個 onRequest 函式，接收 context 物件，回傳 Response。
這個設計的學習曲線極低，如果你寫過 Express 或 Next.js 的 API Routes，幾乎可以無痛上手。它支援 TypeScript、支援 ESM 與 CommonJS，也可以透過 _middleware.js 在路由層級插入中介軟體，處理驗證、CORS、日誌等共用邏輯。
執行環境方面，Functions 跑在 V8 隔離環境中，啟動速度極快（冷啟動通常在 5 毫秒以內），但這也意味著它不是完整的 Node.js 環境。許多依賴 Node 原生 API（如 fs、child_process、部分 crypto 用法）的套件無法直接執行。Cloudflare 提供了 nodejs_compat 相容旗標，讓部分 Node 模組可以運作，但並非百分之百相容。這是評估時必須列入考量的重點：如果你打算在邊緣跑一個依賴大量 Node 生態的後端服務，可能會遇到不少坑。
4.2 綁定生態系：KV、D1、R2、Durable Objects
Cloudflare 這幾年在邊緣儲存上的布局相當積極，而 Pages 可以透過設定介面直接綁定這些服務：
KV（Key-Value Store）適合存放設定值、快取資料、Session 等讀多寫少的場景。它強調的是全球讀取的低延遲，但寫入有一致性延遲（通常數十秒內傳播到全球），不適合需要強一致性的資料。
D1是 Cloudflare 的邊緣 SQLite 資料庫，適合中小型應用的關聯式資料。它解決了過去在邊緣環境難以使用 SQL 的痛點，但要注意它仍是相對年輕的產品，在效能與功能上與成熟資料庫服務還有差距。
R2是物件儲存服務，最大賣點是「零出口費用」（zero egress fee），對於需要頻繁讀取檔案（如圖片、影音、備份）的應用來說，成本優勢非常明顯，這也是許多人從 S3 轉向 R2 的主因。
Durable Objects則提供具狀態的邊緣運算能力，適合需要強一致性、即時協作的場景，例如多人編輯器、聊天室、遊戲狀態管理。
在 Pages 中綁定這些服務的流程相當簡單，只要在專案設定的「Functions」→「Bindings」裡新增對應綁定，就能在程式碼中透過 context.env 存取。這種整合深度是 Pages 相對 Vercel、Netlify 的一大優勢——因為這些儲存服務都是 Cloudflare 自家的，整合起來自然順暢。
4.3 自訂網域、SSL 與安全設定
把自訂網域指向 Pages 專案有兩種方式：一是把網域直接交給 Cloudflare 代管 DNS（推薦，設定最簡單，SSL 自動簽發），二是網域不在 Cloudflare 上，透過 CNAME 指向 <專案名>.pages.dev。兩種方式都能取得免費的 SSL 憑證，並且會自動續期。
免費方案下，每個專案可以綁定 100 個自訂網域，這個數量對絕大多數專案來說都用不完。如果你想讓多個網域指向同一個部署，可以設定 Redirect 規則或用 _redirects 檔案處理。
安全性方面，Pages 繼承了 Cloudflare 的 WAF（Web 應用防火牆）、DDoS 防護、Bot 管理等能力。即使你在免費方案，也能享有基本的防護。對於需要更細緻控制（如 IP 白名單、地理封鎖、速率限制）的場景，則需要搭配 Cloudflare 的其他功能，有些屬於付費範疇。
4.4 _headers 與 _redirects：小而美的設定檔
Pages 支援兩個簡單但實用的設定檔：_headers 和 _redirects，放在輸出目錄根層即可生效。
_headers 讓你可以為特定路徑設定 HTTP 回應標頭，例如 Cache-Control、X-Frame-Options、Content-Security-Policy。格式非常直覺：
/images/*
Cache-Control: public, max-age=31536000, immutable
_redirects 則處理 URL 重定向與重寫，支援 301、302、200（rewrite）等狀態碼。這兩個檔案的功能雖然樸素，但對於靜態網站來說已經涵蓋了八成以上的需求，而且不需要寫任何程式碼。若需要更動態的邏輯，再交給 Functions 處理即可。
4.5 回滾與版本管理
每一次部署都會保留在專案的部署歷史中，你可以清楚看到每次推送對應的建置結果、耗時、以及對應的 commit。要回滾到舊版本，只要在介面上點選「Rollback」即可，整個過程通常幾秒鐘就能完成。
這個機制在緊急修復時非常有用。實測中，我把一個部署回滾到三天前的版本，從點擊到生效大約花費不到十秒，而且不影響其他分支的預覽部署。唯一要注意的是，回滾並不會改變你的 Git 歷史，也就是說下次有人推送程式碼時，又會部署出新的版本，如果沒有把修正合併回主分支，可能會再次踩到同樣的雷。
五、效能實測與數據分析
談完功能，來看看效能。這部分我用幾個不同的測試工具與地點進行量測，數據僅供參考，實際表現會因網路環境、專案大小、快取狀態而異。
5.1 全球 TTFB 表現
TTFB（Time To First Byte）是衡量伺服器回應速度的關鍵指標。在 Cloudflare Pages 上，靜態資源因為有 CDN 快取，TTFB 通常落在 30 到 80 毫秒之間，視使用者與節點的距離而定。以台灣地區測試，多數節點的回應時間在 25 到 50 毫秒之間，表現相當優異。
Functions 的回應時間則略高一些，因為涉及程式碼執行。在簡單的 API（例如回傳 JSON）測試中，台灣地區的 TTFB 大約落在 40 到 90 毫秒之間。相較之下，若把同樣的 API 放在美東的傳統主機上，台灣使用者的 TTFB 往往會超過 200 毫秒。這個差距在行動網路或跨國連線的情境下會更加明顯。
5.2 冷啟動與執行環境
這是邊緣運算相對傳統 Serverless 的一大優勢。因為 Pages Functions 跑在 V8 隔離環境（和 Cloudflare Workers 相同），不需要啟動完整的容器或虛擬機，冷啟動時間通常低於 5 毫秒，實測中幾乎感受不到「第一次請求比較慢」的現象。相比之下，AWS Lambda 或 Google Cloud Functions 的冷啟動動輒數百毫秒，對於延遲敏感的應用來說差距很大。
不過，這個優勢是有代價的：V8 隔離環境不支援所有 Node.js API，套件相容性需要逐一驗證。如果你的應用依賴某些原生模組，可能得改用 Workers 相容的替代方案，或把邏輯拆到其他服務上執行。
5.3 建置速度與部署時間
前面提過，Astro 專案的建置約 40 到 70 秒，Next.js 約 90 到 150 秒。部署（把建置產物分發到邊緣）的時間則通常只需幾秒到十幾秒，因為 Cloudflare 本來就是全球網路業者，分發效率很高。
免費方案的建置是排隊執行的，也就是說如果你同時推送多個分支，後面的建置可能要等前面的完成。付費方案（Pro 以上）則提供並行建置，對於大型團隊或頻繁推送的工作流會比較友善。這一點在專案數量多、推送頻繁時值得注意。
六、定價方案與成本結構
定價是 Cloudflare Pages 最吸引人的地方之一，尤其是那個「無限頻寬」的承諾。
6.1 免費方案：誠意十足的入門選擇
免費方案提供每月 500 次建置、無限的請求數、無限的頻寬、每個專案 100 個自訂網域，以及基本的 Functions 額度（每天 100,000 次請求）。對於個人部落格、開源專案、小型商業網站來說，這個額度幾乎是綽綽有餘。
需要注意的是，免費方案的 Functions 有每日請求上限，超過之後當天的 Functions 就會停止回應（靜態資源不受影響）。如果你的應用高度依賴 Functions，且流量有機會爆衝，這是一個要留意的限制。
6.2 付費方案：Pro、Business、Enterprise
Pro 方案（每月 20 美元起）主要增加了並行建置、更長的建置逾時時間、更高的 Functions 用量、以及一些進階的效能與安全功能。對於正在成長的商業專案，這個價位相當有競爭力。
Business 與 Enterprise 方案則針對大型組織，提供更高的用量上限、進階的合規與支援服務。這些方案通常需要聯繫業務洽談，價格不公開。
整體來說，Cloudflare Pages 的成本結構在免費與入門付費層級極具優勢。當你的流量成長到需要付費時，通常也代表專案已經有一定的商業價值，那時候的費用相對營收來說通常是可以接受的。相較之下，某些競品的免費方案在頻寬與請求數上限制較多，流量一大就會收到帳單，這是 Pages 明顯勝出的地方。
七、與競品比較：Vercel、Netlify、GitHub Pages、AWS Amplify
把 Cloudflare Pages 放進整個市場來看，它的定位會更清楚。
平台
免費頻寬
邊緣函式
建置額度
特色
Cloudflare Pages
無限
有（Functions）
500 次／月
邊緣節點最多、整合儲存服務
Vercel
100 GB／月
有（Edge Functions）
6000 分鐘／月
Next.js 整合最深、開發體驗佳
Netlify
100 GB／月
有（Edge Functions）
300 分鐘／月
功能全面、外掛生態豐富
GitHub Pages
100 GB／月（軟限制）
無建置環境（可用 Actions）
完全免費、適合純靜態
AWS Amplify
15 GB／月
有（Lambda@Edge）
1000 分鐘／月
與 AWS 生態整合、企業友善
從表格可以看出，Cloudflare Pages 在頻寬與成本上的優勢非常明顯，但 Vercel 在 Next.js 的整合深度上仍然領先，例如 ISR（增量靜態再生）、Server Components、Image Optimization 等功能，在 Vercel 上都是開箱即用，而在 Pages 上則需要額外設定或改用其他方案。
Netlify 的優勢在於成熟度與外掛生態，它的表單處理、身分驗證、分割測試等功能都有現成的解決方案，對於不想自己串服務的團隊來說很省事。GitHub Pages 則是最單純的選擇，適合完全靜態、不需要任何後端邏輯的專案，但一旦需要動態功能就得另尋他法。AWS Amplify 則適合已經深度使用 AWS 的團隊，整合起來比較順，但學習曲線較陡。
選擇哪一個，最終還是取決於你的技術棧與優先順序。如果你用的是 Next.js 且需要完整功能，Vercel 可能更適合；如果你重視成本與全球效能，且願意接受一些框架整合上的限制，Cloudflare Pages 會是很有吸引力的選項。
八、優點與缺點總整理
經過一連串實測，我把 Cloudflare Pages 的優缺點整理如下。
優點：
第一，免費方案極具誠意，無限頻寬與請求數，對個人與小型專案幾乎零成本。第二，全球邊緣節點數量龐大，跨區域的延遲表現優異。第三，Functions 冷啟動極快，適合延遲敏感的應用。第四，與 Cloudflare 自家的 KV、D1、R2、Durable Objects 整合順暢，前後端可以部署在同一生態系。第五，支援的框架廣泛，從 Astro、Hugo 到 Next.js、Nuxt 都能部署。第六，Git 整合與預覽部署流程完整，協作友善。第七，回滾機制簡單可靠。
缺點：
第一，Functions 基於 V8 隔離環境，Node.js API 相容性有限，部分套件無法直接使用。第二，建置環境的除錯資訊相對有限，遇到建置失敗時有時需要反覆嘗試才能找出原因。第三，Next.js 的進階功能（如 ISR）支援度不如 Vercel 完整。第四，預覽部署預設公開，需要額外設定才能保護。第五，免費方案的建置是排隊執行，多專案同時推送時可能等待。第六，D1 等新產品仍在演進中，穩定度與功能持續變化，需要關注官方公告。
九、適用場景與不適用場景
什麼樣的專案適合用 Cloudflare Pages？我的觀察是以下幾類：
靜態網站與部落格是最典型的適用場景。無論是 Hugo、Jekyll、Astro 還是 Next.js 的靜態匯出，部署上去幾乎不需要煩惱。搭配無限頻寬，即使文章爆紅也不用擔心費用。
Jamstack 架構的應用也很適合。前端靜態化，動態邏輯用 Functions 處理，資料存在 KV 或 D1，整套都在邊緣執行，效能與成本兼顧。
需要全球低延遲的 API 服務同樣是好選擇。如果你的使用者分散在不同國家，把 API 推到邊緣可以顯著改善體驗。
反過來說，以下幾種情況可能要多考慮一下：
依賴大量 Node.js 原生模組的後端服務會遇到相容性問題，遷移成本可能偏高。需要長時間執行或複雜背景任務的應用，邊緣函式有執行時間限制，不適合這類工作負載。深度使用 Next.js 進階功能的專案，在 Vercel 上的體驗可能還是比較順。需要強一致性資料庫的應用，D1 目前仍不是這個定位，可能需要搭配外部資料庫。
十、常見問題解答
Q：Cloudflare Pages 真的完全免費嗎？
A：免費方案確實提供無限頻寬與請求，但有每月 500 次建置與每日 100,000 次 Functions 請求的限制。超出建置額度就無法在當月繼續自動建置（可改用 Direct Upload），超出 Functions 請求則當天 Functions 會停止回應。靜態資源不受影響。
Q：可以從 Vercel 或 Netlify 無痛搬家嗎？
A：多數情況可以，因為建置流程大同小異。但要注意框架特定功能的差異，例如 Next.js 的 ISR、Netlify 的 Forms，在 Pages 上可能需要改用其他方案實作。建議先部署一個預覽版本測試。
Q：Pages Functions 可以用 npm 套件嗎？
A：可以，但僅限於不依賴 Node.js 原生 API 的套件。若套件有用到 fs、child_process 等模組，需要尋找替代方案或啟用 nodejs_compat。建置時若遇到錯誤，通常是這個原因。
Q：自訂網域的 SSL 憑證需要額外付費嗎？
A：不需要。只要網域在 Cloudflare 上或透過 CNAME 指向 Pages，SSL 憑證會自動簽發與續期，免費方案也適用。
Q：如果我的流量突然爆衝，會被收費嗎？
A：免費方案的靜態資源是無限頻寬，不會因為流量爆衝而產生費用。但 Functions 有每日請求上限，超過之後會停止服務直到隔日重置。若你需要更高上限，可以升級付費方案。
十一、結論：值得投資時間學習的邊緣部署平台
Cloudflare Pages 不是一個完美無缺的平台，它在 Node.js 相容性、框架進階功能支援、以及某些開發體驗細節上，仍有進步空間。但如果你把這些限制放在「免費、無限頻寬、全球邊緣網路」的框架下來看，它的價值就非常清楚了。
對於個人開發者、部落客、開源專案維護者來說，Cloudflare Pages 幾乎是當前最划算的選擇之一。對於中小型商業專案，它提供了足以支撐成長的效能與擴充性，成本結構也相對友善。而對於已經在使用 Cloudflare 生態系（Workers、R2、D1）的團隊，把前端也搬過來更是順理成章。
當然，技術選型從來不是單純的「哪個最好」，而是「哪個最適合現在的專案」。如果你的專案高度依賴特定框架的進階功能，或者需要完整的 Node.js 執行環境，那麼繼續留在原本的平台可能更務實。但如果你正在尋找一個成本可控、效能優異、且願意接受一些權衡的邊緣部署方案，Cloudflare Pages 絕對值得你花時間實際部署一次試試看。
邊緣運算的趨勢才剛開始，Cloudflare Pages 在這個浪潮中站到了一個不錯的位置。它的未來發展，特別是 D1 與 Durable Objects 的成熟度提升，值得持續關注。對於願意及早擁抱新架構的開發者來說，現在正是投入學習的好時機。
```