nano banana pro 怎么用？生图接口返回的图别直接存链接：nano banana pro / gpt-image-2 出图结果的落库与转存

接 图像生成接口 的时候有个坑，很多人是上线三个月后才踩到的：把返回的图片链接直接存进数据库，然后前端拿这个链接展示。当时一切正常，几个月后用户反馈"历史作品全裂了"。

原因很简单------生成结果的链接通常有有效期，或者带签名参数。它是给你下载用的，不是给你当持久存储用的。

这篇讲接 AIGC 接口 之后，结果该怎么处理。以甜甜圈API （dashengfenshen.cn）为例，但这套做法对任何生图 API 都通用。

一、正确的处理顺序

生成完成之后，别急着返回给前端：

拿到结果立刻下载到自己的服务；
转存到自己的对象存储（OSS / COS / S3 都行）；
数据库里存自己的 key，不是上游链接；
前端展示走自己的 CDN。

import uuid, requests
from openai import OpenAI

client = OpenAI(api_key="ttq-你的密钥", base_url="https://dashengfenshen.cn/v1")

def generate_and_store(prompt: str, model: str = "nano-banana2") -> str:
resp = client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": prompt}],
)
url = extract_image_url(resp) # 按文档的响应字段取图片地址
复制代码
```
 # 立刻下载并转存，别把上游链接存进库
 data = requests.get(url, timeout=60).content
 key = f"aigc/{uuid.uuid4().hex}.png"
 oss.put_object(key, data)                      # 换成你自己的存储 SDK
 return key                                     # 库里存这个
```

响应字段的准确结构以开发文档「图片生成接口 → 响应字段」为准。

二、转存时顺手做的三件事

既然都下载下来了，有几件事一起做掉最划算：

记原始参数 ：model、提示词、aspect_ratio 一起入库。以后要复现、要做效果回溯、要分析哪种提示词效果好，全靠这些；
算内容哈希：同样的提示词可能被重复提交，哈希一比就能命中缓存，直接省掉一次调用的钱（生图 8~10 积分、生视频 120+，省一次是一次）；
存缩略图 ：列表页不该加载原图，尤其 nano-banana-pro 能出到 4K。

三、视频要格外注意

视频文件比图片大得多，转存策略要调整：

Sora 2 是 12 秒、16:9 或 9:16；Veo 3.1、Omni 是 10 秒量级；ttq-td 固定 15 秒。文件动辄几 MB 到几十 MB；
下载要设更长的超时，别用图片那套参数；
考虑异步转存：生成完先把上游链接给前端应急展示，后台任务慢慢转存，转完再替换记录里的地址。

视频单次成本也高得多（Veo 3.1 120 积分、Sora 2 130 积分，是生图的十几倍），丢一个结果的代价不是丢一张图，是丢一次调用的钱，所以转存失败一定要有重试。

四、缓存能省多少

我的项目里加了提示词哈希缓存之后，重复调用命中率大概两成------直接省掉两成的生图开销。这在跑量场景下很可观，尤其配合分级用模型（终稿 nano-banana-pro 10 积分、铺量 nano-banana2 8 积分）。

五、小结

接 AI绘画API 时，很多人把注意力全放在"怎么调通"，忽略了"结果怎么管"。把转存、参数留痕、哈希缓存这三件事做上，能避掉图片失效的事故，还能顺带省钱。

甜甜圈API （dashengfenshen.cn）：一个接口接 nano-banana-pro / nano-banana2 / gpt-image-2 / ttq-cutout / Veo 3.1 / Sora 2，OpenAI 兼容改 base_url 就能用；价格便宜 （积分制按次计费）、并发高 （批量转存任务跑得动）、出图快 、出视频快 、稳定。文档地址：https://dashengfenshen.cn 。