接生图 API出问题时最浪费时间的是方向找错——明明是密钥没生效却在那儿调超时。 这篇给一份该服务的错误对照表和排查顺序。一、先按 HTTP 状态码分流状态码大概率原因该不该重试401 / 403密钥错、没带Bearer、密钥被禁用❌ 改配置400请求体格式错、model写错、messages结构不对❌ 改代码402 / 余额提示积分不足❌ 充值429触发限流并发开太高✅ 退避后重试5xx服务端临时问题✅ 退避后重试无响应 / 超时客户端超时给太短或网络问题✅ 重试只对 429 和 5xx 重试。4xx 重试多少次结果都一样只是白白拖慢整批。二、最常踩的五个1.Bearer后面漏了空格// ✗ 少了空格服务端解析不出密钥返回 401 headers: { Authorization: Bearer${key} } // ✓ headers: { Authorization: Bearer ${key} }2.model名字写错nano-banana-pro和nano banana pro是不同写法按文档给的模型代码填别自己改连字符。 写错会返回 400 而不是模型不存在容易看不出来。3. 超时用了默认值Node 的fetch不设signal就是不超时请求会一直挂着 Python 的requests不传timeout同理。生图给 120 秒生视频给 300 秒。signal: AbortSignal.timeout(120_000)4. 密钥写死在前端浏览器里发请求密钥在 Network 面板一览无余。必须走后端代理。5. 网关超时比接口超时短本地 curl 好好的一上服务器就 504——十有八九是 Nginx 的proxy_read_timeout还是默认 60 秒。生图要放到 300 秒。三、排查顺序从便宜到贵1. curl 直接打一次 → 排除代码问题10 秒搞定 2. 看状态码 → 按上面的表分流别乱猜 3. 打印完整响应体 → 服务端通常会给出具体原因别只看 status 4. 换个模型试 → 能区分服务问题还是这个模型的问题 5. 降并发到 1 再试 → 能区分限流还是别的第 3 步最容易被跳过。很多人只if (!r.ok) throw new Error(失败) 把服务端给的具体原因扔了然后对着失败两个字排查半天。if (!r.ok) { const body await r.text(); // 别扔掉 throw new Error(HTTP ${r.status}: ${body.slice(0, 200)}); }四、跑批时的错误统计批量任务跑完一定要统计错误分布不然出了问题只知道有些失败了const stats {}; // ...每次失败时 stats[key] (stats[key] || 0) 1 console.table(stats); // { HTTP 429: 12, timeout: 3, HTTP 500: 1 }429 占大头 → 降并发timeout 占大头 → 加超时或降并发5xx 占大头 → 加重试。分布决定该调哪个参数凭感觉调容易越调越糟。五、模型与消耗模型代码定位消耗nano-banana2跑量、试参数8 积分/次nano-banana-pro终稿1K/2K/4K10 积分/次gpt-image-2细节质感按次计费Veo 3.1 视频生成/Sora 2生视频120 / 130 积分/次六、小结排查四条按状态码分流别乱猜、只对 429/5xx 重试、把响应体打出来、跑批统计错误分布再调参数。该服务兼容 OpenAI 协议错误语义也一致 现成的排查经验直接能用。模型全、价格便宜、并发高、出图快、稳定。接口服务甜甜圈APIdashengfenshen.cn