Firexport / 部落格

自 2026 年 9 月 1 日起，Firebase Remote Config 依應用程式 fetch 設定的頻率計費。每天前 100,000 次 fetch 在所有方案中都免費。超過的部分，Blaze 專案按 fetch 次數付費，Spark 專案最終會被限流。大多數應用程式都不會超過這條線。你的應用程式會不會超過，與其說取決於有多少使用者，不如說取決於程式碼中的一項設定：最短擷取間隔（minimum fetch interval）。

價格

• 這 100,000 次是以專案計算的。同一個專案中的 Android 應用程式、iOS 應用程式和網站共用這個額度。
• 它是以天計算的，清閒的日子無法抵銷忙碌的日子。上線當天如果有 1,000,000 次 fetch，即使當月其餘日子都在 100,000 次以內，這一天也要花 US$5.40。
• 你的程式碼和 SDK 版本都不需要變更。Firebase 在自己那一端計算 fetch 次數，兩種方案都是如此。

新的計價何時套用到你的專案

在 2026 年 9 月 1 日之前啟用 Remote Config 的專案會先有一段過渡期。至於是哪一段，取決於專案使用的方案：

計價頁面沒有說明在 11 月 15 日到 12 月 1 日之間升級的 Spark 專案會怎樣。如果你打算這麼做，請以 12 月 1 日開始計費來準備。

該不該在 11 月 15 日之前升級？

• 如果你的專案每天的 fetch 少於 100,000 次，不需要。Spark 會照常運作，Blaze 也一樣。
• 如果超過或接近這個數字，在 11 月 15 日之前升級可以多爭取兩個月，也就是 12 月和 1 月，在產生任何費用之前把 fetch 次數降下來。留在 Spark 的另一個結果是限流，對大多數應用程式來說，這比付幾美元更糟。
• Blaze 會把專案連結到一個 Cloud Billing 帳戶，而且沒有支出上限。其他產品仍保有各自的免費用量，你只需要為超出的部分付費。升級時請設定預算快訊（見下文）。

Spark 上的限流代表什麼

Spark 專案第一次在一天內超過 100,000 次 fetch 時，30 天的寬限期就開始了，這段期間每次 fetch 仍會得到回應。即使用量在這段期間回到線下，倒數也不會暫停或重設。從第 31 天起，每天第 100,000 次之後的 fetch 都會被拒絕。應用程式會照常運作，但 fetch 被拒絕的裝置會停留在原有的值，或使用應用程式內的預設值：逐步推出、A/B 測試或緊急關閉開關（kill switch）都無法送達這台裝置。用量接近上限時，專案管理員會收到電子郵件，控制台也會顯示橫幅，所以收件匣裡出現警告時，就該去看看了。

計算你的 fetch 次數

一次 fetch 指的是送達 Remote Config 伺服器的一個要求：

其他 Firebase 產品在內部發出的呼叫也不會計入。要查看你的專案發出多少次 fetch：

• Firebase 控制台：用量和帳單（Usage and billing）中的 Remote Config 區段。在 Spark 上，配額進度資訊卡會顯示當天的 fetch 次數與 100,000 的對照。在 Blaze 上，長條圖會依價格級距拆分每一天的用量。
• Google Cloud 控制台：IAM 與管理 > 配額與系統限制（IAM & Admin > Quotas & System Limits），篩選 firebaseremoteconfig.googleapis.com，兩種方案都適用。在 Blaze 上，Cloud Billing 報表會把費用列在 SKU Fetch Requests 之下：2026 年 9 月 1 日當天或之後建立的專案是 37B1-4623-6F54，更早的專案是 598C-0184-404A。

接著用典型一天的 fetch 次數除以 Analytics 中當天的活躍使用者數。在預設的 12 小時間隔下，如果沒有即時監聽器，一台裝置每天最多 fetch 約 2 次，所以結果是 2 或更少；如果許多使用者在多台裝置上使用應用程式，或用多個瀏覽器造訪你的網站，會稍微高一點。如果遠高於 2，就表示你的程式碼中有某個地方略過了間隔，關於額外 fetch 的段落會告訴你該從哪裡找起。

你的應用程式要付多少錢

每天的 fetch 次數等於每日活躍使用者數乘以每位使用者每天的 fetch 次數。填入你自己的數字，或你預期上線後會達到的數字：

幾種規模在 Blaze 上的費用，以每天都相同的 30 天月份計算：

每日活躍使用者有 1,000,000 位時，把每位使用者的 fetch 次數從 10 次降到 2 次，每個月可以省下約 US$1,440。反過來看，免費的 100,000 次可以容納多少每日活躍使用者：

