Gemini API 错误码速查手册从 503 到 429逐个击破【免费下载链接】cookbookExamples and guides for using the Gemini API项目地址: https://gitcode.com/GitHub_Trending/coo/cookbook调 Gemini API 调着调着突然蹦出个 503或者点发送就甩你一脸 429别慌先别急着改代码先查一下错误码确认它是不是能重试的那一类。Gemini cookbook 项目的错误处理部分把这件事做得很实在先分类再决定走自动重试还是手动退避。 先分清哪些错能重试Gemini API 错误码速查日志里突然蹦出个 503第一反应是重试不先看数字。常见错误码大致分两大类处理方式完全不同可以重试的——瞬态错误408 Request Timeout请求超时了重试一下通常就好429 Resource Exhausted你手太快服务器让你歇会儿Gemini 429 限流是最常见的500 / 502 / 503 / 504服务端忙、重启或网关抖了503 Service Unavailable最典型的瞬态错误不能重试的——你自己的问题400 Bad Request请求本身有问题重试一百次也没用401 / 403API key 没配好或没权限重试只是重复翻车404模型名或端点不存在先检查拼写判断口诀服务端状态不对就重试你的请求不对就改代码。仓库里完整的错误处理示例在错误处理示例 Notebook。⚡ 自动重试开启方法改一处参数就搞定分清错误之后最省事的修法是让客户端库自己重试。创建genai.Client时把HttpRetryOptions通过http_options带进去就行不用自己写任何重试逻辑retry_options types.HttpRetryOptions(attempts5, initial_delay2.0, max_delay30.0, http_status_codes[408, 429, 500, 502, 503, 504]) client genai.Client(api_keyGEMINI_API_KEY, http_optionstypes.HttpOptions(retry_optionsretry_options))四个旋钮attempts总共试几次、initial_delay首次重试等多久、max_delay最长等多久、http_status_codes哪些码触发重试。有的 SDK 版本是调用时传request_options这个仓库的示例则在建 client 时一次配好思路都一样这一步 90% 的情况就够了。能覆盖上面状态码列表里的瞬态错误后台自动重试用户基本无感不能覆盖400/401 这类 4xx 照样直接抛出来——这是好事重试也没用略不足没法按错误类型定制处理也看不到我重试过了的痕迹观察性得靠日志补️ 手动重试策略配置用 retry 库搭精细退避想精确控制怎么等、何时放弃或者给同一个函数包一层自动重试就用retry库自己配。你只需要关心三件事哪些错重试写一个predicate只放 code 在{408, 429, 500, 502, 503, 504}里的errors.APIError过怎么等指数退避——initial2.0从 2 秒起步multiplier2.0每次翻倍maximum64.0封顶 64 秒何时放弃timeout600是总预算超了直接抛不让它无限挂下去retry.Retry(predicateif_genai_transient_error, initial2.0, maximum64.0, multiplier2.0, timeout600) def generate_with_retry(prompt): return client.interactions.create(modelMODEL_ID, inputprompt)这样一包装429 就从打断用户的异常变成了等几秒再试的内部事件。想要更手动的 API 重试策略细节翻错误处理示例 Notebook即可。 503 错误自测流程三步确认重试真的生效我觉得它生效了是最不靠谱的事。故意触发一次 503看它会不会乖乖重试故意失败一次在函数里第一次调用时故意抛errors.ServerError503 Service Unavailable后续调用走真实 API看输出正确行为是先打印Error: 503 ...然后重试并成功如果一次成功却没有任何重试痕迹说明predicate没接住这个异常反向验证把异常换成 400确认它不重试——只重试该重试的才是对的这个自测套路示例 notebook 里现成就有照着把 cell 抄下来跑就行。错误处理容易踩的坑三处超时不是越大越好。遇到ReadTimeout或DeadlineExceeded把timeout默认 600 秒调大是合理的但设得过高会拖慢错误检测、占着连接不放该失败得快就让它快失败。日志别省。每次重试都记下错误码 时间戳 请求上下文模型名、重试次数。没有错误码两周后你只能对着日志猜。配额不够别硬刚。429 成片出现时不是网络问题是配额真用完了重试越多被限得越狠。正确姿势是走官方配额申请流程提额其他场景的入门示例可以看Gemini API 快速上手目录。错误处理的目标不是消灭错误——503 和 429 总会有。而是让它们发生时用户无感先分类、先自动重试、不够再手动退避上线前自测一遍。做到这些红色的报错也就不那么吓人了 【免费下载链接】cookbookExamples and guides for using the Gemini API项目地址: https://gitcode.com/GitHub_Trending/coo/cookbook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/9 18:21:44 · 阅读 1.2k Gemini API 错误码速查手册：从 503 到 429，逐个击破
Gemini API 错误码速查手册从 503 到 429逐个击破【免费下载链接】cookbookExamples and guides for using the Gemini API项目地址: https://gitcode.com/GitHub_Trending/coo/cookbook调 Gemini API 调着调着突然蹦出个 503或者点发送就甩你一脸 429别慌先别急着改代码先查一下错误码确认它是不是能重试的那一类。Gemini cookbook 项目的错误处理部分把这件事做得很实在先分类再决定走自动重试还是手动退避。 先分清哪些错能重试Gemini API 错误码速查日志里突然蹦出个 503第一反应是重试不先看数字。常见错误码大致分两大类处理方式完全不同可以重试的——瞬态错误408 Request Timeout请求超时了重试一下通常就好429 Resource Exhausted你手太快服务器让你歇会儿Gemini 429 限流是最常见的500 / 502 / 503 / 504服务端忙、重启或网关抖了503 Service Unavailable最典型的瞬态错误不能重试的——你自己的问题400 Bad Request请求本身有问题重试一百次也没用401 / 403API key 没配好或没权限重试只是重复翻车404模型名或端点不存在先检查拼写判断口诀服务端状态不对就重试你的请求不对就改代码。仓库里完整的错误处理示例在错误处理示例 Notebook。⚡ 自动重试开启方法改一处参数就搞定分清错误之后最省事的修法是让客户端库自己重试。创建genai.Client时把HttpRetryOptions通过http_options带进去就行不用自己写任何重试逻辑retry_options types.HttpRetryOptions(attempts5, initial_delay2.0, max_delay30.0, http_status_codes[408, 429, 500, 502, 503, 504]) client genai.Client(api_keyGEMINI_API_KEY, http_optionstypes.HttpOptions(retry_optionsretry_options))四个旋钮attempts总共试几次、initial_delay首次重试等多久、max_delay最长等多久、http_status_codes哪些码触发重试。有的 SDK 版本是调用时传request_options这个仓库的示例则在建 client 时一次配好思路都一样这一步 90% 的情况就够了。能覆盖上面状态码列表里的瞬态错误后台自动重试用户基本无感不能覆盖400/401 这类 4xx 照样直接抛出来——这是好事重试也没用略不足没法按错误类型定制处理也看不到我重试过了的痕迹观察性得靠日志补️ 手动重试策略配置用 retry 库搭精细退避想精确控制怎么等、何时放弃或者给同一个函数包一层自动重试就用retry库自己配。你只需要关心三件事哪些错重试写一个predicate只放 code 在{408, 429, 500, 502, 503, 504}里的errors.APIError过怎么等指数退避——initial2.0从 2 秒起步multiplier2.0每次翻倍maximum64.0封顶 64 秒何时放弃timeout600是总预算超了直接抛不让它无限挂下去retry.Retry(predicateif_genai_transient_error, initial2.0, maximum64.0, multiplier2.0, timeout600) def generate_with_retry(prompt): return client.interactions.create(modelMODEL_ID, inputprompt)这样一包装429 就从打断用户的异常变成了等几秒再试的内部事件。想要更手动的 API 重试策略细节翻错误处理示例 Notebook即可。 503 错误自测流程三步确认重试真的生效我觉得它生效了是最不靠谱的事。故意触发一次 503看它会不会乖乖重试故意失败一次在函数里第一次调用时故意抛errors.ServerError503 Service Unavailable后续调用走真实 API看输出正确行为是先打印Error: 503 ...然后重试并成功如果一次成功却没有任何重试痕迹说明predicate没接住这个异常反向验证把异常换成 400确认它不重试——只重试该重试的才是对的这个自测套路示例 notebook 里现成就有照着把 cell 抄下来跑就行。错误处理容易踩的坑三处超时不是越大越好。遇到ReadTimeout或DeadlineExceeded把timeout默认 600 秒调大是合理的但设得过高会拖慢错误检测、占着连接不放该失败得快就让它快失败。日志别省。每次重试都记下错误码 时间戳 请求上下文模型名、重试次数。没有错误码两周后你只能对着日志猜。配额不够别硬刚。429 成片出现时不是网络问题是配额真用完了重试越多被限得越狠。正确姿势是走官方配额申请流程提额其他场景的入门示例可以看Gemini API 快速上手目录。错误处理的目标不是消灭错误——503 和 429 总会有。而是让它们发生时用户无感先分类、先自动重试、不够再手动退避上线前自测一遍。做到这些红色的报错也就不那么吓人了 【免费下载链接】cookbookExamples and guides for using the Gemini API项目地址: https://gitcode.com/GitHub_Trending/coo/cookbook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考