前端轉全棧的最低成本路線：Serverless 幫你省掉的東西，和它順手設下的三條線

2026 年 10 月 16 日，掘金上一篇前端工程師轉型全棧的整理文被廣泛轉發。文章的核心主張很直接：想從前端跨到全棧，其實不需要先學 Linux 運維、Docker、Kubernetes、Nginx 和資料庫調校，一套 Serverless 組合就能把這些整層略過。作者推薦的搭配是 Cloudflare Workers 加 D1 資料庫，再用 Hono 當框架、Drizzle 當 ORM。這條路線在技術社羣裡討論度不低，但多數文章只講輕鬆的部分。這篇整理難得之處，在於它把四個專案的官方文件翻過一遍之後，先把限制攤開來講。

先看邊界，再決定要不要學

按照該文整理，這套組合能做的是中小型 API、個人專案、內部工具，以及需要全球低延遲的 CRUD 服務，在每天十萬次請求以內可以零成本運作。做不了的是超過 30 秒 CPU 的長任務、大數據分析、影音轉檔、大模型推理，以及高並發的寫入密集場景。

這張能力表其實比任何教學文都重要。Serverless 的賣點是「不用管基礎設施」，但代價是執行環境被嚴格框住。把這個概念用日常比喻來說：傳統自架伺服器像自己開餐廳，廚房設備隨你買，但要自己處理水電和消防；Serverless 像去美食街租一個攤位，開店成本極低，但爐子的火力、瓦斯用量都由房東規定，想辦一桌辦桌菜就辦不了。

Workers 的關鍵數字：128 MB 與免費流量

Cloudflare Workers 的官方定位，是一條命令就能建置、部署、自動擴縮的無伺服器平臺，跑在全球三百多個節點上。免費方案每天十萬次請求，每次呼叫 10 毫秒 CPU 時間；付費方案每月 5 美元起，每月一千萬次請求與三千萬 CPU 毫秒，單次 CPU 上限可拉到 5 分鐘。流量與帶寬不計費，這是它與 Vercel 定價模式最大的差異點。

但原文特別點出一條硬線：每個 isolate 只有 128 MB 記憶體。這是 per-isolate 而非 per-request 的限制，超過會直接回傳 Error 1102。128 MB 意味著你不能把大模型載入記憶體，也不能一次讀進兩百 MB 的資料集。這個環境是為「輕邏輯加快速 IO」設計的，重計算不在它的服務範圍內。

D1 的計費邏輯：SELECT 星號是成本，不是風格問題

D1 是 Cloudflare 的無伺服器資料庫，SQLite 語義，資料放在離使用者近的邊緣節點。它的計費不是按運轉時數，而是按「讀了幾行、寫了幾行」。免費方案每天讀五百萬行、寫十萬行，儲存含 5 GB，閒置不計費。

這個計費方式會直接改變寫程式的習慣。官方給的例子是：一張五千行的表跑一次 SELECT *，就算讀了五千行。在 D1 上，避免 SELECT 星號是實打實的成本問題。另外還有幾條容易忽略的上限：單次 Worker 呼叫免費版最多 50 次查詢，這代表不能在一個請求裡循環打資料庫，必須改用批次查詢或 JOIN 把往返次數壓下來。

所以呢：這條路線適合誰

對多數前端工程師而言，轉全棧的門檻從來不是寫後端邏輯，JavaScript 的能力是現成的。真正的牆是運維那半邊：部署、資料庫、憑證、監控。Serverless 把這半邊整層抽象掉，等於把「學會當廚師」和「學會管廚房」拆開，先讓你只專心做菜。

但這個選擇也有隱含的代價。第一，能力邊界被平臺框住，專案一旦長到需要長任務或重計算，就得重新選型或遷移。第二，對平臺的理解深度，會決定除錯能力；128 MB 和 50 次查詢這類限制，出問題時不會有明顯的錯誤提示引導你。第三，工具選得越省事，可轉移的技能就越偏應用層。這和工程師社羣近期討論的AI 時代面試真正在考什麼是同一個母題：當基礎設施都被抽象掉之後，工程師的價值剩什麼、往哪裡放。

判斷標準可以很簡單。如果你的目標是 side project、個人工具、公司內部系統，這套組合的性價比目前很難被取代。如果你服務的業務有成長到長任務、資料管線的可能，Serverless 可以當起點，但別把它當終點，邊界的存在本身就是一份提醒。