用 AI Vibe Coding 很方便，雲端服務的隱藏收費陷阱很容易讓人後悔

Free Plan 不提供備份

Supabase 的免費方案雖然在開發階段非常好用，但有一個容易被忽略的痛點：Free Plan 不包含任何專案備份功能(Free Plan does not include project backups.)。

這代表一旦專案上線後，資料庫發生意外刪除、惡意修改或操作失誤，將沒有官方自動備份可以還原。

許多專案在成長到有真實用戶後才發現這個問題，資料庫是可能存消費者購買紀錄、一些累積了一陣子的重要設定參數，這些遺失的資料要去哪裡救回來是一回事，若要開啟備份就必須升級付費方案，每個月 $25 美金起跳，瞬間打破原本「免費快速開發」的美夢。

當然我想有些人是會再自己硬幹一個東西，然後在社群上發文說每個月省了多少錢，留言XX，將私訊獲得!#$%$%#$秘笈...

Auth 的郵件寄送額度

另一個常讓第一次使用 Supabase 的人踩雷的是 Supabase Auth 的 email 寄送限制。

如果專案要做一些會員註冊驗證信之類的功能，Supabase Auth 提供內建 email 功能，但額度少得可憐，也許自己測試時不會發現問題，但一旦專案上線，使用者開始湧進註冊，內建免費的額度馬上就沒了，使用者被卡在註冊流程中。

讓 AI 改程式碼可能一下就改好，但是電子郵件發不出去，不是幾分鐘就能解決的事，這都多虧電子郵件行銷界的前輩們，現代各大電子郵件寄送服務通常都有一些逐步上調寄送額度/人工申請審核的管制政策，不會讓一個剛註冊好的帳號瞬間就能在5分鐘內發送上百封信。

付費升級買一堆用不到的服務

免費版的資料庫效能有限，如果壓力測試發現系統瓶頸在資料庫服務那邊，很直觀的反應是「阿我就升付費方案就好了」?

但 Supabase Pro 的計費架構是這樣的：付的錢是整個專案的套餐價，不是單純買資料庫效能。

免費版的資料庫使用的是 nano 等級的機器(Shared CPU，0.5GB RAM)。升級到 Pro($25/月)之後，方案本身包含 $10 的 Compute Credits，對應的是 Micro 等級(2 vCPU，1GB RAM)，也許夠應付一些小型專案，但想撐過瞬間千人的高流量還是有點危險。

Compute and Disk

想要更高效能的資料庫，需要選更高等級的 Compute（從 Micro 往上有 Small、Medium...），每個等級都是另外加錢，和 Pro $25 月費是分開計算的。詳細規格和定價可以看 Supabase Compute and Disk 官方文件。

如果只需要一個有廠商代管的雲端純 PostgreSQL 資料庫，也許使用專門的雲端資料庫服務會更直接，不用為一堆沒在用的附加服務買單。

當然也不是換到其他家就能馬上過著幸福快樂的好日子，例如本來的程式一開始是用 Supabase 的 HTTP API，然後呼叫資料庫連線又沒有一個統一的架構設計......你什麼時候產生了只要改 url 和帳密，就能輕鬆換到其他家的幻覺?

如果換到其他家，人家不一定有做那層 PostgREST，程式又要調整一番才能用。

Firebase 的其他資料庫

Firebase 的另一個產品 Realtime Database 也是 NoSQL 就是了，又有各自的適合場景，有興趣的可參考官方文件選擇資料庫：Cloud Firestore 或 Realtime Database。

Firebase 裡面還有一套 Firebase SQL Connect，背後是會幫人自動到 GCP 開貴貴的 Cloud SQL for PostgreSQL，而且官方文件上有說: 使用 Spark 方案(Firebase 免費方案)時，每天最多只能執行 8,300 項作業，超過上限就無法再執行任何作業。

又是一個測試時用爽爽，上線後可能馬上就卡住的玩意。

被「不用學 SQL」坑的人越來越多

許多 AI vibe coding 課程或教學影片特別愛推 MongoDB Atlas、Firebase Firestore 這類資料庫，常見的賣點就是「不用學複雜的 SQL，用像 Excel 一樣的思維就能操作，很快就能完成各種資料管理系統」。

對新手或簡單專案來說，這的確很吸引人，讓人看似不花一絲力氣就做出一個有資料功能的應用。但現實往往是，這些工具雖然好上手，卻不是所有專案都適合。

當應用開始需要處理使用者資料列表和明細、文章分類與標籤、會員權限關聯、多條件查詢等功能時，正規的關聯式資料庫（例如 PostgreSQL/MariaDB）反而會更自然、效能更好，也更容易長期維護。

NoSQL 也並非一無是處。它在一些資料結構經常變化、讀取遠多於寫入、不需要複雜關聯的應用場景特別有優勢，例如即時聊天、即時遊戲、IoT 資料收集、使用者行為追蹤工具等。真正的關鍵不在於哪個技術好不好，而是清楚知道它的優勢與限制，一味追求「最簡單、最快」的技術選擇，最後常演變成技術債。

與其只看「好不好上手」，更該先想想這個專案未來可能長什麼樣子，才不會讓前期的開發爽感，變成後期的維護痛苦。

API 有速率限制

Google Sheets API 免費版每分鐘只能被打 60 個請求，詳情可參考Google Sheets 用量限制。

