加载失败
这篇帖子讲的是一个 Firebase（Google 的后端/前端集成平台）浏览器端 API key 被拿去访问 Gemini API（Google 的生成式 AI 接口）后，13 小时内刷出约 €54k 的账单。争议点在于：Google 过去长期把 Firebase/Maps 这类场景中的 API key 视为“public by design”的客户端标识，而 Gemini 现在又把同类 key 变成了可计费、可滥用的入口。原帖提到的预算告警和 cost anomaly alert 都是小时级延迟，说明 Google Cloud 的计费聚合并不是实时的，所以靠邮件提醒无法在暴涨前止损。评论里还延伸到 Gemini 的 spend cap、prepay、Pub/Sub 自动停机、Firebase AI Logic（通过 proxy 让 key 不暴露给客户端）等方案，讨论的核心是云计费安全和默认保护是否应该由平台负责。
很多人拿自己的 GCP 经验说明，预算告警和 cost anomaly alert 往往要过数小时才到，等邮件落地时账单已经从几十欧滚到数万欧。有人提到设了 100 美元预算，却在超支 5 小时后才收到通知；也有人说夜间任务跑飞后，只能靠一次性退款止损。评论把这种机制比作“火警晚半小时才响”，并指出即使接了 Pub/Sub 自动停用账单，也常常因为计费链路延迟而来不及拦住损失。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10]
一派认为真正的 hard cap 并不神秘：可以按请求实时估价，接近上限时直接切断服务，哪怕允许一点 slippage 也不该出现 100 倍级别的超支。另一派则强调计费是 event-driven 的，聚合延迟、跨服务对账和同步扣费会让“精确拦截”变得很难。讨论里还扩展到 prepay、按小时或按月 quota、超额后停服等方案，核心诉求是让用户能明确控制风险，而不是只有告警没有刹车。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11]
评论反复指出，Google 过去长期把 Firebase、Maps 这类前端场景里的 API key 当作“public by design”的识别符，而不是秘密。问题在于 Gemini / Gemini Developer API 现在可能接受同一类 key，导致原本只用于公开前端的 key 突然变成可计费、可滥用的入口。虽然 Google 文档后来改成要求 Gemini 使用单独 key，并声称会阻断已泄露的 key，但这仍然让很多旧集成处在危险状态。也有人补充说，GitHub 上搜到的大量 key 其实已被自动报漏并失效，真正危险的是旧规则和新权限之间的错配。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13]
不少人强调，至少应当做 referrer 限制、按 API 限制、rate limiting，以及把调用放到后端 proxy，而不是让浏览器直接打有计费的私有接口。还有人建议给 API key 增加月度和每小时额度，或把告警和自动停机结合成真正的保护网。反对者则指出，浏览器端请求本来就会暴露 key，IP 和 Origin 也不是可靠边界；所以问题不只是开发者没做好，而是这种 key 设计本身就很容易被误用。评论里还提到 Firebase AI Logic 之类方案，本意就是把 Gemini key 藏在 proxy 后面。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11]
很多人把这类问题看成大厂的商业选择，而不是纯技术限制：默认不开 hard cap、告警延迟、文档深埋，都会把风险转嫁给用户，同时保留超支收入。有人直接称之为 anti-feature 或 trap for the user，并引用“少让用户花钱就像在害公司”的老观点，认为内部激励根本不会优先修这类功能。也有人觉得 Google、AWS、Microsoft 并不是做不到，而是不愿意为了少数小客户去承担可能减少的收入和支持成本。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13]
很多评论强调，几十千欧元不是“小失误”，而是可能直接压垮一个项目或小公司。有人说自己也差点被 runaway job 搞崩，另一些人则提到靠 GCP support 才拿回一次性退款，但并不确定第二次还会不会有同样待遇。相较之下，像 Backblaze B2 这种能在额度到达后直接停掉请求的服务，被拿来当作“至少能限制损失”的对照。整体情绪是：对大厂来说也许只是流水，对小团队却可能是灾难。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
spend cap: 支出上限；达到后应停止计费或停用服务的硬限制。
budget alert: 预算告警；只负责通知超支风险，不会自动拦截消费。
Pub/Sub: Google Cloud 的发布/订阅消息系统，常被用来把告警接到自动化停机流程。
prepay: 预充值/预付费模式，先充钱再用，余额耗尽后服务停止。
rate limiting: 速率限制；限制单位时间内请求次数，防止单个 key 或用户快速耗尽额度。
API key restrictions: API key 限制；把 key 绑定到特定 API、来源域名或应用，减少被滥用的范围。