昨天拜訪了聞聲錄字的俠客 Google Cloud Speech-to-Text，留下了一個問題：
要請這位高手出手，得先出示令牌（Google Cloud 的憑證）。
但令牌不適合發給每一支長輩的手機，萬一外流，帳單會寄到府上。
這其實是很多 App 開發者都會遇到的問題，特別是沒有自己後端的獨立開發者：
金鑰要放哪裡？
有沒有更省事的做法？
帳單會不會失控？
今天就來逛逛府外的一整條商業街「Firebase」，
並認識街上專門替人押送貨物的鏢局「Cloud Functions for Firebase」！
官方首頁的介紹：
Firebase is a platform of services to help you and AI agents build and run intelligent apps with more speed, security, and scalability.
意思是：Firebase 是 Google 提供的一整套服務，協助開發者更快、更安全、更容易擴展地打造並營運 App。
| 重點 | 說明 |
|---|---|
| 涵蓋範圍 | 為 App 開發的完整生命週期設計：從打造到上線後的營運 |
| 服務對象 | 行動 App、Web App，也包含遊戲 |
| 支援平台 | Apple 平台、Android、Web、Flutter、Unity、C++（伺服器端另有 Admin SDK） |
| 主要產品分區 | AI、Build（打造）、Run（營運） |
| 底層 | 以 Google Cloud 為基礎；每個 Firebase 專案，背後都是一個 Google Cloud 專案 |
用商業街來比喻：
街上有幫忙打造 App 的店家（登入、資料庫、檔案、後端程式），
也有上線後照顧 App 的店家（當機回報、使用分析、推播），還有 AI 相關的店家。其中 Build（打造）的服務，
就是常聽到的 BaaS（Backend as a Service，後端即服務）： 登入、資料庫、檔案儲存這些後端功能，不用自己架伺服器，直接使用現成的雲端服務。
AI| 產品 | 做什麼 |
|---|---|
| Firebase AI Logic | 從 App 直接呼叫 Gemini 模型 |
| Genkit | 開源框架，用來在伺服器端開發 AI 功能 |
| Gemini in Firebase | Firebase 主控台裡的 AI 助理 |
| AI 工具（agent skills、MCP server） | 讓 AI agent 也能使用 Firebase 的工具 |
Build| 產品 | 做什麼 |
|---|---|
| Authentication | 使用者登入：匿名、Email、Google、Apple 等 |
| Cloud Firestore | 文件型 NoSQL 資料庫，可以即時同步 |
| Realtime Database | 以 JSON 樹狀結構儲存、低延遲同步的資料庫 |
| SQL Connect | 以 Cloud SQL for PostgreSQL 為基礎的關聯式資料庫 |
| Cloud Storage for Firebase | 存放使用者上傳的圖片、音訊、影片 |
Cloud Functions for Firebase |
在雲端執行後端程式（今天的主角） |
| App Check | 確認請求來自正版 App、未被竄改的裝置 |
| Hosting、App Hosting | 部署網站與 Web App |
Run| 產品 | 做什麼 |
|---|---|
| Crashlytics | 當機回報 |
| Performance Monitoring | 效能監控 |
| Test Lab、App Distribution | 在雲端裝置上測試、發佈測試版 |
| Google Analytics | 使用行為分析 |
| Cloud Messaging（FCM） | 推播通知 |
| Remote Config | 不發新版，就能調整 App 的設定 |
| A/B Testing、In-App Messaging | 比較不同版本的效果、App 內訊息 |
Firebase 有兩種方案：免費的 Spark，以及隨用隨付的 Blaze。
| 比較項目 | Spark | Blaze |
|---|---|---|
| 付款資訊 | 不需要 | 要連結 Cloud Billing 帳戶 |
| 免費產品（Crashlytics、FCM、App Check、Analytics 等） | 完整使用 | 完整使用 |
| 有免費額度的付費產品（Firestore、Realtime Database 等） | 只有免費額度 | 免費額度，超過的部分隨用隨付 |
| Cloud Functions | 不能部署（可以在本機模擬） | 可以部署 |
| Cloud Storage for Firebase | 不能使用 | 可以使用，仍有免費用量 |
| Google Cloud 付費服務（Cloud Run 等） | 不能使用 | 可以使用 |
| 超過免費額度時 | 該產品當月停用 | 照用量計費 |
小提醒：
方案套用在整個專案，專案裡的所有 App 共用同一個方案。- 在 Google Cloud 主控台連結帳單帳戶，或在同一個專案開始使用 Cloud Run 等 Google Cloud 服務，
專案會自動升級成 Blaze。
Cloud Functions 在 Blaze 的每月免費額度（Firebase 價格頁，2026 年 9 月）：
| 項目 | 每月免費 | 超過之後 |
|---|---|---|
| 呼叫次數 | 200 萬次 | 每百萬次 US$0.40 |
| GB-秒（記憶體 × 執行時間） | 40 萬 | 依 Google Cloud 價格 |
| CPU-秒 | 20 萬 | 依 Google Cloud 價格 |
| 對外網路流量 | 5 GB | 每 GB US$0.12 |
部署函式時會建置容器映像檔，這部分另有免費額度（Cloud Build 每天 120 分鐘、Artifact Registry 儲存 500 MB）。 官方提到容器儲存可能產生小額費用，所以
就算用量都在免費額度內，Cloud Functions 仍可能出現少量的帳單。
隨用隨付很有彈性，但也讓人擔心帳單失控。Blaze 有三種工具可以搭配使用：
| 工具 | 做什麼 | 會暫停服務嗎 |
|---|---|---|
| 預算提醒（alerts-only budget） | 花費到設定的門檻時寄 email | 不會 |
| 設定花費上限（spend cap，Preview） | 某項服務的當月花費達到預算時，暫停該服務到月底 | 會 |
| API 配額（quota） | 限制 API 的使用速率 | 超過時回傳錯誤 |
設定花費上限的幾個重點：
| 重點 | 說明 |
|---|---|
| 支援的服務 | 目前只有 Firebase AI Logic、App Hosting、Cloud Functions、Extensions |
| 不是即時的硬上限 | 用量回報有延遲，可能晚幾分鐘才生效，這段時間的費用照常計算；官方建議設得比真正的底線再低一點 |
| 以服務為單位 | 一個花費上限，只管一個專案裡的一項服務 |
| 下個月自動恢復 | 被暫停的服務，下個月初會自動恢復，也可以手動解除 |
| 設定位置 | Firebase 主控台：Settings > Usage and billing > Details & settings |
Cloud Functions 的花費上限，管的是函式本身（底層的 Cloud Run functions）；
函式裡呼叫的 Cloud STT 屬於另一項服務，目前不在花費上限的支援清單上。
可能需要替這些服務另外設預算提醒，並搭配 API 配額一起控管。
另一個需要留意的地方：
專案升級 Blaze 之後，Gemini Developer API 的呼叫都會改成隨用隨付，不再適用免費層。想用 Cloud Functions，又想用 Gemini 的免費層時，這點要一起考慮。
官方介紹：
Cloud Functions for Firebase is a serverless framework that lets you automatically run backend code in response to events triggered by background events, HTTPS requests, the Admin SDK, or Cloud Scheduler jobs.
意思是：把後端程式交給 Google 保管與執行，有事件或請求時才自動執行，不用自己管理伺服器。
官方列出的三個特點：
| 特點 | 說明 |
|---|---|
| 整合 Firebase 與 Google Cloud | 可以回應 Authentication、Cloud Storage 等產品的事件，也能透過 Admin SDK 操作其他 Firebase 服務 |
| 免維護 | 一個指令就能部署，之後依使用量自動擴縮；不用處理憑證與伺服器設定 |
| 邏輯私密且安全 | 程式在伺服器上執行，與 App 隔離，不會被竄改或反組譯 |
有些事情，只靠 App 自己做會遇到限制：
| 需求 | 只靠 App 的情況 | 交給 Cloud Functions |
|---|---|---|
呼叫需要金鑰的 API |
金鑰打包進 App，就有機會被取出 | 金鑰留在雲端，App 只呼叫函式 |
不能被竄改的邏輯（計分、發獎勵） |
App 端的程式可能被修改 | 在伺服器上執行 |
控制用量（每人每天幾次） |
App 端的限制可能被繞過 | 在函式裡檢查身分與次數 |
資料變動後要做的事 |
App 要開著才做得到 | 由事件觸發 |
定時執行的工作 |
App 沒開就不會執行 | 排程函式 |
接收第三方通知（webhook） |
App 沒有固定網址可以接收 | HTTP 函式提供固定網址 |
談到金鑰，有一個可能混淆的地方：
| 金鑰 | 可以放進 App 嗎 | 官方說明 |
|---|---|---|
| Firebase API key（firebase_options.dart裡那一串） | 可以 | 只用來識別專案與 App；資料安全靠 Security Rules、App Check、IAM |
| Gemini API key | 正式環境不建議 | 編譯進 App 的金鑰可以被取出，官方建議透過後端代理呼叫 |
Firebase API key 不是機密，Gemini API key 是。兩者名字很像，性質不太一樣。
前提：Firebase API key 只拿來用 Firebase 的服務；不要設定這把 Firebase API key 去呼叫其他付費的 API。
有些需求，其他做法可能更直接。
這類比較不同方案得失的評估，常稱為技術選型或權衡分析（trade-off analysis）：
| 情況 | 可以考慮 | 說明 |
|---|---|---|
| 運算能在手機上完成 | 地端處理 | 不需要網路、不另外計費、延遲低；例如本系列介紹過的 MediaPipe、sherpa-onnx |
| 只想從 App 呼叫 Gemini | Firebase AI Logic | 官方的 SDK 與代理服務，Gemini Developer API 的金鑰不用放進 App；2026 年 11 月 2 日起要強制啟用 App Check |
| 讀寫使用者自己的資料 | Firestore、Cloud Storage 搭配 Security Rules | App 直接讀寫，權限由規則控管 |
| 需要長連線、WebSocket，或想用其他程式語言 | Cloud Run 服務 | Cloud Functions for Firebase 支援 JavaScript、TypeScript、Python，另有 Dart 實驗性支援（目前只有 HTTP 與 callable 函式）；Cloud Run 可以執行任何能包成容器的程式。彈性更大，要自己處理的事情也比較多 |
Cloud Functions 最能發揮的，是一定要在伺服器上做的事：
保管憑證、不能被竄改的邏輯、事件觸發與排程。
其他需求，可以先比較不同做法的成本與維護負擔。
部署時
| 步驟 | 發生什麼事 |
|---|---|
| 1 | Firebase CLI 把程式碼壓縮後，上傳到專案的 Cloud Storage |
| 2 | Cloud Build 建置程式碼，產生的容器映像檔存進 Artifact Registry |
| 3 | 新版函式上線，舊版的執行個體被清掉 |
執行時
| 階段 | 發生什麼事 |
|---|---|
| 待命 | 沒有請求時，執行個體可以縮到 0 |
| 觸發 | 事件或請求符合條件，函式開始執行 |
| 擴縮 | 忙碌時自動增加執行個體，閒置時回收 |
縮到 0 之後的第一個請求，要先把執行環境準備好，
稱為冷啟動（cold start），通常會慢一些。
就像員工都回家休息了，第一位客人上門時，得先把人叫回來。
兩個版本
| 比較項目 | 1st gen | 2nd gen |
|---|---|---|
| 底層 | 原始版本 | 部署成 Cloud Run 服務 |
| 最長執行時間 | 9 分鐘 | HTTP、callable 60 分鐘；排程、Task queue 30 分鐘；其他事件 9 分鐘 |
| 並行 | 一個執行個體一次處理 1 個請求 | 一個執行個體最多同時處理 1,000 個請求 |
官方建議新的函式盡量使用 2nd gen。
觸發方式：函式什麼時候會執行
| 類型 | 什麼時候執行 | 例子 |
|---|---|---|
HTTP 函式（onRequest） |
收到 HTTP 請求 | 公開 API、webhook |
Callable 函式（onCall） |
App 透過 Firebase SDK 呼叫 | App 請後端做某件事 |
排程函式（onSchedule） |
到了設定的時間 | 每天清理資料 |
Task queue 函式（onTaskDispatched） |
佇列分派工作 | 需要限速、重試的長工作 |
Firestore 事件（例如 onDocumentCreated） |
文件新增、修改、刪除 | 資料變動後發通知 |
Cloud Storage 事件（例如 onObjectFinalized） |
檔案上傳、刪除 | 產生縮圖、處理音訊 |
Authentication 事件 |
註冊、登入之前；帳號建立、刪除之後 | 限制誰能註冊、寄歡迎信 |
今天逛了 Firebase 這條商業街，也認識了街上的鏢局 Cloud Functions for Firebase：
令牌交給鏢局保管、伺服器交給 Google 打理、請帳房幫忙盯著花費：文章開頭的三個問題，都找到了對應的做法！
認識了鏢局的規矩，明天就來正式開張：
建立 Firebase 專案、寫下第一支函式，
在本機模擬測試、部署上線，再讓 Flutter App 呼叫它。
明天就來開張鏢局：Cloud Functions for Firebase（中）！
感謝有緣看到這邊的你～
希望佛菩薩也祝福你：🌟平安開心 健康自在🌟
南無觀世音菩薩🍀 南無地藏菩薩🏠 南無阿彌陀佛☀️
iThome鐵人賽
看影片追技術