聽起來不少，但如果我們的 web app 有個數據儀表板之類的 dashboard 功能，在頁面載入時會打好幾個 API 拿不同統計數據，或是使用者多一點，那用量很快就超過，然後開始收到 429 錯誤，完全無法正常顯示資料。

標準 Sheets API 用量有限，有些開發者會改用 Google Visualization API Query endpoint（網址類似 https://spreadsheets.google.com/tq?...&key={sheetId}）來繞過標準 Sheets API限制。不走標準 Sheets API，因此不計入 per-minute quota。

那種 Google Visualization API 的方式會直接存取公開分享的試算表，只要知道這件事，隨便一個路人都可以把整個檔案抓回去看光光，看那個檔案裡面是代購訂單紀錄、某種帳目，或是其他敏感資訊? 安全性風險很大。

資料讀取慢

Sheets API 讀資料是整個 range 一起撈，沒有資料庫的 index，也沒有 query 篩選，頂多只有有限的 A1 notation 範圍選擇或 Apps Script 內的 QUERY 函數。

要找特定條件的資料，通常要把整個工作表撈回來，再在程式裡過濾，資料一多就非常慢。

處理寫入衝突

Google Sheets 本身設計是給人用滑鼠點格子用的協作試算表，不是給程式高頻寫入的。

兩個 request 同時寫同一個工作表，很容易發生 race condition，資料被蓋掉或者 API 回傳錯誤。

雖然勉強可以用 Apps Script 的 Lock Service，但實作複雜且仍有上限，無法像正規資料庫那樣提供 transaction isolation。

欄位沒有型別

所有儲存格基本上都是「值 + 格式」，日期可能存成文字、數字被當成字串，還有多餘空格、隱藏換行、傳來的日期格式不一致……這些問題都得在程式裡自己清洗資料與轉型態，然後在程式裡自己寫一堆 setNumberFormat 和牢記各種格式的符號，以免直接在 Google Sheets 要對資料排序和搜尋時，出現一堆怪問題。

搞到後來，搞那些資料清洗與防禦性程式碼，往往比核心商業邏輯還多，長期維護成本大幅上升。

資料筆數有上限

Google Sheets 整份試算表的上限是 1,000 萬個儲存格或 18,278 個欄。如果一筆資料有 20 個欄位，大約 50 萬筆資料就會撞到天花板，而且接近上限時讀寫速度會明顯變慢，不是突然壞掉，是慢慢讓你很難受。

其實也不用真的到什麼幾萬筆，只要資料稍微多一點，就沒人能用網頁瀏覽器打開那個 Google Sheets 檔案了。

災難復原原則

在 vibe coding 時代，有些資料流程莫名其妙變成顯學，像是剛提到的 Google Sheets 當資料庫，還有單據全部上傳到 Google Drive，然後程式自動讀取產生正規化資料之類的。

這些做法表面上很方便，但從 IT 角度看有幾個問題：

Google Sheets 等服務雖然有版本歷史功能，但不一定符合每個人的需求。而且版本歷史有時效性，看 Google 高興定多久就定多久，之前是超過 30 天或100個舊版本以外的會自動刪掉，就救不回來了。

預算充足的正規資料庫管理，會有定時自動備份、跨區域複寫、備份保存等一堆策略。但 Google Sheets 的備份就是...請使用者自己定期下載一份副本，沒有人幫他管這件事。哪天 Google 帳號被盜、檔案被誤刪、或 Google 端出問題，資料就直接消失了。

總而言之，Google Sheets 適合自己手動維護的小型清單，或是讓非技術人員可以直接瀏覽編輯資料。真正要讓程式頻繁讀寫的，隨便一個關聯式資料庫都比 Sheets 更合適。

如果是要開放給多人使用的正經服務，避免重要資料消失，對資料的保護機制至少要到位。

免費方案每月 100GB 流量

免費方案每月有 100GB Fast Data Transfer 額度，如果網站有放很多大圖片給人瀏覽、大檔案給人下載，或是被人惡搞的話，很快就會用完，需要注意一下。

這個限制是帳號/Team層級的，如果開了很多網站專案，剛好有幾個用量比較兇，會連累到其他網站。

100GB 用完之後，網站不會馬上被停用，也不會像一般虛擬主機直接顯示 509 Bandwidth Limit Exceeded，而是會變慢，如果持續有大用量才會被停用。

付費升級後就變成 1TB 額度，用超過的話會跳表計費。

免費方案 Cron jobs 只能每天跑一次

免費方案每個 project 可以設最多 100 個 cron job，但執行頻率最多只能每天一次，不能每小時或每幾分鐘跑。

也不保證一定在設定的那個時間點就會執行，看 Vervel 的資源用量調度，也有機會排到 50 幾分鐘後才執行。

需要更高頻率需要付費升級，或是自己想其他法子(例如從外部的 cron 服務呼叫網站 endpoint)。

當然 Vercel 上的服務推陳出新，上面沒寫的不代表沒問題，Usage 頁面有計量的東西都應該關注一下，像是 Serverless Functions 就曾讓新創APP Cara App 和 Jmail 造成單月台幣一兩百萬($40000~$90000 美金)的帳單。

Function Max Duration 小心執行時間逾時

如果有需要比較久的操作（呼叫不可控的外部 AI API、大量資料處理），超過設定值就會 timeout，要記得手動調整。免費方案最多可以設定300秒(5分鐘)，更長的時間要付費升級。

