前端託管的分水嶺，往往要等帳單真的跑起來才浮現：站點一多、流量一漲，頻寬與構建次數就成了新的變數。Cloudflare Pages 把免費的邊界挪到另一處：站點、席位、請求與頻寬先擺在一邊，配額表真正盯住的是構建次數、專案數量與單檔體積。

把構建與分發綁在同一張網上

官方給 Cloudflare Pages 的定位是無伺服器平台，讓團隊把應用快速構建、協作、測試並部署上線；產品頁的一句話摘要寫得更直接：全端應用構建完成後，直接落到 Cloudflare 全球網路。分發這一環由自有的網路承擔，產品頁的說法是這套服務跑在支撐網際網路兩成流量的系統之上，企業級的可靠性、安全性與效能屬於預設配置，HTTP/3、QUIC、圖片壓縮與 SSL 都在開箱即用的範圍內。上線路徑有三條：接入程式碼託管平台、用 Direct Upload 直接上傳構建產物，或者用命令列工具從本機推送。靜態網站與全端應用共用同一套部署模型，Pages Functions 負責把伺服器端程式碼跑起來。

構建配置交給預設

接上程式碼託管平台之後，每次推送都會觸發一次構建與部署。官方為常見框架備了一份預設清單，React、Gatsby、Next.js 的靜態匯出、Nuxt、Qwik、Remix、Svelte、SvelteKit、Vue、Angular、Docusaurus、Hugo、Jekyll、Eleventy、VitePress 與 Zola 都在列表裡，每條預設自帶構建命令與產物目錄。構建成敗由結束碼決定：命令回傳非零即標記為失敗，回傳零則視為成功並上傳產物，即使標準錯誤裡寫了日誌也不影響這個結論。根目錄預設取倉庫根，只有單體倉庫裡放多個專案時才需要單獨指定。產物目錄由構建命令產生，多數框架統一落在業界慣用的 public 目錄下。

若不走程式碼託管這條路，Direct Upload 允許把已經構建好的產物整包推上去，適合構建流程放在自有平台或本機的場景。命令列方式一次上傳一個資料夾，官方給的檔案上限是兩萬個；面板拖曳方式接受壓縮包或單一資料夾，檔案上限一千；兩者在單檔體積上都以 25 MiB 封頂。函式目錄需要隨著命令列一起上傳，一個獨立的 worker 腳本檔則兩種方式都能辨識。

配額表真正盯住的東西

免費檔的邊界由官方配額表逐條寫明。構建並行是最好懂的一項：免費檔同一時間只跑一個構建，專業檔五個，商業檔二十個；並行按帳戶計數，單次構建執行超過二十分鐘會被中止。每月構建次數依次是五百次、五千次與兩萬次。自訂網域按專案計算，免費檔一百個、專業檔兩百五十個、商業檔五百個。檔案數量上，免費檔單一站點能放到兩萬個，更高檔位可以提到十萬個，需要在專案設定裡把對應的環境變數開好。單一資源檔的體積上限是 25 MiB。預覽部署與協作用戶兩項都按無限額提供，帳戶層面的專案數上限為一百個，官方註明這項額度按慣例不做上調。

請求層交給兩個小檔案

靜態資源的響應頭與跳轉規則由兩個純文字檔接管，它們本身不會作為資源發布出去，只是在構建產物目錄裡被平台解析。響應頭檔的規則條數上限是一百條，每一行連空格帶名稱帶取值合計兩千個字元封頂；一次請求命中多條規則時，會把各條規則宣告的響應頭一併繼承下來。跳轉檔每行只寫一條宣告，順序會影響結果：同一條來源路徑出現多份宣告時，位置靠前的那一條先生效，靜態規則也應當排在動態規則前面。它的容量上限是兩千條靜態跳轉加一百條動態跳轉，合計兩千一百條，單條宣告一千個字元封頂。兩個檔案同時命中一次請求時，跳轉先於響應頭執行。

預覽、回滾與部署鉤子

每次在倉庫上開一個新的合併請求，平台就會為這次改動生成一條獨立預覽連結，內容隨分支上的後續提交持續更新。每新建一條分支，就會在專案子網域前面拿到一串隨機生成的雜湊，形成一條新的預覽位址；平台還會為分支名建一個別名，讓別名跟著該分支的提交往前滾。生產網域與掛在專案上的自訂網域都不受預覽部署影響。為了避免這些臨時副本影響搜尋結果，官方預設給每一條預覽部署加上不被搜尋引擎收錄的標記。回滾的對象是任意一次構建成功的生產部署，回滾之後依然可以再切到更新的版本，而預覽部署不作為回滾目標。網域接入分兩種情況：根網域需要先把站點接入 Cloudflare 並改好名稱伺服器，由平台代為建立解析紀錄；子網域只要在解析服務商那裡補一條 CNAME 紀錄，指向專案自己的子網域即可。

部署鉤子把觸發的起點從提交挪到了別處：每條鉤子有自己的唯一位址，收到一次 HTTP POST 就啟動一次構建，設定時只填鉤子名稱與要構建的分支兩個參數。官方提醒鉤子只要位址被呼叫就能觸發，因此應當當成機密資訊保管，懷疑被人使用時刪掉重建一條。這套機制適合內容由外部內容管理系統維護、又希望站點跟著內容一起更新的場景，也可以串進自訂的持續整合流程，或者按固定時間表定時重建。

Cloudflare Pages 把前端託管拆成三件事：構建在預設裡完成，分發落到自有的全球網路，配額則寫在一張公開的表上。它值得留意的地方，在於免費檔的敞開項足夠多：站點、席位、請求與頻寬先擺在一邊，真正需要盤算的是每月構建次數、專案數量與單檔體積。對流量起伏大、頻寬開銷又難預估的靜態網站與全端應用來說，這套組合把成本的不確定性壓得很低。