为什么绝不应在客户端代码中嵌入 Gemini API 密钥（以及 Firebase AI Logic 如何解决这一问题）
内容提要
直接在浏览器调用 Gemini API 会暴露密钥，导致配额被盗刷、账单飙升。Firebase AI Logic 通过代理架构在服务端注入密钥，客户端不再接触密钥；Firebase App Check 验证请求来自真实应用，防止脚本滥用。文章分步讲解项目配置、App Check 集成（含本地调试令牌）、流式输出、多轮对话、结构化 JSON 输出及错误重试，并提醒 2026 年起 App Check 将强制启用。
延伸解读
代理架构与App Check：互补而非替代
文章强调，Firebase AI Logic的代理架构只解决密钥隐藏问题，但无法阻止他人复制公开的Firebase配置并直接调用代理。App Check通过验证请求来自真实应用实例来堵住这一漏洞。两者结合才能同时防范密钥泄露和脚本滥用。读者需理解：代理是“藏钥匙”，App Check是“验身份”，缺一不可。
成本结构差异：为何AI接口更需防护
文章指出，传统CRUD后端被滥用可能只消耗计算资源，而Gemini调用按token计费，脚本化滥用可在数小时内烧掉月度预算。这种成本形态放大了未授权访问的风险。因此，App Check对生成式AI场景的价值高于普通后端，开发者应优先配置，而非等到账单异常再补救。
本地开发与生产环境的App Check配置
reCAPTCHA Enterprise在localhost上不可靠，文章建议使用调试令牌：在本地环境设置FIREBASE_APPCHECK_DEBUG_TOKEN为true，将控制台打印的令牌添加到Firebase控制台。但必须通过环境判断（如location.hostname）限制该逻辑，绝不能发布到生产。这能避免本地开发被误拒，同时不削弱线上安全。
模型生命周期与弹性设计
文章提醒Gemini模型名称和可用性变化频繁，例如gemini-2.0-flash已于2026年6月1日退役。硬编码模型名可能导致突然的404错误。建议通过Firebase Remote Config动态加载模型名，以便无需发版即可切换。同时，对429/503等瞬时错误实施指数退避重试，提升应用韧性。
Q&A
为什么不能在前端代码里直接嵌入 Gemini API 密钥？
因为打包后的 JavaScript 中密钥会以明文出现，任何人都能通过查看网络请求或运行简单命令提取密钥。一旦泄露，攻击者可以耗尽你的使用配额、导致账单飙升，甚至用你的资源发起请求，使项目因滥用被暂停。
Firebase AI Logic 的代理架构是如何保护 Gemini API 密钥的？
客户端 SDK 将请求发送到 Firebase AI Logic 代理网关，代理在服务端注入 Gemini API 密钥并转发给 Gemini API。密钥始终存储在 Google 基础设施中，不会出现在 JS 包、网络请求或浏览器可检查的任何地方。
Firebase App Check 和 Firebase Authentication 有什么区别？
App Check 是证明（attestation），不是身份验证（authentication）。Authentication 回答“用户是谁”，而 App Check 回答“请求是否来自真实、未被篡改的应用实例，而不是脚本、机器人或他人应用”。两者应一起使用，但 App Check 能在没有用户上下文时防止滥用。
在本地开发时如何配置 App Check 调试令牌？
在本地开发环境中，设置 self.FIREBASE_APPCHECK_DEBUG_TOKEN = true，首次运行会在控制台打印一个调试令牌。将该令牌复制到 Firebase 控制台的 App Check → 应用 → 管理调试令牌中，之后本地请求即被视为已验证。切勿将此调试代码发布到生产环境。
如何让 Gemini 返回结构化的 JSON 输出？
在 getGenerativeModel 时传入 generationConfig，设置 responseMimeType: "application/json" 并提供 responseSchema（使用 Schema.object 等定义字段类型）。这样模型会返回符合 schema 的 JSON，可直接用 JSON.parse 解析。
App Check 强制启用对 Firebase AI Logic 有什么影响？
Google 宣布从 2026 年 11 月 2 日起，Firebase AI Logic 将强制启用 App Check。2026 年 7 月起，新集成的引导设置会自动启用 App Check。强制日期后，任何未验证的请求都会被直接拒绝，因此建议尽早配置。