免費方案不能用於商業用途

一旦用 Vercel 免費方案做一些商業獲利性的網站，Vercel 可以不須事先通知，直接停用專案或是刪掉資料，在 Vercel 的 Terms of Service 的 Hobby Plan 裡面有寫:

You shall only use the Services under a Hobby plan for your personal or non-commercial use. We may change the features, limitations, or other conditions applicable to the Hobby plan or discontinue offering the Hobby plan at any time. We reserve the right to disable or remove any Project or website deployment on the Hobby plan with or without notice at our sole discretion. We may shut down and terminate projects or deployments using the Hobby plan without notice for any reason or no reason.

至於什麼叫商業行為呢? 在 Fair Use Guidelines 的 Commercial usage 有介紹，目前是有列出一些範圍，可能隨時會更新，以官方為主。

Commercial usage is defined as any Deployment that is used for the purpose of financial gain of anyone involved in any part of the production of the project, including a paid employee or consultant writing the code. Examples of this include, but are not limited to, the following:(以營利為目的的佈署，包括任何參與專案開發的付費員工或顧問。以下是一些例子，但不限於此：)

• Any method of requesting or processing payment from visitors of the site (任何向訪客請求或處理付款的方式)
• Advertising the sale of a product or service (宣傳銷售產品或服務)
• Receiving payment to create, update, or host the site (因建立、更新或託管網站而收取費用)
• Affiliate linking is the primary purpose of the site (聯盟行銷用途的網站)
• The inclusion of advertisements, including but not limited to online advertising platforms like Google AdSense (為了放廣告的網站)

Vercel 另外有列一個，在網站上要求抖內不算商業行為(Asking for Donations does not fall under commercial usage.)

雖然很多人都在用，但為了安全起見，如果是要做正式的商業服務，最好還是升級到付費方案，以免有一天網站突然打不開，資料都遺失。

AI 點數制度

從零開始生成一個東西很快，但一旦進入調整細節、修 bug、加功能的階段，快的地方就不一樣了...變成點數燒得飛快，花錢如流水。

每一次對話修改都算一次，UI 調整、功能迭代，全部都在扣點數，每一階方案都有點數額度限制。要理解一件事，現在滿地可以看到購物網站、會員制網站，但不代表從0開始做一個網站不用費什麼力氣。

付錢升級也不代表有無限用量，本來想省錢，結果後期維護成本比自己寫或訂閱 Claude 還高。

AI 自信地說「已修好」「已做完」，但在edge case可能還是有 bug，在使用者操作流程上還是有一些不順眼的地方，這時候又要花更多點數去 debug。

多增加一個脆弱的單點

Lovable 生出來的網頁 app，一旦功能牽涉資料庫、使用者驗證、檔案儲存等，後端會接上一些協力廠商的服務，例如 Supabase (Lovable: Integrate the backend with Supabase)。

這下好了，等於同時要處理兩邊的限制，Lovable 自己的額度和功能限制，還有 Supabase 的免費方案限制，兩邊都有各自的天花板。有一邊出問題都會影響整個 app 的運作。

早期的 CSR 模式讓網站 SEO 成效很差

他們到了 2026 年中才宣布 Building apps using TanStack Start，更換新專案的技術架構，從之前的 CSR 換成 SSR。

因為一些純 CSR(client-side rendering) 的 SPA(早期常見的 React / Vue 純前端)，HTML 幾乎是空的 <div id="app"></div>，要等一大包 JS 下載、執行、再打 API，才有網頁內容。搜尋引擎的 SEO 爬蟲也不一定抓得到內容。

Lovable 自己的公告內就舉了一些實證，像是架構更新後，爬蟲檢索速度變快、自然搜尋流量變多、從AEO(ChatGPT, Perplexity 等工具)來的流量增加了 98.5%。

但是架構更新只有給新專案使用，舊專案只能繼續用舊版架構，網頁看似很漂亮，但網站只是在搜尋引擎都找不到的 AI 玩具。

現代網頁前後端技術架構頻繁變動，業內人士也叫苦連天，但工程團隊可以依照自己的狀況來選擇。而使用這些 AI 平台的結果，容易導致既有專案被放生的問題。

也許有些網站或 app 真的做好之後就不用改，但大部分的專案都會有後續維護、功能迭代、UI 調整、bug 修正等需求，這些平台的限制和商業策略，會讓專案後續維護變得很困難。

鏟子超人個資裸奔事件

2025年花蓮光復事件中，出現很多鏟子英雄的救災物資/請求協助的資訊網站，其中一個鏟子英雄的網站就是使用 Base44 做出來的，做那個網站的人也不是一個網頁工程師，然後在碰到實際需求時，一番修改後，導致被人質疑資安有問題。

例如網站本來需要 Google login 才能填寫資料，但使用者容易在 in-app browser 被擋住，於是那個人做了一些功能調整、放寬限制，例如不用登入就能新增與修改救災需求。

然後因為 Base44 的程式設計，可以直接從 Devtools 中看到整個資料的大表 JSON，種種條件疊加之下，最後出現一個鏟子英雄和災民個資分享網站。隨便一個稍微懂點技術的人，非常容易就能把登記在網站上的各種名字、地址、電話等個資通通抓回來。

