作者注：調用生圖接口時，響應裏沒有圖片不等於請求失敗，更不等於沒扣費。本文給出先看響應、再決定是否重試的 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 文檔中心
