作者注：调用生图接口时，响应里没有图片不等于请求失败，更不等于没扣费。本文给出先看响应、再决定是否重试的 4 步判断法，以及可以直接套用的 Python 代码。
调图像接口时，你可能遇到过这种情况：请求发出去了，接口也返回了，但结果里就是找不到图片。很多人的第一反应是网络抖了一下，于是立刻再调一次，甚至写个循环连打几次。本文介绍 先看响应、再决定是否重试 的处理顺序，帮助你掌握生图没返回图片时的正确排查方式。
这不是一篇泛泛而谈的重试指南。按次计费的生图模型，每一次请求都可能产生一次费用。以 2026-11-12 上线 API易 的 gpt-image-2.6-all 为例，它按次计费 $0.025，空响应如果不加判断直接重试，就会再付一次。
核心价值：读完本文，你会知道生图没返回图片时应该先查哪几个地方，什么情况可以重试、什么情况绝对不能重试，以及怎样把这套判断写进代码，避免同一张图被扣两次费。
生图没返回图片时的核心要点
先把结论放在前面。生图没返回图片时，不能把它简单归类为网络问题，而是要按固定顺序检查响应内容。下面这张表概括了整套判断法的 4 个步骤。
| 步骤 | 检查内容 | 结果为否时的处理 | 价值 |
|---|---|---|---|
| 第 1 步 | HTTP 请求是否成功 | 按状态码处理，不进入后续判断 | 区分请求层失败与内容层问题 |
| 第 2 步 | 响应里有没有图片数据或图片 URL | 进入第 3 步 | 有图就结束，杜绝误重试 |
| 第 3 步 | 响应里有没有错误信息 | 有错误就按错误处理 | 避免对必然失败的请求反复付费 |
| 第 4 步 | 确认无图且无错误 | 只重试一次 | 把额外成本控制在可预期范围 |
为什么生图没返回图片不能立刻重试
生图请求和普通的文本对话不同，单次成本更高，而且结果往往不是“全有或全无”。一次请求可能已经在服务端完成了生成，只是你的代码没有从正确的字段里取到图片；也可能是请求本身被拒绝了，响应里明明写着原因。这两种情况下立刻重试，前者会让你为同一张图付两次钱，后者会让你为一个注定失败的请求反复付钱。
以 gpt-image-2.6-all 的按次价 $0.025 来算，每多一次盲重试就多付 $0.025。如果把空响应当作网络抖动写成循环连打，重试 3 次就多出 $0.075，而这些钱可能一分都没换来有效图片。所以生图没返回图片时，先看响应再重试，本质上是在花钱之前先做一次几乎零成本的检查。
先看响应再重试的判断逻辑
判断顺序的设计原则是“由外到内”。HTTP 状态码是最外层的信号，它告诉你请求有没有被正常处理；图片数据是你真正要的东西，所以紧接着检查；错误信息是服务端主动给出的失败原因，必须优先于重试；只有前三层都排查过，确认确实没有图片、也没有任何错误说明，重试才有意义。
这里有一个常被忽略的细节：第 2 步要检查的是“图片数据或图片 URL”。不同接口形态返回图片的位置不一样，有的放在 data 数组里的 b64_json 或 url 字段，有的会把图片链接写在对话消息的 content 文本中。如果你的解析代码只认其中一种，就会把明明有图的响应误判为空响应，这是触发误重试最常见的原因之一。
生图没返回图片的响应类型拆解
要做好先看响应再重试，首先得认清响应可能长什么样。下面这张表把常见的几类响应列出来，并给出对应的处理方式。
| 响应类型 | 典型特征 | 是否已产生图片 | 推荐处理 |
|---|---|---|---|
| 请求层失败 | HTTP 状态码非 2xx | 否 | 按状态码处理，鉴权、参数类问题修正后再发 |
| 正常出图（结构化） | data 中有 b64_json 或 url |
是 | 直接取图，不要重试 |
| 正常出图（文本内嵌） | 消息 content 中包含图片链接 |
是 | 用正则提取链接，不要重试 |
| 带错误信息的成功响应 | HTTP 成功但响应体含 error 或拒绝说明 |
否 | 读错误原因，修改提示词或参数 |
| 真正的空响应 | HTTP 成功、无图、无错误 | 否 | 记录原始响应后重试一次 |
| 请求超时 | 客户端未收到响应 | 无法确认 | 不要自动重打，先核对日志与账单 |
请求超时为什么也要先看再重试
超时是最容易被当成“网络抖动”的情况，但它恰恰最需要谨慎。客户端超时只说明你没等到响应，并不能说明服务端没有完成生成。生图本身耗时较长，如果客户端设置的超时时间偏短，很可能服务端已经生成完图片并完成计费，而你的程序在此之前就放弃了等待。
对这类情况，合理的做法是先适当放宽超时时间，再在超时发生时记录请求时间和参数，去控制台的调用日志里核对这次请求的实际状态。确认没有成功记录后再手动补发，比让程序自动连打要稳妥得多。
带错误信息的响应要按错误处理
有些响应的 HTTP 状态是成功的，但响应体里带有错误对象，或者模型在文本里说明了无法生成的原因，例如提示词触发了内容审核。这类响应虽然没有图片，但原因已经写得很清楚，原样重试几乎必然得到相同结果。
正确的做法是读取错误信息，判断是参数问题、内容问题还是服务端临时问题。参数和内容问题需要修改请求后再发；只有错误信息明确指向临时性故障时，才考虑在间隔一段时间后重试。
生图没返回图片时先看响应再重试：快速上手
下面用 Python 演示如何把这套判断写进代码。示例使用 OpenAI 兼容接口，模型以 gpt-image-2.6-all 为例。具体的调用端点和返回格式请以 API易 文档中该模型的说明为准。
极简示例：拿到响应先检查有没有图
最简单的做法，是在拿到响应后先判断图片字段，有图就结束，没图才进入后续排查：
from openai import OpenAI
client = OpenAI（
api_key="YOUR_API_KEY"，
base_url="https://api.apiyi.com/v1", # API易 OpenAI 兼容接口
）
resp = client.images.generate（
model="gpt-image-2.6-all"，
prompt="一只坐在窗台上的橘猫，水彩风格"，
）
item = resp.data[0] if resp.data else None
if item and （item.b64_json or item.url）:
print（"已拿到图片，不要重试"）
else:
print（"响应里没有图片，先打印原始响应再决定"）
print（resp.model_dump（））
这段代码只有十几行，但已经避免了最常见的错误：不看内容就重打。HTTP 层的失败会由 SDK 抛出异常，你可以在外层用 try 捕获并按状态码处理，而不是直接进入重试循环。
完整示例：4 步判断加最多一次重试
在生产环境里，建议用下面这个更完整的版本。它覆盖了 HTTP 状态检查、两种图片返回位置的解析、错误信息识别、超时不自动重打，以及“确认无图后最多重试一次”的限制：
import re
import requests
API_KEY = "YOUR_API_KEY"
BASE_URL = "https://api.apiyi.com/v1" # API易 统一接口地址
MODEL = "gpt-image-2.6-all"
IMG_URL_RE = re.compile（r"https？://\S+？\.（？:png|jpe？g|webp）"， re.I）
def find_images（body）:
"""同时检查结构化 data 字段与对话 content 中的图片链接"""
images = []
for item in body.get（"data"） or []:
if item.get（"url"）:
images.append（item["url"]）
elif item.get（"b64_json"）:
images.append（"base64-image"）
for choice in body.get（"choices"） or []:
content = （choice.get（"message"） or {}）.get（"content"） or ""
images += IMG_URL_RE.findall（content）
return images
def generate_with_check（prompt， max_retry=1）:
for attempt in range（max_retry + 1）:
try:
resp = requests.post（
f"{BASE_URL}/images/generations"，
headers={"Authorization": f"Bearer {API_KEY}"}，
json={"model": MODEL， "prompt": prompt}，
timeout=300，
）
except requests.Timeout:
# 超时无法确认服务端是否已生成并计费，不自动重打
return {"status": "timeout"， "action": "check_logs_first"}
# 第 1 步：HTTP 是否成功
if resp.status_code ！= 200:
return {"status": "http_error"， "code": resp.status_code，
"detail": resp.text[:500]}
try:
body = resp.json（）
except ValueError:
return {"status": "bad_json"， "detail": resp.text[:500]}
# 第 2 步：响应里有没有图片数据或图片 URL
images = find_images（body）
if images:
return {"status": "ok"， "images": images}
# 第 3 步：有错误信息就按错误处理，不重试
if body.get（"error"）:
return {"status": "api_error"， "error": body["error"]}
# 第 4 步：确认无图、无错误，记录原始响应后才允许重试
print（f"第 {attempt + 1} 次请求无图片，原始响应：{str（body）[:300]}"）
return {"status": "empty_after_retry"， "action": "stop_and_report"}
result = generate_with_check（"一只坐在窗台上的橘猫，水彩风格"）
print（result）
这段代码有几个关键设计值得注意。max_retry 默认是 1，意味着一张图最多产生两次请求费用，成本上限是可预期的。超时分支直接返回而不是继续循环，因为超时时无法确认是否已扣费。每次判定为空响应时都会打印原始响应，方便你事后排查到底是解析问题还是服务端真的没出图。
🚀 快速开始：如果你想先在测试环境验证这套判断逻辑，可以通过 API易 apiyi.com 获取免费测试额度，用同一个 API Key 调用 gpt-image-2.6-all 及其他主流模型，先跑通判断流程再接入正式业务。
生图没返回图片时盲重试的成本对比
把判断逻辑写进代码之前，很多人对“多重试几次”的代价没有直观感受。下面以 gpt-image-2.6-all 按次 $0.025 的价格，对比盲目连打和先看响应再重试两种策略在单张图上的额外支出。
| 处理策略 | 单张图最多请求次数 | 最坏情况额外支出 | 风险说明 |
|---|---|---|---|
| 不检查，失败就重打 1 次 | 2 次 | $0.025 | 可能为已出图的请求重复付费 |
| 不检查，循环连打 3 次 | 4 次 | $0.075 | 对必然失败的请求反复付费 |
| 不检查，循环直到出图 | 不确定 | 无上限 | 遇到内容审核类拒绝时持续扣费 |
| 先看响应，确认无图后重试 1 次 | 2 次 | $0.025 | 只在真正空响应时付出额外成本 |
表面上看，“先看响应再重试”和“失败就重打 1 次”的最坏额外支出一样，但两者的触发条件完全不同。前者只在确认没有图片、也没有错误信息的情况下才花这 $0.025；后者会在已经出图但解析失败、或者内容被拒绝的情况下同样花掉这笔钱，而且换不来任何结果。
当调用量放大到批量生图时，这个差异会被成倍放大。每张图多付的 $0.025 乘以每天的请求量，就是一笔完全可以避免的支出。
生图没返回图片的接口与模型参考
不同模型和接口形态返回图片的位置可能不同，这直接影响第 2 步的判断是否准确。下表整理了常见的返回形态与检查要点，帮助你确认自己的解析代码没有漏掉图片。
| 返回形态 | 图片所在位置 | 解析要点 | 可用平台 |
|---|---|---|---|
| 图像生成接口（URL） | data[].url |
注意链接可能有有效期，拿到后尽快下载保存 | API易 apiyi.com，以模型文档为准 |
| 图像生成接口（Base64） | data[].b64_json |
解码后写入文件，不要误判为空字符串 | 同上 |
| 对话接口内嵌图片 | choices[].message.content |
用正则提取 Markdown 图片或链接 | 同上 |
| 流式返回 | 分片拼接后的完整内容 | 必须等流结束、拼接完整后再判断有无图片 | 同上 |
流式返回是另一个容易造成误判的地方。如果你在收到第一个分片时就去找图片，自然什么都找不到。生图没返回图片时，一定要确认你检查的是完整的响应，而不是中间状态。
常见问题 FAQ
Q1：生图没返回图片，是不是一定没扣费？
不一定。请求是否计费取决于服务端是否处理了这次请求，而不是你的代码有没有取到图片。解析字段写错、流式响应没拼完整、客户端提前超时，都可能出现“已计费但你没拿到图”的情况。所以要先看响应再重试，而不是默认没扣费就随手重打。
Q2：先看响应再重试，和普通的指数退避重试有什么区别？
指数退避解决的是“什么时候重试”，适合限流和临时性服务端故障；先看响应再重试解决的是“该不该重试”。对于按次计费的生图请求，应该先用 4 步判断确认确实需要重试，再结合退避策略决定重试时机，两者是先后关系而不是替代关系。
Q3：gpt-image-2.6-all 是什么时候上线的，价格是多少？
gpt-image-2.6-all 于 2026-11-12 在 API易 上线，按次计费 $0.025。按次计费意味着每一次请求都是独立计价的，空响应直接重试会再付一次，这也是本文强调先看响应再重试的直接原因。
Q4：哪些情况下生图没返回图片时绝对不要重试？
主要有三类：
– **响应里带有错误信息**：例如提示词触发内容审核或参数不合法，原样重试结果相同。
– **请求超时**：无法确认服务端是否已生成并计费，应先核对日志。
– **鉴权或额度类 HTTP 错误**：重试不会改变结果，需要先修正 Key 或额度问题。
Q5：如何快速验证自己的判断逻辑是否正确？
建议在测试环境中先跑通完整流程：
1. 在 API易 apiyi.com 注册账号，获取 API Key 和免费测试额度
2. 把本文完整示例中的 `BASE_URL` 设为 `https://api.apiyi.com/v1`，调用 gpt-image-2.6-all
3. 分别用正常提示词和可能被拒绝的提示词测试，观察每个分支的返回
确认每种响应都能落到正确分支后，再接入正式业务。
Q6：重试一次之后还是没有图片，应该怎么办？
停止自动重试，把两次请求的原始响应、请求参数和时间记录下来。先检查解析代码是否遗漏了图片字段，再到控制台核对这两次请求的调用记录。如果确认是服务端连续返回空结果，可以带着请求时间和原始响应通过 API易 apiyi.com 联系技术支持排查，比继续付费重打更有效。
Q7：批量生图时怎么控制重试成本？
给每个生图任务设置独立的重试计数，并把单任务重试上限固定为 1 次。同时建议在任务层面统计“空响应率”，如果某批任务空响应明显偏多，优先排查提示词和解析逻辑，而不是整体放大重试次数。
生图没返回图片时先看响应再重试：核心要点 Key Takeaways
- 没图不等于没扣费：按次计费的生图请求，服务端处理过就可能已计费。
- 判断顺序固定：HTTP 状态 → 图片数据或 URL → 错误信息 → 确认无图后重试。
- 重试只给一次：确认无图且无错误后只重试一次，成本上限可预期。
- 超时不自动重打：超时无法确认生成状态，先核对日志再决定是否补发。
- 解析要覆盖多种位置：同时检查
data字段和对话content，避免误判空响应。 - 盲重试有明确代价：gpt-image-2.6-all 每多一次盲重试就多付 $0.025。
- 先在测试额度上验证：可通过 API易 apiyi.com 的免费测试额度跑通判断流程后再上线。
总结
生图没返回图片时，先看响应再重试的核心要点：
- 先排查再花钱：检查响应几乎零成本，盲目重试每次都要付费。
- 按 4 步顺序判断：HTTP 是否成功、有没有图片、有没有错误、确认无图后才重试一次。
- 把规则写进代码：限制重试次数、超时不自动重打、记录原始响应，让成本可控、问题可查。
对于调用按次计费图像模型的开发者来说，这套判断法并不复杂，但能实实在在地避免同一张图被扣两次费。建议先在测试环境里把各个分支都走一遍，再把它作为生图调用的标准封装。
推荐通过 API易 apiyi.com 快速验证这套处理逻辑，平台提供 OpenAI 兼容接口和免费测试额度，一个 Key 即可调用 gpt-image-2.6-all 等多种主流模型。
📚 参考资料
- API易 文档中心：模型调用方式与返回格式说明
- 链接：
docs.apiyi.com -
说明： 查看 gpt-image-2.6-all 的具体调用端点与响应字段，以文档为准
-
OpenAI Images API 参考：图像生成接口的标准响应结构
- 链接：
platform.openai.com/docs/api-reference/images - 说明： 了解
data数组中url与b64_json字段的含义
作者: APIYI 技术团队
技术交流: 欢迎在 API易 网站首页联系我们，更多接入资料可访问 docs.apiyi.com 文档中心