那時候去 Base44 取經一下，發現對於資料權限控制這件事，不需要使用者自己寫一堆 SQL 條件或驗證機制，Base44 直接有內建一套把 RLS 概念視覺化的操作介面，降低開發複雜度(如下圖)。

所以說最大的問題常常還是在人本身，然後專案決策問題，最後還是讓執行的人來背鍋，只是這次背鍋的人不是工程師，只是個自己掏錢買 Base44 的普通義工。

應用程式和資料都在他們的平台上

Base44 跟 Lovable 最大的差異，在 Lovable 我們可以拿走生成的程式碼，然後 Lovable 可以連結自己的 Supabase 帳號，這樣程式碼要放在哪邊跑，自己高興就好。

Base44 生成的 app 也是跑在他們平台上的，但資料庫、圖片等各種資料也存在他們那裡。如果 Base44 改定價、停服務、或是想搬走，migration 的難度比較高，底下等下會提到另一家，也有類似的問題。

Base44 在 2025 年被 Wix 收購了，在收購時有說 Base44 將繼續作為獨立產品與事業單位運作。如今過了一年，確實沒唬爛，Base44 還是活得好好的，除了有來自 Wix 的金流系統 Base44 Payments powered by Wix，還發表自家大模型 Base1，暫時還沒聞到那種平台準備消失，大家要準備搬家的味道。

• Wix Further Expands into Vibe Coding with Acquisition of Base44, a Hyper-Growth Startup that Simplifies Web and App Creation with AI
• Base44 Becomes First App-Creation Platform to Launch Its Own Proprietary LLM “Base 1”, Marking a Major Milestone in the Company's Technology Vision

用每月免費額度把人拐進來

網站程式寫好之後，會配一個免費子網域，像是 https://xxx.manus.space，頁面上面當然有 Manus 的 logo，然後想要移除 logo、自訂網域，當然就要付費升級。

在 Manus 帳號設定內可以看到「網站」有單獨一個用量表，雲服務、AI、整合服務有一些每月免費額度，超過就要儲值扣款了。

詳情可參考 Manus 官方文件的 WebDev 帳單如何運作？。

什麼? 你說那個連結裡面幾乎什麼都沒寫? 就說資料庫、API呼叫、網站內的 AI 功能、雲端託管要按需付費，依照實際消耗的資源進行計費，但根本沒有詳細的價目表。沒錯，Manus 官方文件就是這樣。

想要出走，可能表示一堆程式全部重寫

如果對 Manus 雲端不透明的計費方式有微詞，想要把程式搬走，程式碼是可以輕鬆拿到。

Manus 的介面上可以直接看到專案原始碼，然後可以下載成 zip 檔案(免費方式就行)，或是直接 push 到 GitHub。

但如果打開專案程式碼會發現:

• 沒有實際的資料庫連線資訊，一堆東西都是 process.env.DATABASE_URL 之類的環境變數，資料庫什麼的都要自己重新架設(廢話)，自己想辦法把 env 環境變數的東西全部補齊。
• 剛剛講的那個方便的 Manus 會員登入功能，當然武功全廢，Manus OAuth 沒有給外人用，請乖乖自己重弄，然後把 OAUTH_SERVER_URL 設定好，繼續用網站本來的 stateless JWT 來驗證。
• 本來的後端程式只是一個代理層，網站後端的一堆功能(例如圖片儲存，還有一些明明沒用到卻也被包進專案的)，通通都是呼叫 BUILT_IN_FORGE_API_URL，這是 Manus 私有的 API，程式碼內到處可以看到那個什麼 forge-api 的痕跡:

下載下來的程式碼有 CRUD 和一些功能邏輯，但牽涉雲端運作的部分，都要自己想辦法生出來，這就像那些科幻電影/特務片，整個機器最重要的一塊晶片或引擎被人拔走，剩下的東西根本就無法運作。

官網上的圖片現在看起來真是細思極恐，Manus 這種模式在初期很爽，後面使用人數稍微多一點，有更大機會造成帳單失控，而且程式碼的平台依賴性超高，搬走後要讓網站重新在別的地方運作起來，施工程度比本文中的一些平台還麻煩。

API Rate Limit 的問題（升級付費方案也不一定解決）

Resend 除了每日額度之外，還有 API rate limit。目前所有方案（包含免費和付費）預設的限制都是每秒最多 10 次請求（以整個 team 為單位），甚至不到這麼多請求，都有機會碰到 429 error。

如果你在一個功能流程中需要連續寄好幾封信（例如同時寄信給N位管理員 + 消費者），或者在流量高峰期有多個使用者同時觸發寄信，就很容易觸發速率限制，導致部分信件發送失敗。

相較之下，其他間寄信服務商在付費方案的速率限制普遍高出不少，這也是為什麼當服務開始成長時，很多人會考慮從 Resend 轉移到其他方案。

隱藏的工程問題

要比較安全地處理這種情況，當然不是找一家可以一秒寄無限封信的廠商，也不是直接加一堆自動重試機制，這樣可能導致同一封信被寄出兩次，或是持續失敗的重試一直累積，導致資源用盡和系統崩潰。

通常需要引入 Queue 佇列服務，讓寄信的動作變成非同步處理，並加上適當的去重邏輯。這樣做雖然能避免重複寄信和即時錯誤，但也代表系統又多了一個需要維護的服務，整體複雜度上升。

