Firebase Cloud Messaging (FCM)
原理剖析、費用陷阱與架構觀點
許多開發者以為 FCM 只是「發 Send Notification 的免費 API」，但實務上它涉及 Token 生命週期管理、iOS APNs 整合、背景與前台 Payload 處理等繁雜機制。本文將帶你一次弄懂 FCM 的底層運作與核心價值。
資深後端與 App 架構團隊
2026 年最新專題研究
Firebase Cloud Messaging 是什麼？
Firebase Cloud Messaging (FCM) 是 Google 提供的跨平台訊息推送解決方案（前身為 GCM，Google Cloud Messaging）。它讓你可以跨 Android、iOS、Web (PWA)、Flutter 與 React Native 等各種平台，安全且低耗電地即時傳遞訊息與通知。
在沒有 FCM 之前，如果你要自建推送系統，你必須在 App 端維持一個長連接（Long Connection）Socket，這不僅會對伺服器造成巨大連線壓力，更會極速耗盡使用者的手機電量。FCM 扮演的就是**「統一長連接通道」**的角色，由作業系統層級（Google Play Services / Apple APNs）統一維護通道，你的伺服器只需要對 FCM 發送 HTTP REST API 請求即可。
一句話理解 FCM 的本質：它不是廣播電台，而是『信差轉運站』。你的 Server 交代好信件（Payload）與收件人地址（Device Registration Token），剩餘的可靠度、排隊重試與耗電控制全部交給 Google 底層解決。
FCM 的 3 大核心能力：
可對「單一裝置 (Token)」、「裝置群組」或「主題 (Topic)」進行發送（如推播訂閱新聞標籤）。
支援系統自動顯示的「通知訊息 (Notification Message)」與靜默喚醒 App 的「資料訊息 (Data Message)」。
整合 Google Analytics，可精準追蹤推播開啓率 (CTR)、轉化率，甚至直接進行推播文案 A/B Testing。
FCM 費用說明：真的完全免費嗎？
FCM 服務本身完全免費，且無限量！
Google 官方承諾，不論你每天發送 100 條還是 10,000,000 條推播訊息，FCM 本身的 API 呼叫與傳遞服務完全不需要付費，也沒有訂閱等級或發送上限（No Daily Limit）。
魔鬼藏在細節裡：不可忽視的「隱形衍生成本」
許多團隊在專案規模擴大後，發現 Firebase 帳單暴增，便誤以為是 FCM 在收費。事實上，費用來自於**圍繞 FCM 架構的周邊基礎設施**：
1. Serverless 計算成本 (Firebase Functions / Cloud Run)
如果你利用 Firebase Cloud Functions 來監聽數據庫（如 Firestore 寫入時觸發推播），當使用者量大時，Cloud Functions 的執行次數與 CPU 時間將產生費用。
2. Token 儲存與查詢成本 (Database Read/Write)
每個 App 安裝後都會產生一個 Registration Token，你需要將其儲存在數據庫中（如 Firestore/MongoDB）。百萬級用戶的 Token 寫入、更新與批次查詢 reads/writes 費用相當可觀。
3. Apple Developer Program 規費 (iOS 推送必須)
要讓 FCM 成功推送到 iOS 裝置，你的 FCM 後端終究需要透過去 Apple APNs (Apple Push Notification service)。因此你必須維持每年 99 美元的 Apple 開發者帳號費用來獲取 APNs 憑證。
底層運作機制與訊息類型抉擇
FCM 的推送訊息架構可分為兩大類。選擇錯誤的訊息種類，常常是造成「iOS 收不到推播」或「Android 背景被切掉」的罪魁禍首。
Notification Message (通知訊息)
自動渲染
帶有 notification Key 的 JSON。當 App 在背景時，SDK 系統底層會自動顯示通知欄，不需要開發者撰寫程式碼呈現。
{
"message": {
"token": "bk3RN1...",
"notification": {
"title": "新優惠通知",
"body": "您有 8 折折價券即將過期！"
}
}
}
Data Message (資料訊息)
自訂解析
僅帶有 data Key 的 JSON。不論前台背景，都會將 Payload 直接交給 App 的 Service 手動處理（如靜默更新背景數據、自訂 UI）。
{
"message": {
"token": "bk3RN1...",
"data": {
"type": "chat_message",
"sender_id": "8801",
"content": "今晚一起吃飯嗎？"
}
}
}
FCM 全端通訊生命週期：
資深架構師觀點：FCM 避坑與實戰心法
在大型生產環境中，FCM 最難的往往不是「怎麼發出推播」，而是**「Token 的維護衛生」**與**「系統的容錯設計」**。以下是我多年來踩過無數個坑後總結的 4 個核心觀點：
觀點 1：Token 清理機制比發送邏輯更重要！
使用者解除安裝 App、清除快取、或是長期不開啟，Token 都會失效。如果你不做 Token 衛生維護，資料庫會充斥著死 Token。
實體作法：每次後端發送推播時，務必監聽 FCM 回傳的 UNREGISTERED 或 INVALID_ARGUMENT 錯誤，一旦收到立刻從資料庫刪除或標記失效，否則幾百萬無效 Token 會拖垮你的批次推送效率。
觀點 2：iOS 的 APNs 整合是噩夢的源頭，一律全面升級 HTTP v1 API
舊版的 Legacy FCM API (Server Key) 即將完全廢棄，請務必使用最新的 FCM HTTP v1 API（採用 OAuth2 認證）。
HTTP v1 允許你精確地針對 iOS 撰寫 apns 專屬屬性（如角標 badge、聲音 sound、content-available），避免因 Android/iOS 屬性混用導致 iOS 靜默推播失效。
觀點 3：不要相信「100% 抵達率」，關鍵業務必須有 Fallback 備援
FCM 雖然可靠，但受到中國大陸網路環境、Android 廠商極致殺背景（如小米/華為省電策略）以及使用者關閉通知影響，推播絕對不是 100% 必達的。 如果是「交易驗證碼」、「扣款成功通知」等核心業務，絕不能只依靠 FCM！必須設計「App 內通知中心 API」或「簡訊/Email 備援機制」。
觀點 4：小心 4KB Payload 限制與過度頻繁推送
FCM 的 Payload 大小上限是 4KB (4096 bytes)。切記不要把大筆的 JSON 數據硬塞在推播裡。正確的做法是：推播只帶 message_id，App 收到推播後再向你的 Server REST API 拉取完整資料。
實戰工具：FCM Payload 顯示模擬器
調整標題、內容、訊息類型與平台，預覽通知可能呈現的方式。實際顯示仍由作業系統與 App 設定決定。
Notification message 可由系統在背景狀態下顯示通知。
鎖定畫面預覽