開發時間也是成本：獨立開發者那一個月，把部署選型的帳攤開了

2026年10月19日，掘金上一篇標題為「如何低成本部署網站？Vercel 和 Cloudflare 怎麼選？」的文章，作者以自身獨立開發出海工具站一個月的經驗，整理了 VPS 與 Serverless 兩條路線的取捨邏輯。這類個人選型分享本身沒有聳動數字，但它攤開的，是獨立開發這個族羣在驗證階段把基礎設施成本壓到接近零的定價結構，也是雲端平臺免費額度爭奪戰的一個切面。

兩種帳本：固定成本對用量成本

作者的對比框架核心是一張帳。VPS 按月或按年付費，閒置時照樣產生費用，換到的是完全的運行時自由：自裝環境、自管 Nginx、自管安全補丁，冷啟動問題不存在，本地磁碟、資料庫、Redis 都可以自己養。Serverless 則按請求量與計算資源計費，低流量時成本可以低到趨近於零，代價是執行時長與 CPU 時間受平臺限制、有冷啟動可能、持久化狀態必須外掛到物件儲存或 KV。

作者的結論偏向驗證期先選 Serverless，理由一句話講完：開發時間本身就是成本。產品還沒驗證需求之前，把時間花在維護伺服器，等於把最貴的資源（創始人的工時）投在報酬最不明確的環節。

這個取捨其實有明確的適用邊界。作者自己也列出：持續運行的 Worker、長時間音視頻處理、密集計算、依賴系統級能力的任務，Serverless 的執行時長限制會直接卡死，VPS 或容器服務仍是必要選項。換句話說，Serverless 壓低的是低流量期的邊際成本，不是所有流量的邊際成本。

Vercel 與 Cloudflare 的差異，出在運行時那一層

平臺之間的差異，作者點在運行環境而非價格。Vercel 的 Node.js Functions 提供接近原生的 Node.js 環境，但同樣受函數執行時長、記憶體與 CPU 的平臺配置約束。Cloudflare Workers 走的是另一條技術路線：基於 V8 isolates 運行，提供自己的 Runtime API，再透過相容層支援部分 Node.js API。

這個差異的傳導很實際。本地 Node.js 環境跑得正常的代碼，搬到 Cloudflare Workers 未必能跑：依賴特定 Node.js 內建模組、原生二進制擴展、子進程或本地檔案系統的程式碼，都需要事先確認相容性。作者建議開發者先讀 Cloudflare 官方的 Node.js compatibility 文件、compatibility flags（如 nodejs_compat）、Workers Runtime APIs 與 Durable Objects 四份文件，再決定遷移範圍。

一個務實的做法被特別提出：把部署平臺、運行時環境、相容性限制與開發規範寫進專案的 AGENTS.md，讓 AI 編碼工具生成代碼時直接遵守這些約束。這與我們先前分析的一個人的 vibe coding 把待辦軟體邊際成本壓到接近零是同一條曲線：當 AI 工具承接更多編碼工作，平臺約束從人的記憶變成文件的輸入參數，遷移成本被提前到設計階段計算。

誰受惠、誰承壓

從成本結構看，這篇分享的選型邏輯對應的市場格局相當清楚。受惠的一方是驗證期與低流量階段的獨立開發者：Serverless 平臺的免費額度把固定成本換成用量成本，低流量期趨近於零，這與gits 把 git 託管成本壓到近乎為零的思路同源，基礎設施服務的邊際成本在無伺服器架構下被壓到可以免費贈送的水位。

承壓的一方則有兩層。低階 VPS 的按月計費模式，在純靜態與輕量動態網站這個區間的性價比被直接壓縮；而開發者這一側，一旦請求量、計算量或頻寬起來，Serverless 帳單的增長速度可能超出預期，作者也明確提醒要避免「突然出現的高額帳單」。用量計費壓低了進入門檻，同時把流量成長的風險從平臺移回使用者。

技術相容層則是另一道摩擦成本。V8 isolates 與原生 Node.js 的差異，意味著從 Vercel 遷往 Cloudflare（或反向）不是零成本搬移，依賴原生擴展與子進程的專案會被卡在相容性檢查這一關。這種摩擦對平臺是留存機制，對開發者是換供應商的沉沒成本。

收束判斷

來源是一篇個人選型經驗文，沒有覆蓋具體帳單金額與流量數據，本文不對兩家平臺的實際費用下結論。可以確認的是結構性判斷：驗證期專案的最優解是把創始人工時從基礎設施維運裡抽出來，用量計費的平臺承擔了這個階段的成本彈性；等到常駐進程、長時任務與密集計算的需求浮現，帳本會倒向 VPS 或容器。真正的分水嶺不在平臺名稱，在工作負載的形狀。