我們可以把佇列規劃成多個網站共用的私有服務，當然這會有雲端全球大當機時就一起死的問題，這不是本文重點，就不多談了。

很多人可能只看到 AI 迅速用 Resend API 做出基本寄信功能，但很少會主動提醒要處理速率限制、重試邏輯，以及可能衍生的各種工程問題。等到真的發生時，才發現寄信這件事的水很深。

CU-hours 計費機制，免費額度撐不到一個月

NeonDB 用 Compute Unit (CU) 來計費，1 CU 大概是 1 vCPU + 4GB RAM，最小可以設定到 0.25 CU，免費版最大可以設定 2 CU。

免費方案每個 project 每月有 100 CU-hours，在短短幾天的開發期間，還有跑個壓測，基本上一定用不完。

聽起來好像很多，但實際算給大家看：

• 如果網站有固定流量，每小時都會被喚醒，或有 cron job 讓 database 保持清醒，光是開 0.25 CU 跑一整天，就要消耗 0.25 × 24 = 6 CU-hours。
• 一個月30天輕鬆破 180 CU-hours，免費額度到月中就用光。
• 看系統報表還會發現，大部分時間可能只用到 0.01~0.02 CU，但 NeonDB 就是依照 0.25 CU 來計費，不能開到更低。

用完之後就會開始計費，升級到付費方案之後，沒有任何包含的免費 CU-hours，要從第一個小時開始付：

• $0.106 per CU-hour
• $0.35 / GB-month 的儲存空間

一個月大概$20美金，還是比 supabase pro 便宜，而且CPU&RAM規格還更好。但只要廠商把 0.106 小數點後面任何一個數字漲價，我們的帳單就準備迎接痛楚。

很多人在開發階段覺得很好用，等到額度用完才發現問題。

冷啟動時間不穩定

付費方案可以設定不要閒置停機，但免費版完全沒得選，閒置幾分鐘就會 scale to zero。

當使用者點進網站需要資料庫時，雲端資料庫會經歷 idle → pending → active 的過程。
有時候很快(幾十~幾百毫秒)，但有時候卻要好幾秒。這種「有時候快、有時候慢」最要命，因為我們完全無法預測，無法跟使用者或客戶交代。

整個 autoscaling、connection pooler 的行為，都是 Neon 平台幫我們控制的，不是那種「我自己能 debug」的狀態。

demo 給客戶看的時候突然卡住，突然有流量尖峰時，autoscaling 雖然會起來，但中間可能出現短暫的連線問題或查詢爆幹慢，我們只能看 NeonDB 系統面板上的 "All OK" 和 primary compute: pending 的狀態發呆。

根據 Neon 官方文件，只有最高階的付費方案(Scale Plan) 才有 99.95% uptime SLA，Free 跟 Launch 方案就別想了，故障就故障了，99.95% 大約允許每個月 20 幾分鐘的 downtime，聽起來沒多長，但是每個人都來問說什麼時候會好的時候，就是最漫長的 20 分鐘。

備份資料庫

Neon 免費版有備份，比 Supabase 好了，但非常有限，主要有兩種：

• 手動快照: 就是有什麼大型變更前，自己上去按 create snapshot，然後快照只能保存一份，如果需要更多份，或是定時自動快照，都需要升級到付費方案。
• PITR: 提供過去6小時的歷史時間點。

對玩玩而已的免費小專案也許還能接受，但如果已經開始有真正在用的使用者，需要商業承諾，或是打算長期經營，需要考慮的就更多了。

路由繞路問題

有些使用者開 Cloudflare 的網站會超級慢，因為台灣各大 ISP（尤其是中華電信）配上 Cloudflare 的各種免費或便宜方案，經常會發生繞路到 Cloudflare 香港、新加坡，再到美國甚至澳洲的慘劇，萬一你的使用者幸運碰到這種情況，網站開啟速度令人難以忍受。

當下的檢測方式，可以用使用者的網路環境執行 tracert 或 traceroute，看看跑到哪些海外節點環遊世界去了，或是在網址後面加上/cdn-cgi/trace，然後看 colo 是否連到 TPE 或 KHH 以外的節點。

對電商，或某些從社群網站來客的線上服務來說，速度就是轉換率，這絕對賭不起。

官方的建議是付費升級，升級到沒有在網頁上明碼標價的 Enterprise 方案，就能由距離地理位置最近的資料中心提供服務，並享有最高的流量優先級。

CPU 運算時間限制是 10ms

根據 Cloudflare Workers 官方限制說明，免費版的限制不是「每個請求最多跑幾秒」，而是 CPU 時間最多 10ms。

CPU 時間和牆鐘時間（wall time）不一樣。等外部 API 回應的時候，CPU 是閒著的，不算在 10ms 裡。但如果我們的程式有任何運算量稍微重的操作（JSON 解析大資料、加解密、複雜邏輯），很容易超過 10ms，然後請求直接被截斷。

付費版（$5/月）CPU 時間上限提升到 30ms，如果需要更多就要另外加購。同一份文件也指出，一般 Worker 平均約 2.2ms，所以大多數簡單的 proxy 或轉發用途還好；一旦涉及認證、SSR、大型 payload 處理，就容易踩到。

沒有完整的 Node.js 環境

Workers 跑的是 V8 isolate，不是完整的 Node.js 環境，即使開啟 nodejs_compat，支援度也有限。