額外的 fetch 從哪裡來，以及如何減少

每個 fetch 方法都會先檢查最短擷取間隔。在間隔之內，SDK 會回傳已有的值，不會發出要求。所以應用程式發出多少次 fetch，取決於這個間隔怎麼設定，以及少數幾種繞過它的做法。先找出程式碼中設定或略過它的每一個地方：

grep -rniE "minimumfetchinterval|fetch\(0|expirationduration|timespan\.zero" \
  --exclude-dir={node_modules,build,Pods,.dart_tool,.gradle} .

1. 留在正式環境中的短擷取間隔

在 Android、Apple 平台、Web 和 Flutter 上，預設值都是 12 小時。更短的值來自開發時的設定和範例程式碼：Firebase 自己的 Flutter 入門程式碼設定了 1 小時，「以便頻繁重新整理」，許多教學課程也照抄了它。如果原封不動地發布，1 小時的間隔會讓每台裝置在距離上次 fetch 滿 1 小時後開始的每個工作階段中 fetch 一次，每天最多 24 次。請只在偵錯版本中使用短間隔：

// Android (Kotlin). On AGP 8+, BuildConfig.DEBUG needs
// buildFeatures { buildConfig = true } in build.gradle.
Firebase.remoteConfig.setConfigSettingsAsync(
    remoteConfigSettings {
        // 12 hours in release builds
        minimumFetchIntervalInSeconds = if (BuildConfig.DEBUG) 60 else 43200
    }
)

// iOS (Swift)
let settings = RemoteConfigSettings()
#if DEBUG
settings.minimumFetchInterval = 60
#else
settings.minimumFetchInterval = 43200 // 12 hours
#endif
RemoteConfig.remoteConfig().configSettings = settings

// Flutter. kDebugMode is in package:flutter/foundation.dart.
await FirebaseRemoteConfig.instance.setConfigSettings(RemoteConfigSettings(
  fetchTimeout: const Duration(minutes: 1),
  minimumFetchInterval:
      kDebugMode ? const Duration(minutes: 1) : const Duration(hours: 12),
));

// Web. 12 hours is the default, so deleting the line does the same.
const remoteConfig = getRemoteConfig(app);
remoteConfig.settings.minimumFetchIntervalMillis = 12 * 60 * 60 * 1000;

對於很少變動的值，Firebase 建議再拉長一些，設為 24 或 48 小時。如果你縮短間隔是為了讓變更盡快送達使用者，即時更新（4）可以做到這一點，而且每次變更只需要一次 fetch，而不是每個工作階段一次。

2. 為了修正「Remote Config 沒有更新」而加上的 fetch(0)

對於「我的新值沒有出現」這個問題，常見的解答是在 fetch 呼叫中傳入為零的間隔。在 Android 和 Apple 平台上，這個引數會優先於設定，所以不管間隔怎麼設定，每次呼叫都會送到伺服器：

// Each of these ignores the interval and goes to the server on every call:
remoteConfig.fetch(0)                                // Android
remoteConfig.fetch(withExpirationDuration: 0)        // iOS
remoteConfig.FetchAsync(TimeSpan.Zero)               // Unity

移除這個引數，讓設定好的間隔生效。使用者看到的值仍會在 12 小時內更新，如果有即時監聽器，則會立即更新。

3. 在每個畫面、每次回到前景或背景喚醒時都 fetch

在每個畫面的初始化、每次 onResume、每次元件掛載時 fetch，或在 Application.onCreate 中 fetch（推播訊息或背景工作喚醒應用程式時，它也會執行），都會讓間隔所允許的次數成倍增加。間隔是 12 小時時影響不大，因為這些呼叫大多在裝置上就得到回應。間隔很短或使用 fetch(0) 時，大量的 fetch 就是從這裡來的。只在應用程式於前景啟動時 fetch 一次，其他地方都用 getter 讀取值。Firebase 把在背景發生的這些稱為「幽靈 fetch」（ghost fetches），並將它們列為最先要檢查的項目之一。

4. 即時更新和頻繁發布

應用程式在前景時，即時監聽器會維持一條連線，這條連線是免費的。你發布新的範本版本時，每台正在監聽的裝置都會下載它，每次下載都是一次 fetch，而且不受間隔限制。之後才開啟應用程式、手上還是舊版本的裝置，也會以同樣的方式取得新版本。所以每次發布，不論改了什麼，在下一次發布之前，每台執行你應用程式的裝置最多都會產生一次 fetch。

