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 预算和提醒