很多時候 AI 會直接寫 Node.js 常見功能的程式碼（例如讀寫檔案、處理路徑、加密等），結果放到 Cloudflare Workers 上完全無法執行，必須大幅修改才能跑。

如果我們一開始沒有講明要使用 Cloudflare Workers 跟他家的哪幾個服務，AI 做出來的東西不一定相容。

也因為 Workers 的執行環境跟一般 Node.js 不太一樣，在自己電腦上測試時可能跑得好好的，但部署上去之後卻出現奇怪的錯誤，或是某些功能突然失效。

要找出問題原因，有時候會比一般技術架構麻煩很多，尤其是當專案做到後期、功能變複雜時。除錯時間一拉長，後續維護的成本就會明顯上升。

Cron 定時任務限制

有時候我們希望 Workers 在指定時間執行，免費版可以直接設定 cron trigger (要注意時區問題)

但是多設幾組就會碰到

You have exceeded the limit of 5 cron triggers.

帳號內所有 Workers 專案加總，不能超過 5 個 Cron Triggers 的限制配額。付費之後上限就變成 250 個了，

碰到限制只能另外想辦法，其他這種小地方還可以參考 Account plan limits

本文中的論點之一有「搬家很麻煩」，在 Cloudflare 這也不得不提一下，雖然它的免費額度很大，沒有特殊情況時，不會考慮要搬到其他平台，但當真的有搬走需求時，會發現整個平台依賴性跟 Cloudflare 綁得比想像中緊。

尤其是同時用到 Cloudflare 多種服務之後，要把專案完整搬到別的平台，常常需要大幅修改程式碼，而不是單純搬資料而已。

免費版 CPU time 根本撐不了一天

Azure App Service 免費版（F1 plan）每天只有 60 分鐘 CPU time，而且這個額度是整個 region 下所有免費 app 共用的，不是每個 app 各自 60 分鐘。

只要多開幾個免費的 F1 app、只要 web app 有訪客在用，CPU time 很快就燒光。

就算只是放靜態網頁，網頁裡面放幾個 PDF 下載，F1 plan 同樣也有 bandwidth 連出頻寬限額，官方沒明文說是多少，但有人測到說額度只有100多MB而已。

用完之後網站會直接被停掉，使用者進來網站只會看到

Error 403 – Web app is stopped (Quota exceeded)

要等到額度重置後才會恢復。更多官方限制詳細說明可以看 Azure App Service 配額和計量。

這個限制嚴格到根本不適合任何正式服務，連測試用都很勉強。

往上升一階費用就很高，性價比遠輸其他選項

免費版撐不住，往上升就是 D1，大約美金 $9.49/月，B1，大約美金 $54.75/月，拿到的是 1 vCPU、1.75 GB RAM。

一個月 $55 美金在有些地方可以有很不錯的選擇，但在三大公有雲就比較不划算，這些產品定價主要是設計給企業的，有大型組織的合規需求、Azure AD 整合、私有網路、SLA 保證等，加值才合理。

而在個人 side project 或小型服務，這些東西通常是最先被犧牲掉的。

免費域名被封鎖

另外 Azure 提供的免費子域名 azurewebsites.net 還有被 DNS RPZ 封鎖的先例: 微軟子網域Azure App Service突遭內政部封鎖，2.3萬網站服務異常！發生什麼事？刑事局說明來龍去脈

至於要自訂域名，那又是付費方案才有的。

冷啟動問題：省錢的代價是使用者第一個請求要等

Cloud Run 預設是「沒流量就關掉」的設計。當大約15分鐘完全沒有請求時，它會把 container 收掉以節省資源。下次有人來使用時，才會重新啟動。

這對很多 side project 來說是常見情境：一天可能只有幾十個、甚至幾個請求。結果使用者每次打開網站或使用功能，第一個請求都要等 container 重新啟動。輕量專案可能還好，但如果用了比較重的框架，冷啟動很容易跑到好幾秒，使用者體驗會明顯變差。

想解決冷啟動，可以設定至少保留一個 instance 永遠開著，但這樣就算完全沒有流量，也會開始計費。原本以為「用多少付多少」的服務，結果變成「為了讓它好用，我得一直付錢」。

背景任務幾乎跑不動：CPU 只在處理請求時才給

Cloud Run 預設的計費模式是「只有在處理請求時才給 CPU 運算資源(request-based)」。沒有請求進來時，CPU 會被大幅限制，背景程式、定時任務、WebSocket 連線、輪詢等幾乎都會停止運作。

很多人在 vibe coding 時，會想做一些簡單的自動化功能（例如定時清理資料、背景同步、定期發送提醒）。結果部署到 Cloud Run 後才發現，這些背景邏輯根本不會穩定執行。

要讓背景任務正常運作，就必須開啟「CPU always-allocated」模式，但這等於讓 instance 一直保持運作狀態，費用也會跟著上升。

這時候你才會發現，Cloud Run 的「省錢」其實是有很多條件的，然後那些條件都不符合我們的條件。

針對一些定時任務之類的需求，Cloud Run 後來又提供更多的解決方案：

Cloud Run Jobs: 專門設計用來跑批次任務或排程任務，可用於「跑完就結束」的任務，例如定時清理資料、背景同步、定期發送提醒、定時產生報表。

Cloud Run Worker Pools，推薦用於「持續背景處理」，專為持續從 queue 拉取任務這類工作設計，適合 Kafka Consumer、Pub/Sub Pull、Redis Queue Worker 等長時間運行但非 HTTP 的工作。