200,000 台裝置，一天發布 10 次，光是即時更新最多就會產生 2,000,000 次 fetch，以每 10,000 次 US$0.06 計算，當天大約 US$12。把多項編輯合併成一次發布，而不是分成好幾次小的發布；只在需要立即生效的地方加入監聽器，例如緊急關閉開關。

5. 每個伺服器要求都載入一次範本

伺服器端 Remote Config 仍是預覽版（Preview），它透過 Admin SDK 下載整個範本，每次下載都是一次 fetch。在 Cloud Function 或 Cloud Run 的處理常式中呼叫 getServerTemplate()，每個要求都會產生一次 fetch，所以光是一個忙碌的端點就可能每天超過 100,000 次。請在每個伺服器執行個體中只載入一次，並用計時器重新整理：

import { initializeApp } from "firebase-admin/app";
import { getRemoteConfig } from "firebase-admin/remote-config";

initializeApp();

const DEFAULTS = { welcome_message: "Hello" };
// At most one fetch per server instance every 10 minutes.
const REFRESH_MS = 10 * 60 * 1000;

let templatePromise; // one template per server instance, kept between requests
let loadedAt = 0;

export async function getConfig() {
  if (!templatePromise) {
    loadedAt = Date.now();
    templatePromise = getRemoteConfig()
      .getServerTemplate({ defaultConfig: DEFAULTS })
      .catch((err) => {
        templatePromise = undefined; // try again on the next request
        throw err;
      });
  }

  const template = await templatePromise;

  if (Date.now() - loadedAt > REFRESH_MS) {
    loadedAt = Date.now();
    // Refreshes in the background. Until it lands, requests get the
    // values already loaded.
    template.load().catch((err) => console.error("Refresh failed", err));
  }

  return template.evaluate();
}

每 10 分鐘重新整理一次，每個執行中的執行個體每天就是 144 次 fetch，與流量無關。透過 REST API 讀取範本的指令碼和 CI 工作也會計入，不過次數很少，通常無關緊要。

改用 Blaze 時設定預算快訊

Blaze 沒有硬性上限。在 Google Cloud 控制台中開啟帳單（Billing） > 預算與快訊（Budgets & alerts），為專案建立一個預算，金額接近上方計算機算出的數字。根據預設，它會在達到該金額的 50%、90% 和 100% 時寄送電子郵件給帳單管理員。它不會阻止支出，所以收到第一封電子郵件時，就該去看看用量和帳單（Usage and billing）頁面上的 Remote Config 圖表了。

常見問題

Firebase Remote Config 還是免費的嗎？

每個專案每天 100,000 次 fetch 以內免費，Spark 和 Blaze 都一樣。在裝置上讀取值、A/B Testing、逐步推出和個人化都不另外收費。每天超過 100,000 次之後，Blaze 專案每 10,000 次 fetch 支付 US$0.06，Spark 專案則會在 30 天寬限期過後被限流。

現有專案什麼時候開始收費？

Blaze 上的專案從 2027 年 2 月 1 日開始。Spark 上的專案不會被收費：100,000 次的上限從 2026 年 12 月 1 日起適用於它們；如果在 2026 年 11 月 15 日之前升級到 Blaze，則從 2027 年 2 月 1 日開始計費。

每天 100,000 次的上限是以應用程式還是以專案計算？

以專案計算。同一個 Firebase 專案中註冊的所有應用程式共用這個額度。

需要修改程式碼或更新 SDK 嗎？

不需要。計量是在 Firebase 的伺服器上進行，在 Spark 和 Blaze 之間切換也不需要修改應用程式。只有想減少 fetch 次數時，才需要修改程式碼。

即時 Remote Config 會比較貴嗎？

維持連線本身不會計入。你發布之後，每次下載新的範本版本都會計入，每台裝置一次，而且不受最短擷取間隔限制。

Remote Config 改了值，為什麼使用者那邊沒有更新？

通常是最短擷取間隔造成的：根據預設，裝置會把值保留最多 12 小時，而且 fetch 到的值要在 activate() 之後才會生效。新的計價實施以來，Spark 專案在每天 fetch 超過 100,000 次滿 30 天之後，也可能被限流。縮短間隔之前，請先查看用量和帳單（Usage and billing）中的 Remote Config 區段，因為縮短間隔會讓限流更嚴重。

資料來源

• Remote Config 計價：價格、過渡日期、哪些算是 fetch、在哪裡查看用量
• Remote Config 限流和載入策略：12 小時的預設值，以及哪些做法會覆寫它
• 即時 Remote Config：更新是如何下載的
• 伺服器端 Remote Config
• Cloud Billing 預算與快訊