本文目录

自 2026 年 11 月 2 日起，Firebase 可在项目中为 Firebase AI Logic 自动强制启用 App Check（若尚未强制）。按 2026 年 10 月 27 日 Firebase 发布记录，目的是在经 Firebase AI Logic 访问 Gemini API 时加强防护。未携带有效 App Check 令牌的请求会被拦截，范围包括尚未接入生产环境 attestation 的已发布应用——不只是本地未完成的构建。

这是该时间窗下的迁移与排障清单：确认调用路径 → 判断是否需要临时延后 → 接入生产 attestation → 观察请求／App Check 指标 → 启用或确认强制。范围始终是 Firebase AI Logic，不是所有 Gemini API 调用。不经 Firebase AI Logic 的直连 Gemini API 流量是另一条面，不是这次 11 月 2 日自动强制通知所针对的对象。

各项目何时真正开始强制，以该项目 Firebase 控制台 Security > App Check 页面和实时请求指标为准。仅供参考。

计划生效日改了什么

Firebase 2026 年 10 月 27 日发布记录写明：自 2026 年 11 月 2 日起可为 Firebase AI Logic 自动强制 App Check；若仍有未接 App Check 的已发布版本，可临时延后自动强制。Firebase AI Logic FAQ 重复同一日历，并给出硬截止：过了 2027 年 1 月 21 日，就不能再为 Firebase AI Logic 延后自动强制。

官方表述没有公布具体 UTC 小时或具名时区。把「11 月 2 日」读作日历日期，比自行假定午夜截止更稳妥。

强制开启后，FAQ 的失败模式很直接：任何发往 Firebase AI Logic、却没有有效 App Check 令牌的请求都会被拦，包括从未实现生产 attestation 提供方的已发布版本。因此会出现「开发环境仍可用 debug 令牌，商店包却调用失败」的分裂——正是许多团队描述的现象。

步骤 1 — 确认调用路径是 Firebase AI Logic

改强制日期之前，先确认失败流量确实走 Firebase AI Logic 客户端 SDK／Firebase AI Logic 路径，而不是从不经过该产品 App Check 的后端裸调 Gemini Developer API 或 Agent Platform Gemini API。

可检查：

  • 客户端初始化走 Firebase AI Logic SDK 入口（按平台：移动端、Web、Flutter、Unity 等），而不是完全绕开 App Check 的纯服务端 Gemini 客户端。
  • 项目已启用 Firebase AI Logic，失败面是经该产品访问 Gemini 的应用。
  • 出错时间与 Security > App Check > APIs 中 AI Logic 一行的强制状态相符，而不是无关的 API 密钥、配额或模型名 404。

若调用根本不经 Firebase AI Logic，这份 11 月 2 日 App Check 自动强制说明就应按那条路径自己的文档排查，而不是照这份 App Check 清单做。

站内相关（Gemini API 请求默认存储变更，与 App Check 不同题）：Gemini API 新付费项目默认存储 Generate Content 请求。

步骤 2 — 临时延后只作迁移缓冲

若终端用户仍停留在未接 App Check 的版本，Firebase 允许临时延后自动强制：

  1. 打开 Firebase 控制台。
  2. 进入 Security > App Check > APIs。
  3. 找到 Firebase AI Logic 一行。
  4. 使用行末 Enforces 日期选择器（编辑控件）。
  5. 选择不晚于 2027 年 1 月 21 日的强制日期并保存。

FAQ 写明：2027 年 1 月 21 日是可选最晚日期；过后再也不能为 Firebase AI Logic 延后自动强制。

延后不是长期「关掉验证」教程。延后且未强制期间，官方文档警告：Gemini API 访问仍易受滥用。缓冲用来上线 attestation、迁移用户，然后再打开强制（或等到所选日期生效）。日期选择器不是永久关闭开关。

步骤 3 — 按平台接入生产 attestation

对已发布应用，FAQ 的迁移顺序是：需要则先延后 → 尽快实现生产 attestation 提供方 → 监控请求 → 再强制。该 FAQ 列出的提供方：

平台生产 attestation 提供方（文档所列）
Apple 平台DeviceCheck、App Attest 或 reCAPTCHA Enterprise
AndroidPlay Integrity 或 reCAPTCHA Enterprise
WebreCAPTCHA Enterprise
Flutter支持以上提供方，含 reCAPTCHA Enterprise
Unity支持以上提供方（FAQ 写 reCAPTCHA Enterprise 即将支持）

按出货平台实现对应提供方，遵循该栈当前的 App Check 接入说明，并发布新版本，让用户离开未 attestation 的二进制。FAQ 还提到：接入时启用 limited-use tokens，可为日后的 replay protection（一次性令牌）留口——这是可选增强，不能代替基线强制。

文档未列出的 attestation 厂商不在该 FAQ 平台矩阵内。

步骤 4 — 观察请求与 App Check 指标再谈「可以强制」

attestation 上线后，持续看流量，直到近期请求几乎都来自已验证客户端。FAQ 的决策口径是定性的：当几乎所有近期请求都来自 verified 客户端时，再强制更稳妥。以该项目 Firebase 控制台的 App Check／请求视图为准；单台设备测试不足以下结论。

宜对齐的信号：

  • Firebase AI Logic 上 verified 与 unverified 请求占比。
  • 旧商店包是否仍产生 unverified 量。
  • 已 attestation 版本的分阶段放量是否在替换未 attestation 人群。

数字看起来健康之后，才适合把强制视为对该用户群「可保持开启」。

步骤 5 — 启用或确认强制

若 Firebase AI Logic 的 App Check 尚未强制，在 attestation 覆盖可接受后启用。若 Firebase 已在 11 月 2 日及之后自动强制（且未设延后），在 APIs 页确认 Enforces 状态并继续监控。

FAQ 提醒：若到计划日仍未强制且未配置延后，Firebase 可自动强制。没有延后计划却干等，等于让「已发布但未 attestation」的用户被拦。

保持强制时的本地开发

强制不必为本地开发而关掉。FAQ 写明：Firebase AI Logic 已强制 App Check 时，本地可用 App Check debug provider，同时保持对该产品的强制。这样生产侧保护仍在，开发机可用 debug 令牌——优于仅为跑模拟器就把整个项目停在开放延后上。

清单（短版）

  1. 确认失败调用走 Firebase AI Logic（不是无关 Gemini 路径）。
  2. 若旧版未 attestation 仍在线，仅将 Enforces 临时延至不晚于 2027 年 1 月 21 日作缓冲。
  3. 按 Apple／Android／Web／Flutter／Unity 接入文档所列生产 attestation；发版并迁移用户。
  4. 监控 verified／unverified 指标至覆盖可接受。
  5. 启用或确认 Firebase AI Logic 的 App Check 强制；本地用 debug provider，强制保持开启。
  6. 延后不是永久关闭——关闭强制期间滥用风险仍在。

范围说明

范围仍是 Firebase AI Logic，不是互联网上每一条 Gemini API。延后只作迁移缓冲，过了允许窗口也不能长期关闭 App Check。官方没有公布强制翻转的 UTC 小时；控制台文案若有变动，以 Firebase 发布记录与 Firebase AI Logic App Check FAQ 为准。

在该计划自动强制窗口里，操作问题很简单：客户端路径是不是 Firebase AI Logic，每个出货平台是否用文档所列生产 attestation 提供方出示有效 App Check 令牌，以及 Security > App Check 上的强制状态与指标是否符合预期。