隱藏的儲存與掃描費用：推 image 推太兇很容易中獎

每次 build 完推上去的容器映像檔，存在 GCP 的 Artifact Registry 是另外計費的，不在 Cloud Run 的免費額度裡。image 越多、越大，storage 費用越高，舊版本沒有定期清理的話，帳單會慢慢疊上去。

而且萬一不小心點到 Artifact Registry 內的各種附加服務，例如Artifact Analysis 的漏洞掃描，每次 push 新 image 就會自動掃描，這玩意是單次計費的，vibe coding 階段你可能一天 push 幾十次測試版(也有可能是 AI 推送的)，還有一些自動預設開啟的玩意，帳單費用一下就突然暴增。

另外還有各種跨 Region 的費用，開服務時可能看到有 Taiwan 區就選 asia-east1，但是後續開其他服務時，其他服務不見得也能在 asia-east1 上面用，很容易就產生跨區傳輸費用。

公開上線後的無效流量：AI 爬蟲與無聊攻擊也會計費

Serverless 最大的賣點是號稱「用多少付多少」，但事實的真相是:

• 沒人用時，整個系統架構就有一些基本費用，有人用的時候，費用一飛衝天。
• 只要有人進來，就算是無效流量、不是真人、不是顧客、甚至不是合法用途，都照樣計費。

網站或 API 一掛上公開網路，流量從來就不只是「真正想用產品的人」。常見的無效流量包括：

• AI / SEO 爬蟲：各種 LLM 訓練爬蟲、搜尋引擎、內容抓取工具，會把公開頁面或 endpoint 從頭掃到尾。
• 自動掃描與無聊攻擊：掃 .env、wp-admin、常見漏洞路徑、亂試帳密、對 API 狂噴 404 的腳本。我們的服務可能根本不是 WordPress，但掃描器還是把常用的路徑都掃一遍，狂塞各種攻擊 payload 來測試。

這些請求對產品沒有任何價值，但在 Cloud Run 的世界裡，每一筆都可能：

• 消耗請求次數與 CPU / 記憶體秒數，直接吃掉寶貴的免費額度
• 把本來可以 scale to zero 的服務反覆叫醒，冷啟動一次又一次燒錢
• 如果後端還會連資料庫、打外部 API、寫 log、跑驗證邏輯，整條流程的費用會一起被放大

很多人以為「我這個沒什麼人用，應該幾乎零成本」，結果帳單上卻出現一堆自己完全不認識的流量。真正的使用者可能一天只有個位數，但爬蟲加掃描器一天可以幫忙「測試」幾千、幾萬次。

這裡有個常被忽略的產品邏輯差異。

有些資訊產品賣的是固定用量：這個月給你多少流量、多少空間、多少發送額度，用完就停、就變慢、就顯示 509 Bandwidth Limit Exceeded。網站可能暫時掛了、顧客會抱怨，但帳單通常還是那一筆固定月費，最壞情況是「服務停住」，不是「錢繼續無上限往外噴」。

Serverless 賣的是另一套：盡量讓網站一直活著，聽起來比較不會因為哪個服務額度用完，就整站掛掉? 問題是，雲端帳號的額度不是無限的，人類的信用卡額度也不是無限的。

線上服務可以繼續回應爬蟲與攻擊，帳單也可以繼續長；直到某個配額被鎖、警示信堆到被你發現，或是信用卡被刷到你開始認真讀 billing console。

要壓住無效流量，通常又得再加一層機制或產品，例如：

• 前面擋一層 CDN / WAF / Bot Management（Cloudflare、Cloud Armor 之類）
• API 加認證、rate limit、IP 允許清單、地區封鎖
• 對可疑路徑直接 403，不要讓每個垃圾請求都進到 container 才拒絕
• 監控異常流量、設定警示，不然帳單到了才知道被掃了一整晚

這些防護要設定、要維護，有些還要另外付錢。本來是想用 serverless 省運維、省錢，結果公開上線之後，變成一邊付運算費給無效流量，一邊再付防護費去擋無效流量。

對真正有營收的服務還說得過去；對很多 vibe coding 做出來、還在驗證想法的小型專案，這個成本結構往往一開始完全沒被算進去。

還有一個常被忽略的點：要是沒有好好檢查，AI 生成的後端預設常常是全部公開、誰來都能用，錯誤還回得很詳細，簡直比看教學還親切。

所以 serverless 的坑不只是冷啟動、背景任務或 image 儲存費。只要服務暴露在公網上，就等於同時開了一間對全世界開放、按次收費的自助餐廳。誰來吃、吃多少、是不是只來搗蛋，帳單都記在你頭上。

結論：什麼情況適合用 Cloud Run？

Cloud Run 適合「流量有明顯高峰與低谷、程式本身是 stateless、也不需要跑背景任務」的 side project。它確實能讓你快速部署，而且在流量很低的時候費用很便宜。

但如果你做的 side project 有以下任一特徵，就很容易後悔：

• 需要快速回應（冷啟動會影響體驗）
• 有某種需要背景任務或持續運作的功能邏輯
• 會頻繁 push 新版本測試
• 希望「部署之後就幾乎不用管」
• 會公開掛上網、又沒打算擋爬蟲與掃描流量

