如果你的付费 Gemini API 账户返回 429 RESOURCE_EXHAUSTED 错误，且元数据显示 quotaMetric: "generate_content_free_tier_requests" 和 quotaValue: "0"，那么你面临的是两个截然不同的问题之一。要么是你的 Google Cloud Billing 没有正确关联到托管 API 密钥的项目（五分钟内即可修复），要么是你遇到了一个已知的 Google 平台 Bug——该 Bug 自 2026 年 2 月 10 日左右开始影响图片生成模型。截至 2026 年 2 月，Tier 1 账户应获得 150-300 RPM（每分钟请求数），而免费版仅有 5-15 RPM，且从免费版升级到 Tier 1 在正确配置 Cloud Billing 后立即生效（ai.google.dev/gemini-api/docs/rate-limits，2026 年 2 月）。
要点速览
付费 Gemini API 账户出现"free_tier_requests limit: 0"错误有两个根本原因。最常见的一个约占 60% 的案例，即 Cloud Billing 实际上没有关联到你 API 密钥所在的 GCP 项目。修复只需五分钟：进入 Google Cloud Console，将计费账户关联到你的项目，创建新的 API 密钥，然后验证等级升级。第二个原因影响约 25-40% 的近期案例，是一个真正的 Google 平台 Bug，gemini-2.5-flash-image 和 gemini-3-pro-image-preview 等图片生成模型即使在计费配置正确的情况下仍停留在免费版配额。针对这种情况，解决方案包括使用仍然正常工作的文本模型、迁移到 Vertex AI 端点，或使用第三方 API 代理服务。剩余的案例涉及在启用计费之前创建的 API 密钥，只需在计费激活后重新生成 API 密钥即可解决。
"free_tier_requests limit: 0"到底意味着什么？
当你从 Gemini API 收到 429 RESOURCE_EXHAUSTED 错误时，响应体包含详细的配额信息，能准确告诉你哪里出了问题。需要检查的关键字段是 quotaMetric（标识你的请求被计入哪个配额桶）以及 quotaValue 和 quotaLimit（分别显示你的当前使用量和最大配额）。当你看到 quotaMetric: "generativelanguage.googleapis.com/generate_content_free_tier_requests" 且 quotaValue 和 quotaLimit 都为 "0" 时，这意味着一件令人警觉的事情：API 将你的账户视为零剩余配额的免费版用户，无论你的计费控制台显示什么。
要理解这种情况为何发生，需要了解 Google 配额系统的内部工作原理。Gemini API 在项目级别而非单个 API 密钥级别执行配额限制（ai.google.dev，2026 年 2 月）。这意味着如果你在同一个 Google Cloud 项目下有多个 API 密钥，它们共享同一个配额池。当 Cloud Billing 关联到项目时，Google 的后端应自动将该项目的配额从免费版升级到付费版限制。错误响应中出现的"free_tier_requests"指标是最明确的信号，表明这次升级要么没有发生，要么被平台问题回滚了。
quotaLimit: "0" 和简单的触及速率限制之间有一个重要区别。quotaLimit 为零意味着系统根本没有分配给你任何配额——不是你用完了配额，而是你从未获得过配额。这与正常的速率限制错误不同，正常情况下 quotaLimit 可能显示"5"（Gemini 2.5 Pro 的免费版 RPM）而 quotaValue 显示"5"（全部用完）。零配额场景特指计费或平台配置问题，而非正常的用量耗尽。
要确认你处于哪种情况，请仔细检查完整的错误响应体。以下是遇到零配额问题时典型的错误 JSON 格式：
json{ "error": { "code": 429, "message": "Resource has been exhausted", "status": "RESOURCE_EXHAUSTED", "details": [{ "reason": "RATE_LIMIT_EXCEEDED", "metadata": { "quota_limit": "generate_content_free_tier_requests", "quota_limit_value": "0", "quota_metric": "generativelanguage.googleapis.com/generate_content_free_tier_requests" } }] } }
需要注意的关键细节是指标名称中包含 free_tier_requests——这表明 Google 的后端将你的项目归类到了免费版配额桶中，无论你的实际计费状态如何。如果你处于付费版，指标将引用完全不同的配额桶（通常是不带 free_tier 前缀的 generate_content_requests）。这个区别虽然微妙但对于准确诊断至关重要。
该错误通常表现为两种模式之一。第一种模式中，包括文本生成在内的每个 API 调用都失败，提示计费关联问题。第二种模式中，文本生成模型正常工作且具有付费版限制，但 gemini-2.5-flash-image 和 gemini-3-pro-image-preview 等图片生成模型返回 free_tier_requests 错误。第二种模式是 2026 年 2 月 Google 平台 Bug 的典型特征，已在 Google AI 开发者论坛 上被广泛报告。识别你正在经历哪种模式是解决问题最重要的第一步，因为每种场景的修复方法根本不同，应用错误的修复方法会浪费宝贵的调试时间。
快速诊断——计费问题还是 Google Bug？
在修复问题之前，你需要确定自己面临的是两种场景中的哪一种。诊断过程大约需要六十秒，涉及三项检查，逐步缩小根本原因。做对这一步很重要，因为每种场景的修复方法完全不同——应用错误的修复方法会浪费时间，可能让你更加困惑。
检查 1：验证 Cloud Billing 是否已关联。 导航到 console.cloud.google.com/billing，检查计费账户是否已主动关联到包含你 API 密钥的项目。这与拥有 Google One 或 Gemini Pro 订阅不同——API 计费需要 Cloud Billing 账户明确关联到你的 GCP 项目。如果没有关联计费账户，你就找到了问题所在，可以直接进入下一节的修复 #1。令人惊讶的是，很多开发者以为自己是付费版，因为他们注册了 Google AI Studio，但 AI Studio 的免费访问并不会自动启用付费 API 配额。
检查 2：测试不同模型类型。 如果计费已关联，进行一个简单测试。向 gemini-2.5-flash 等文本模型发送基本文本生成请求，同时向 gemini-2.5-flash-image 等图片生成模型发送请求。如果文本模型正常工作但图片模型返回 free_tier_requests 错误，你几乎可以确定遇到了 2026 年 2 月的 Google Bug。该 Bug 专门影响图片生成端点，同一账户上的文本生成端点不受影响，造成令人沮丧的分裂行为，让开发者误以为计费配置有误。
检查 3：API 密钥创建时间。 如果所有模型都失败（文本和图片都失败），检查你的 API 密钥创建时间与启用计费的时间关系。在 Cloud Billing 激活之前通过 Google AI Studio 创建的 API 密钥可能不会自动继承付费版配额。修复方法很简单：在启用计费后创建新的 API 密钥。这是较不常见的场景，约占 15% 的案例，但会困扰那些在免费版探索期间设置密钥然后稍后添加计费的开发者。
根据这三项检查，你将属于三个类别之一：计费未关联（在下一节修复）、图片模型的 Google Bug（参见解决方案部分）或 API 密钥时间问题（创建新密钥）。每个类别都有特定的解决路径，本指南的其余部分将详细介绍每种方案。
你还可以使用以下 curl 命令来快速测试你的 API 密钥并查看包含配额元数据的原始响应。将 YOUR_API_KEY 替换为你的实际密钥，将 MODEL_NAME 替换为你要测试的模型：
bashcurl -s "https://generativelanguage.googleapis.com/v1beta/models/MODEL_NAME:generateContent?key=YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"contents":[{"parts":[{"text":"Hello"}]}]}' | python3 -m json.tool
如果响应在错误详情中包含配额信息，你将看到你的请求被计入了哪个配额桶。成功的付费版响应将返回生成的内容，不包含任何与配额相关的错误元数据，确认你的项目被正确识别为付费账户。
修复 #1——正确关联 Cloud Billing
此修复方案解决 free_tier_requests 错误最常见的原因：Cloud Billing 没有正确关联到你的 Google Cloud 项目。即使你认为计费设置正确，也值得按照这些步骤验证，因为 Google Cloud Console 有多个计费相关页面，可能造成对实际计费状态的混淆。
步骤 1：打开 Google Cloud Console。 前往 console.cloud.google.com，确保使用与 AI Studio 相同的 Google 账户登录。这看起来显而易见，但使用多个 Google 账户的开发者有时会在错误的账户上配置计费。检查右上角的账户头像确认你在正确的账户上。
步骤 2：导航到 Billing。 点击左上角的汉堡菜单（三条横线），然后在导航面板中找到并点击"Billing"。如果你看到"Link a billing account"或"Set up billing"的提示，那么你已确认计费从未正确关联——这就是你的根本原因。如果你看到现有的计费账户，继续验证它是否关联到正确的项目。
步骤 3：验证项目关联。 在你的计费账户下，点击"Account management"，查看"Projects linked to this billing account"部分。找到包含你 API 密钥的项目。如果你的项目不在此列表中，点击"Link a project"并选择它。这是许多开发者遗漏的关键步骤：拥有计费账户是不够的——它必须明确关联到你的 Gemini API 密钥所在的项目。
步骤 4：处理预付款要求。 Google 可能要求一次性预付款以激活付费 API 访问。这不是费用，而是计入未来使用的额度。如果被提示，完成此预付款步骤。一些开发者报告被要求支付 5 到 50 美元不等，具体取决于地区和账户历史。该预付款会计入你的账户余额，在你使用 API 时消耗（ai.google.dev/billing，2026 年 2 月）。
步骤 5：创建新的 API 密钥(推荐)。 关联计费后，前往 aistudio.google.com 在已启用计费的项目下创建新的 API 密钥。虽然现有密钥应继承付费配额，但创建新密钥可以消除任何缓存或传播延迟。在你的应用中使用这个新密钥并立即测试。
步骤 6：验证升级。 进行测试 API 调用并检查响应头。成功的付费版响应不应包含任何 free_tier_requests 配额指标。或者，检查你的配额页面 console.cloud.google.com/apis/api/generativelanguage.googleapis.com/quotas 查看更新后的限制。你应该看到 RPM 值为 150-300，而不是免费版的 5-15 RPM。一旦计费正确关联，升级到 Tier 1 立即生效——无需等待。
如果完成所有六个步骤后，你的文本生成模型以付费限制正常工作，但图片生成模型仍显示 free_tier_requests 错误，你很可能遇到了下一节描述的 Google 平台 Bug。不要继续重新关联计费或创建新密钥——如果根本问题在 Google 端，这不会有帮助。
还有一个额外的验证步骤有助于确认修复成功：访问 API 配额仪表板 console.cloud.google.com/apis/api/generativelanguage.googleapis.com/quotas，查找"GenerateContent requests per minute per project per base_model"指标。在免费版下，此值显示个位数如 5 或 10。在 Tier 1 下，应显示 150-300 范围内的值。如果你看到 Tier 1 的数字，你的计费关联已确认，特定模型上剩余的 free_tier_requests 错误可归因于 Google 平台 Bug 而非你的账户配置。
修复 #2——当这是 Google 平台 Bug 时
自 2026 年 2 月 10 日左右，越来越多的开发者报告称，他们的付费 Tier 1 账户在图片生成模型上收到 free_tier_requests limit: 0 错误，而同一账户上的文本生成模型以付费版配额完美运行。这已在 Google AI 开发者论坛的多个帖子中得到确认，来自已验证计费配置正确且已尝试所有标准故障排除步骤但未成功的开发者。
该 Bug 似乎影响特定的图片生成模型端点，包括 gemini-2.5-flash-image 和 gemini-3-pro-image-preview（内部名称为"Nano Banana Pro"的模型）。用户报告对这些模型的请求返回熟悉的 429 错误和 free_tier_requests 指标，尽管对 gemini-2.5-pro 或 gemini-2.5-flash 等文本模型的相同请求没有任何配额问题。这种选择性失败模式是该问题属于平台级 Bug 而非用户配置问题的最强有力指标。如果你已经了解了 Gemini 3 Pro 图片生成免费版 限制并确认你应该拥有付费访问权限，那么这个 Bug 很可能就是你的阻碍。
在等待 Google 解决此问题的同时，有几个实用的解决方案可以让你的项目继续推进。第一个也是最简单的方法是对不严格要求图片输出的任务使用文本生成模型。Gemini 2.5 Pro 和 Flash 模型具有强大的多模态能力，可用于图片理解和分析，这些文本端点不受 Bug 影响。如果你的应用特别需要图片生成，可以考虑暂时使用其他图片生成 API，如 OpenAI 的 DALL-E 3 或 Stability AI 的端点，它们可以作为工作流程中图片生成部分的即插即用替代品。
另一个一些开发者成功使用的解决方案是使用 Vertex AI 端点代替 AI Studio 端点。Vertex AI 使用不同的配额执行系统，一些用户报告即使 AI Studio 端点被阻止，图片生成也能通过 Vertex AI 正常工作。代价是 Vertex AI 需要额外的设置，包括服务账户认证和稍有不同的 API 格式，但对于不能等待 Bug 修复的生产应用来说，这可能是一个可行的临时解决方案。
对于需要快速可靠解决方案且不想处理 Vertex AI 迁移复杂性的开发者，第三方 API 代理服务可以立即提供 Gemini 图片生成能力的访问。像 laozhang.ai 这样的服务聚合 API 访问并通过正确配置的账户路由请求，绕过单个项目的配额问题。这在 Google 解决底层平台 Bug 期间作为临时桥梁特别有用。
无论你选择哪种解决方案，强烈建议在 Google AI 开发者论坛 上报告你的经历并为现有的 Bug 报告帖子投票。这些报告的可见度直接影响 Google 修复的优先级。在报告中包含你的项目 ID（不是 API 密钥）、受影响的具体模型和确切的错误响应，以帮助 Google 工程团队更快地诊断和解决问题。有关 Nano Banana Pro 速率限制 结构的详细信息，请参阅我们的专门指南。
同时值得关注 Google 的官方问题追踪器和 AI 开发者论坛的更新。Gemini API 之前的计费相关 Bug 通常在广泛报告后的一到三周内解决，尽管 Google 很少提前通知修复何时部署。设置"gemini api free_tier_requests bug"的 Google 快讯可以帮助你在修复公告发布时及时获知，以便立即从解决方案切换回直接的 Gemini API 端点。
Gemini API 等级和配额如何运作
了解 Google 如何构建其 API 等级系统有助于你预防配额问题并对使用做出明智决策。Gemini API 使用分级系统，更高的等级解锁逐步增大的速率限制，等级之间的升级路径基于累计消费和账户年龄，而非订阅模式。
免费版是每个 Gemini API 新用户的起点，为实验和小型项目提供有限但功能性的访问。截至 2026 年 2 月，免费版允许 Gemini 2.5 Pro 5 RPM、Gemini 2.5 Flash 10 RPM、Gemini 2.5 Flash-Lite 15 RPM（ai.google.dev/gemini-api/docs/rate-limits，2026 年 2 月）。每日请求上限也有强制执行：Pro 每天 100 个请求，Flash 每天 250 个。关键的是，免费版提供零张每分钟图片（0 IPM）用于图片生成——这意味着免费版上的图片生成完全不可用，不仅仅是受限。值得注意的是，Google 在 2025 年 12 月大幅削减了免费版限制，将配额减少了 50-80%，这让许多开发者措手不及。有关这些变化的完整分析，请参阅我们的 Gemini API 免费版指南。
当你在项目上启用 Cloud Billing 时，Tier 1 立即解锁，无需等待期，无最低消费要求。这是许多开发者遗漏的最重要事实之一：你不需要预先支付任何费用即可获得 Tier 1 访问，尽管 Google 可能要求一次性预付款作为使用额度。Tier 1 提供限制的巨大提升：大多数模型 150-300 RPM（比免费版提高 30-60 倍）、无限每日请求以及图片生成端点的访问权限。这是大多数个人开发者和小团队应该瞄准的等级。Gemini API 速率限制指南 更详细地介绍了这些数字。
Tier 2 及以上专为生产工作负载和高流量应用设计。达到 Tier 2 需要 250 美元或以上的累计 API 消费以及在 Tier 1 至少 30 天。一旦满足要求，升级会在约 10 分钟内自动完成，将大多数模型的 RPM 限制推至 1,000 或更高。Tier 3 遵循类似模式，需要 1,000 美元以上的累计消费和在前一等级 30 天以上。
一个关键的架构细节是配额按项目而非按 API 密钥执行（ai.google.dev，2026 年 2 月）。这意味着在同一项目下创建多个 API 密钥不会增加你的配额——所有密钥共享同一个池。如果你需要不同应用的独立配额池，必须创建独立的 Google Cloud 项目，每个都有自己的计费关联。每日配额在太平洋时间午夜重置，因此如果你达到每日限制，围绕此重置时间安排请求可以作为实用的解决方案。
下表总结了对遇到 free_tier_requests 问题的开发者最重要的各等级关键差异：
| 指标 | 免费版 | Tier 1 | Tier 2+ |
|---|---|---|---|
| RPM（Pro 模型） | 5 | 150 | 1,000+ |
| RPM（Flash 模型） | 10-15 | 300 | 2,000+ |
| 每日请求限制 | 100-250 | 无限 | 无限 |
| 图片生成 | 0 IPM | 可用 | 可用 |
| 升级要求 | — | 关联 Cloud Billing | 消费 $250 + 30 天 |
| 升级速度 | — | 即时 | 约 10 分钟 |
来源：ai.google.dev/gemini-api/docs/rate-limits，2026 年 2 月
理解这个表格解释了为什么"free_tier_requests limit: 0"错误如此具有破坏性。在免费版上，你的图片生成配额字面上为零——不是受限，而是完全被阻止。这对免费账户是设计如此的，但当计费系统错误地将你的付费项目分配到免费版桶中时，它实际上删除了所有图片生成访问权限，并严重限制了文本模型的访问。
配额被阻止时的替代方案
当你的 Gemini API 配额卡在零且标准修复未能解决问题时，你需要实用的替代方案来保持项目运行。这里的目标不是永久替代 Gemini，而是拥有可靠的后备选项，在等待配额问题解决期间最大限度地减少停机时间。每种替代方案在成本、能力和集成复杂性方面各有优势。
图片生成最直接的替代方案是通过其原生 API 使用不同的模型提供商。OpenAI 的 DALL-E 3 提供高质量的图片生成和完善的 API 文档，Stability AI 的 SDXL 端点以更低的每张图片成本提供有竞争力的质量。这两种服务都有独立于 Google 的计费系统，因此不受 Gemini 配额问题的影响。代价是你需要调整提示工程和 API 集成代码以匹配不同提供商的格式，尽管对于基本的图片生成任务，更改通常是最小的。
对于想要保持与 Google Gemini API 格式兼容同时避免项目级配额问题的开发者，第三方 API 聚合服务提供了一个有趣的中间方案。像 laozhang.ai 这样的平台提供与 OpenAI API 格式兼容的统一 API 端点，并通过正确配置的基础设施提供对 Gemini 模型的访问。这些服务在他们那端处理计费和配额管理，这意味着你可以获得可靠的访问而无需担心 Google 的等级系统或当前的平台 Bug。通过聚合器的每次请求成本通常与官方定价持平或更低，特别是对于图片生成模型，laozhang.ai 收费约每张图片 0.05 美元。
如果你的应用严重依赖 Gemini 的特定能力且你需要留在 Google 的生态系统内，迁移到 Vertex AI 端点值得考虑作为更持久的解决方案。Vertex AI 使用企业级配额管理，与 AI Studio 配额系统分开，并提供微调、模型监控和企业安全控制等附加功能。设置更复杂——你需要配置服务账户、启用 Vertex AI API 并修改请求格式——但对于生产应用来说，可靠性的改善可能值得这些努力。
预防——如何从一开始就正确设置计费
预防比故障排除有效得多，从一开始就正确设置 Gemini API 计费可以完全消除 free_tier_requests 错误最常见的原因。以下最佳实践基于数百个论坛报告中观察到的模式和官方 Google 文档。
在创建 API 密钥之前设置计费。 最有效的预防措施是在创建任何 API 密钥之前在你的 Google Cloud 项目上启用 Cloud Billing。这确保在该项目下生成的每个密钥从创建时起就自动关联付费版配额。在免费版期间创建密钥然后稍后添加计费的开发者有时会遇到旧密钥不继承付费配额的时间问题。虽然根据 Google 的文档这不应该发生，但论坛报告表明偶尔会出现，在计费后创建密钥可以完全避免这个问题。
使用专用 GCP 项目进行 API 访问。 创建一个专门用于 Gemini API 使用的独立 Google Cloud 项目，而不是使用默认或共享项目。这给你干净的配额隔离，使计费跟踪更容易，并在出现配额问题时简化故障排除。描述性地命名项目（例如"gemini-api-production"），以便你可以在 Cloud Console 中轻松识别它。由于配额按项目执行，这也意味着如果你需要不同应用的独立配额池，可以创建多个项目。
计费激活后验证你的等级。 关联计费后，不要仅仅假设升级已经发生。运行测试 API 调用并检查响应中是否有任何 free_tier_requests 指标。更好的做法是检查 Cloud Console 中的 API 配额页面，确认你的限制已升级到 Tier 1 值（150-300 RPM）。如果五分钟后升级仍未传播，尝试创建新的 API 密钥——这有时会触发配额刷新。
主动监控你的配额使用。 在 Google Cloud Console 中设置配额监控，以便在达到限制之前而非之后收到警报。导航到 APIs & Services，然后 Quotas，并在配额限制的 80% 和 95% 处配置警报阈值。这给你提供接近限制的早期预警，并帮助区分合法的高使用量和意外的配额限制。主动监控还在你需要向 Google 报告配额 Bug 时提供证据——你可以证明你的使用模式与被应用的免费版限制不匹配。
保留计费和 API 密钥文档。 维护一份简单的记录，说明哪个计费账户关联到哪个项目、计费何时启用以及每个 API 密钥何时创建。这份文档在排除配额问题时非常宝贵，并加快与 Google 的任何支持互动。在你的笔记中包含项目 ID（在 Cloud Console 设置中找到）和密钥创建日期。
实现带指数退避的重试逻辑。 即使在付费等级上，在使用高峰期或短暂的服务中断期间也可能出现暂时性 429 错误。从一开始就在 API 客户端代码中构建重试逻辑可确保你的应用优雅地处理这些情况，无需手动干预。标准的指数退避策略——从一秒开始，每次重试翻倍，最大 32 秒，加上随机抖动——涵盖配额相关和服务器负载相关的 429 响应。大多数流行的 API 客户端库包含内置的重试支持；例如，Python 的 google-generativeai 库在配置适当设置时会自动处理重试。
设置计费警报以及早发现问题。 在 Google Cloud Console 的 Billing > Budgets & alerts 下配置预算警报。在预期月度支出的 50%、80% 和 100% 处设置警报阈值。这些警报有双重用途：它们通知你使用量是否意外激增（指示可能的密钥泄露或失控进程），并确认计费正在积极跟踪你的使用——如果你在付费等级但从未收到计费警报，这可能表明计费关联存在问题。此外，如果你的应用正在运行但支出意外降至零，这可能信号表明你的项目已被恢复到免费版。
常见问题
在启用计费后创建新 API 密钥能否修复配额问题？
在许多情况下可以。如果你的原始 API 密钥是在 Cloud Billing 关联到项目之前创建的，在计费激活后创建新密钥通常可以解决 free_tier_requests 错误。新密钥是在启用计费的项目上下文中生成的，应自动获得 Tier 1 配额限制。但是，如果你遇到的是 2026 年 2 月的 Google Bug 专门影响图片生成模型，新密钥将无法帮助，因为问题在平台层面而非密钥层面。
为什么文本模型正常但图片模型返回 free_tier_requests 错误？
这是 2026 年 2 月 Google 平台 Bug 的典型症状。该 Bug 似乎专门影响图片生成模型端点（如 gemini-2.5-flash-image 和 gemini-3-pro-image-preview）的配额分配，同时文本生成模型配额配置正确。Google 已在其开发者论坛上承认此问题，但尚未提供修复时间表。在此期间，请使用本指南中描述的解决方案，包括 Vertex AI 迁移和第三方 API 代理。
Tier 1 升级需要多长时间传播？
一旦 Cloud Billing 正确关联到你的项目，从免费版到 Tier 1 的升级应该是即时的（ai.google.dev，2026 年 2 月）。如果五分钟内升级未反映，尝试在启用计费的项目下创建新的 API 密钥。对于 Tier 1 到 Tier 2 的升级，需要 250 美元或以上的累计消费和在 Tier 1 至少 30 天，一旦满足要求，传播通常需要约 10 分钟。
多个 API 密钥是否共享相同的配额？
是的。Gemini API 中的配额执行是按项目而非按密钥的（ai.google.dev，2026 年 2 月）。在同一个 Google Cloud 项目下创建的所有 API 密钥共享同一个配额池。创建额外的密钥不会增加你的可用配额。如果你需要独立的配额池，必须创建独立的 Google Cloud 项目，每个都有自己的计费账户关联。这是开发者常见的困惑来源，他们以为生成新的 API 密钥会获得新的配额分配。事实并非如此——密钥只是凭证，而配额附加在底层项目资源上。
429 错误是否可能意味着服务器过载而非用户配额耗尽？
是的，429 状态码有时可能表示 Google 的服务器负载过重，与你的个人配额无关。在这种情况下，错误是暂时性的，短暂延迟后重试（使用指数退避）通常会成功。你可以通过检查错误详情来区分配额耗尽和服务器过载：配额耗尽将包含带有特定配额信息的 quotaMetric 字段，而服务器过载通常使用不同的错误结构。如果你看到几秒内自行解决的间歇性 429 错误，服务器过载是更可能的原因。在 API 客户端代码中实现带抖动的指数退避被视为最佳实践，无论错误类型如何，因为它优雅地处理两种场景而无需手动干预。