AI coding 工具可以讓你幾分鐘內就把 Docker image 推上去，但它不會告訴你：這個服務的「省錢機制」，其實是建立在對雲端架構做、程式行為的諸多限制之上。

當需求稍微偏離這些限制時，原本以為很划算的選擇，就會開始讓你付出額外的成本與教訓。

按照有多少人實際收到訊息來計費

在一個群組裡發一次主動訊息，系統會依照群組人數扣訊息發送額度。LINE OA 免費方案每月只有 200 則，下一檔就要月付 800 元。而且是月初計費——這個月快用完時付錢，也只能用到月底，下個月又重算。

開發階段感覺還好，但一旦開始有實際用戶使用、或不小心在群組發送，就很容易從免費直接跳到每月固定支出。這時候你才會發現，vibe coding 讓你快速上線的功能，後來卻變成持續的財務負擔。

群組內的 LINE bot 限制

同一個 LINE 群組，同時只能加入一個 LINE OA 帳號，如果群組內已經有其他什麼檔案整理、聊天紀錄整理、資料整理之類的 LINE bot，就很麻煩。

如果把 LINE OA bot 當成一個產品，使用者必須先加為好友（或在有 bot 的群組裡），使用者才能跟 bot 互動，可能本來只是想讓用戶收到提醒，結果卻變成要引導用戶去加一個 LINE 官方帳號，做一堆身份驗證的操作。

以為只是「呼叫 API 發訊息」，結果要自己處理一堆身份與狀態管理

這也是容易被低估的部分。

• 必須自己用某種方式把使用者的 LINE ID（或群組 ID）存起來，之後才能針對特定的人發送。
• 如果同時網站有接 LINE Login，拿到的 user ID 跟 Messaging API 用的 ID 完全不同，不能直接對應，需要做一些引導流程。
• Reply Message（即時回覆）雖然不扣訊息發送額度，但 token 有效時間很短，失敗時(例如使用者傳一個檔案，程式處理後，5分鐘才自動回應)常常要 fallback 用會扣錢的 Push Message。

程式開發上，這些事情在感覺 AI 幫我寫就好，當開始有真實用戶時，這些身份對應、錯誤處理、狀態保存，就會變成持續的維護負擔。每多一個好友，或群組多一個人，未來的潛在成本就越高。用戶成長伴隨的是成本增加。

平台政策風險比想像中高

像之前看到一個有名的案例:檔案小倉鼠，有人在社群上分享能把 LINE 檔案自動備份的 LINE OA bot，並打算收費營利，結果沒多久就收到 LINE 官方通知違反服務條款，然後帳號沒了。

大家做的東西可能因為擋到別人財路，或是 LINE 本來自己的收費功能時，而面臨帳號被停用的風險。

常常有人說抱著想法去找工程師，都會被潑冷水。
有時候真的不是我們沒事找麻煩，
而是產業中看過太多這樣的案例，
然後從業主嘴裡說出來，可能就會變成另一種樣貌:
什麼外包的程式寫的不好，導致帳號被封(干程式屁事?)，
有問題沒有先提醒(解釋權在LINE手上)，
程式不能用還想收尾款(吃霸王餐嗎?)
......搞得好像 LINE 公司是自己開的一樣，如果可以強力過件的話，做什麼行業不好，還在這邊寫程式?

同樣的產品概念在 LINE 會被封號，但是在 Telegram 或 Discord 可能就跑得好好的，只是在某些產品情況上，又會產生額外的使用者學習成本。

最後還有責任問題，LINE 只負責傳輸，不提供持久儲存。我們必須自己處理檔案的下載、保存、備份、刪除機制。

當使用者把名片、文件、照片傳給我們的 LINE OA bot 時，這些資料的儲存、安全、隱私保護，就全部變成你的責任。有人質疑資料外洩、檔案不見、內容處理有錯誤，要做出回應跟處理的都是人類，而不是 AI。

預算警示 ≠ 自動停止服務

GCP、AWS 的預算設定，預設只是發通知，不會自動停止任何服務。收到警示信之後，你還是要自己手動進去關掉，帳單才不會繼續跑。

GCP 有提供「Budget Actions」可以自動觸發停用計費（等同把整個 project 的服務都關掉），但這個功能要另外設定，而且粒度是整個 project，不是單一服務。AWS 同樣可以透過一些服務來自動處理，但也是要自己搭。

儲存類服務就像房租，資料放著就收費

這是最常被誤解的地方。

雲端的很多服務的計費邏輯是：資料放在裡面就一直收費，跟有沒有人在讀寫、有沒有人在使用、程式有沒有在執行無關。

就像租房子，東西擺在房間裡就要付月租，難不成你出門工作的時候，房東就不收你租金？雲端服務的資料庫、物件儲存也是同樣邏輯，你把資料存進去、然後去睡覺，帳單照樣在跑。

設一個「$5 上限」不會讓雲端業者把你的資料刪掉，不會讓費用停止計算，只是寄封通知信給你。資料還在，費用當然還在繼續跳表計算。

真正有效的控制方式

• 刪掉不用的資源（專案舊版本的 container image、過期的 snapshot 等等）
• 有些服務可以設定自動清理策略，但也要注意服務異常時，這些策略可能引發奇怪的連鎖反應
• 要自動停止某些服務的話，需要額外寫程式去串接，不是只在帳務管理設個數字就好
• 定期進 dashboard 看費用明細