图像生成API工程化实战：Nano Banana接入避坑指南

Nano Banana Images API，听名字像是团队内部开的玩笑，但它实际承担了我这边所有图像生成任务的流量入口。这是一个把底层文生图模型封装成标准HTTP接口的服务：你传一句描述，它回一张图；你传一批描述，它回一批图。接口本身不算复杂，难的是把它真正接入工程后，面对鉴权、异步、限流、内容合规、成本控制这一连串问题时，怎么不踩坑。

这篇文章不打算把官方文档翻译一遍，也不去复述每个字段的说明。文档上写清楚的，你打开文档看就行。我更想讲的是从拿到密钥到生产可用的完整过程里，那些文档不会写、但实际调试一定会遇到的事情：为什么同步请求容易翻车？异步任务到底怎么轮询？prompt怎么写才能稳定出图？明明接口正常，为什么业务一上量就开始 429？如果你正准备把 Nano Banana Images API 接进自己的项目，这篇内容可以直接当避坑手册用。

适合谁看？后端同学、做内部工具平台的开发者、需要在业务里接入图像生成能力的产品或技术负责人。如果你只是想拿一个 key 玩一下，也可以看，但前面几章稍微扫一下就行，重点看第3章和第5章。

1. 先想清楚：Nano Banana Images API 到底解决什么问题

1.1 它解决的真实业务痛点

做业务集成前，最好先想清楚这个 API 是来干什么的。它解决的不是“我们没有图像生成模型”的问题，而是“模型能用，但没法快速变成业务能力”的问题。很多团队早期会用开源模型自建推理服务，但自建要处理显卡调度、模型更新、并发排队、监控告警，这一套跑下来投入非常大。Nano Banana Images API 把这些全都收进服务端，客户端只发一个 HTTP 请求，把提示词送过去，拿回图片。

我接触它的第一个场景是电商运营素材。运营同学每天要换一批商品背景图，比如保温杯从纯白背景换成木质桌面，每次都要开设计工具手动修。接入之后，一个简单的请求脚本就把这个重复劳动吞掉了。类似的场景还有内容社区封面图、广告创意草稿、设计团队风格稿预演。它的核心价值，是把“离散的图像生成能力”变成了“可以被业务代码稳定调用的服务”。

1.2 为什么不只依赖官方SDK

选型时很多人第一反应是“有没有官方SDK”。我的建议是：如果这个服务提供纯REST接口，优先以REST为标准来做集成。理由有三个：第一，SDK会随着服务端版本迭代，你不一定每次都跟着升级，而HTTP接口的路径和参数相对稳定；第二，REST调用天然可以在网关层统一加日志、限流、审计，出了问题也好排查；第三，语言无关，同一套对接方案团队里谁都可以维护，不用绑定某个编程语言生态。

类比一下：调SDK像是去餐厅点了固定套餐，端上来什么吃什么；调REST接口像自己拿着菜单点菜，想怎么组合都行，而且菜单基本不变。倒不是说SDK不能用，而是当你面向的是一个需要长期维护的业务系统时，REST是更稳妥的底座。

1.3 同步与异步，选错真的会翻车

这是很多人第一次对接时最容易踩的坑。Nano Banana Images API 的生成接口通常有同步和异步两种方式。同步调用是请求发过去，服务端等模型推理完成再返回图片，整个过程可能几秒到几十秒。异步调用是先提交任务，服务端马上返回一个 task_id，客户端拿着这个 id 查状态，等到状态变成 succeeded 再拿结果。

哪一个更合适？如果你在编辑器里做一个“生成”按钮，用户愿意等，同步也勉强能跑；但凡是批量生成、或者调用方在网关后面，我强烈建议用异步。网关的读超时往往只有几秒到十几秒，同步请求一旦超过这个时间，客户端还没拿到结果，网关已经断开了连接。异步像去银行取号排队，先把需求登记上，轮到了再通知你；同步像在柜台死等，队伍一长后面全堵住。

选型结论写在前面：先用异步。把提交和查询分开，任务失败还能重试，也方便追踪全链路耗时。

2. 拿到密钥，读懂请求与返回的每个细节

接下来进入实操前的地基。你不要上来就写代码，先把账号、密钥、接口路径和返回结构看明白。

2.1 密钥申请与权限规划

去开发者控制台创建一个应用，申请API密钥。不同的图像服务在鉴权方式上有一点差别，有的直接用Authorization: Bearer <key>，有的需要先用 client_id 和 client_secret 换一个短期 access_token。无论哪种方式，第一原则都是：密钥绝对不要硬编码在代码里，更不能提交到代码仓库。我见过不止一次因为 key 写进代码被推到公开仓库，几小时内被人盗刷的案例。正确做法是放到环境变量里，部署时由 CI/CD 的 Secret 注入。

如果控制台支持细粒度权限，尽量按最小权限分。比如这个应用只负责调用图片生成和查询任务，那就不要给它账号管理权限。密钥分环境管理也是一个习惯，开发环境一把 key，生产环境一把 key，两边配额独立，线上出了故障也不会因为开发调试把生产额度打满。

在本地，可以这样设置：

export NANOBANANA_API_KEY="sk_你的密钥"

注意这只是示例，真实 key 从控制台复制，不要把示例中的地址当成真实服务地址。

2.2 基础URL、请求头与路径

我按常见的设计给出一个示意契约，你接入时以服务方文档为准：

• 基础URL：https://api.nanobanana.example.com/v1
• 创建生成任务：POST /images/generations
• 查询任务：GET /tasks/{task_id}

请求头通常是这样：

Authorization: Bearer $NANOBANANA_API_KEY Content-Type: application/json Accept: application/json

有两个细节值得注意。第一，Content-Type 一定不能漏，漏了服务端可能把请求体当文本解析，直接给你 400。第二，如果是服务端集成，最好在 User-Agent 里带上团队或应用标识，这样服务方排查问题时能快速定位到你的调用方，而不是所有人都叫 curl/requests。

2.3 请求体字段逐个讲：别被“能调通”骗了

下面是一个常见的文生图请求体：

{ "model": "nano-banana-v2", "prompt": "一只橘猫坐在木质书桌前，晨光从窗户照入，桌子上放着一杯咖啡，摄影风格，细节清晰", "negative_prompt": "模糊，低分辨率，水印，多余手指", "image_size": "1024x1024", "samples": 1, "sampling_steps": 4, "guidance_scale": 3.5, "seed": 20240601, "response_format": "b64_json" }

逐个说明一下：

• model：选择模型版本。同一个服务可能同时存在多个版本，建议在配置项里显式指定，不要依赖服务端的默认值，因为默认值可能在你不知情的时候被切换。
• prompt：正向提示词，这是最主要的影响因素。写得越具体，结果越可控。只写“一只猫”和写“一只橘猫坐在木质书桌前，晨光从窗户照入”出来的效果完全两回事。
• negative_prompt：负向提示词，用来排除你不想要的东西。常见的是“模糊、低分辨率、水印、文字错误”这类。这个参数不是所有接口都有，但只要有，建议带上。
• image_size：出图的尺寸。不同服务支持的列表不太一样，常见的有 1024x1024、1536x1024、1024x1536。不要盲目上超大分辨率，生成时间会明显变长，效果不一定更好。
• samples：一次生成几张候选图。业务选图场景通常设成3张，让用户挑一张，而不是一张出一遍。
• sampling_steps：采样步数。很多服务其实已经对默认参数做过调优，你手动调到很大并不会显著提升质量，反而增加耗时。我建议先保持默认。
• guidance_scale：提示词引导强度。调高会更贴近提示词，但过高容易出现色彩过饱和、画面僵硬；过低则可能偏离你的描述。默认值附近就好，具体可以看第4章的调优经验。
• seed：随机种子。固定同一个 seed，在同样参数下可以复现接近的结果；不传或随机变化，则每张图都会不同。
• response_format：返回格式，常见是b64_json或url。按你自己的存储方案选，两种格式的消费方式不太一样。

2.4 返回结构：同步和异步差在哪里

如果是同步调用，响应体一般是：

{ "created": 1720000000, "data": [ { "b64_json": "...", "seed": 20240601, "finish_reason": "SUCCESS" } ] }

如果是异步提交，响应体一般是：

{ "task_id": "task_8f3a2b9c", "status": "queued", "estimated_seconds": 15 }

拿到 task_id 之后，用GET /tasks/{task_id}轮询，查询结果通常包含 status、错误信息和最终数据。状态机一般是这样：queued -> processing -> succeeded / failed。也有服务用 pending/rejected 等词，细节看文档，但核心就是那几个阶段。

这里有一个坑：如果返回格式选了url，不要把链接直接存数据库就完事。很多服务的下载链接是带有效期的临时签名，过几个小时就失效了。正确做法是拿到链接后马上下载，转存到自己的对象存储，再落库。选b64_json则需要自己解码成文件保存，多一步，但没有链接过期问题。两种方案我在项目里都用过，对批量任务更推荐b64_json，因为少一次外部下载依赖。

3. 从0到1跑通第一次图像生成请求

文档看再多也不如先跑通一条链路。不要一上来就写一堆类，先把最小流程验证一遍。

3.1 先用curl验证密钥和连通性

写代码之前，用curl跑一次，好处是能最快排除“到底是代码问题还是环境问题”。

curl -s https://api.nanobanana.example.com/v1/images/generations \ -H "Authorization: Bearer $NANOBANANA_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "nano-banana-v2", "prompt": "一只橘猫坐在木质书桌前，晨光从窗户照入，桌子上放着一杯咖啡，摄影风格，细节清晰", "image_size": "1024x1024", "samples": 1, "response_format": "b64_json" }'

如果返回 JSON 里带b64_json，说明网络、鉴权、参数都通了。如果返回 401，检查密钥；如果返回 400，看错误信息里的参数校验提示。这一步虽然原始，但对定位问题非常有效。很多开发者在工程里找半天 bug，最后发现是本地环境变量没生效，curl 一下立刻露馅。

3.2 Python 最小客户端

验证通过之后，就可以写一个最简 Python 客户端了。

import os import base64 import requests API_BASE_URL = "https://api.nanobanana.example.com/v1" API_KEY = os.environ["NANOBANANA_API_KEY"] def generate_image(prompt: str, size: str = "1024x1024") -> bytes: resp = requests.post( f"{API_BASE_URL}/images/generations", headers={ "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json", }, json={ "model": "nano-banana-v2", "prompt": prompt, "image_size": size, "samples": 1, "response_format": "b64_json", }, timeout=(5, 60), ) resp.raise_for_status() payload = resp.json() img_b64 = payload["data"][0]["b64_json"] return base64.b64decode(img_b64) if __name__ == "__main__": image_bytes = generate_image("一只橘猫坐在木质书桌前，晨光从窗户照入，桌子上放着一杯咖啡，摄影风格") with open("output.png", "wb") as f: f.write(image_bytes) print("saved to output.png")

这段代码有几个点我要特意说一下。timeout传的是(5, 60)，意思是连接超时5秒、读取超时60秒。图像生成接口响应可能比较慢，读超时不能设太短，否则大图还没传完客户端就主动掐断了。另外，raise_for_status()一定要有，否则 HTTP 4xx/5xx 时你可能还在尝试解析 JSON，报错信息会被误导。密钥从环境变量取，这已经是老生常谈，但我还是要在代码里再做一次示范。

3.3 异步任务提交与轮询

如果服务方支持异步生成，生产环境建议走异步链路。提交时把参数发给创建接口，拿到 task_id，然后定时查询：

import time import base64 import requests API_BASE_URL = "https://api.nanobanana.example.com/v1" API_KEY = os.environ["NANOBANANA_API_KEY"] def submit_generation(prompt: str, size: str = "1024x1024") -> str: resp = requests.post( f"{API_BASE_URL}/images/generations", headers={"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}, json={"model": "nano-banana-v2", "prompt": prompt, "image_size": size, "samples": 1, "response_format": "b64_json"}, timeout=(5, 30), ) resp.raise_for_status() return resp.json()["task_id"] def wait_for_task(task_id: str, timeout: int = 180, interval: float = 5.0) -> bytes: start = time.time() while time.time() - start < timeout: resp = requests.get( f"{API_BASE_URL}/tasks/{task_id}", headers={"Authorization": f"Bearer {API_KEY}"}, timeout=(5, 10), ) resp.raise_for_status() data = resp.json() status = data.get("status") if status == "succeeded": return base64.b64decode(data["data"][0]["b64_json"]) if status == "failed": raise RuntimeError(f"generation failed: {data.get('error')}") time.sleep(interval) raise TimeoutError(f"task {task_id} not finished within {timeout}s")

轮询间隔为什么取5秒而不是0.5秒？太频繁会把请求打上被限流的名单，而且任务根本不会因为你多查几次就变快。如果响应里带了estimated_seconds，更合理的做法是先用它估算一个首查时间，而不是生成后立即开始轮询。举例：它预计15秒完成，你可以在第10秒左右开始第一次查询，然后每5秒查一次。我这里为了示例写了固定间隔，实际项目建议动态一点。

3.4 批量生成：复用连接，控制并发

批量场景是这类 API 最常见的用法。比如运营一次要生成20张不同文案的背景图，同步一张一张吃时间太长，并发开太大又容易被限流。我的经验是控制在2到4个并发，用requests.Session()复用连接：

from concurrent.futures import ThreadPoolExecutor, as_completed import requests API_KEY = os.environ["NANOBANANA_API_KEY"] API_BASE_URL = "https://api.nanobanana.example.com/v1" session = requests.Session() session.headers.update({ "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json", }) def submit_one(prompt: str) -> str: resp = session.post( f"{API_BASE_URL}/images/generations", json={"model": "nano-banana-v2", "prompt": prompt, "image_size": "1024x1024", "samples": 1, "response_format": "b64_json"}, timeout=(5, 30), ) resp.raise_for_status() return resp.json()["task_id"] prompts = ["prompt1", "prompt2", "prompt3"] with ThreadPoolExecutor(max_workers=3) as pool: futures = {pool.submit(submit_one, p): p for p in prompts} for future in as_completed(futures): task_id = future.result() print(f"submitted: {task_id}")

每一张图片都先提交成异步任务，再统一查询，这样批量生成的消耗更平滑。直接对一批同步请求开线程池也跑得动，但一旦其中某个请求卡在慢任务上，线程池里的线程会被拖住；异步任务没有这个问题，因为提交阶段很快，查询阶段可以统一调度。

3.5 拿回结果：先校验再入库

不管用哪种返回格式，拿到的图片先做基本校验再落盘，不要无脑写文件。常见校验包括文件头、文件大小和尺寸。PNG 文件头是固定的字节序列，JPEG 也有固定魔数。校验函数很简单：

def is_png(data: bytes) -> bool: return data.startswith(b"\x89PNG\r\n\x1a\n")

为什么需要这一步？我实际遇到过服务端返回b64_json但内容被网关截断的情况，解码出来的文件打不开；也遇到过返回内容是合法图片但尺寸不是预期值的情况。提前拦截掉，比业务下游拿到坏图再排查要省事得多。

4. 把生成结果调到业务可用的状态

能出图只是第一步，出什么质量的图才是业务关心的。这一章主要讲提示词和参数的实战经验。

4.1 prompt必须按结构写

图像生成模型的提示词不是自然语言作文，而是结构化的信息组合。我的经验是拆成五个维度：主体、环境、光线、构图、风格。举例：

• 主体：一只橘猫
• 环境：木质书桌、窗边
• 光线：晨光从窗户照入
• 构图：近景、视线平视
• 风格：摄影风格、细节清晰

最终拼成“一只橘猫坐在木质书桌前，晨光从窗户照入，桌子上放着一杯咖啡，摄影风格，细节清晰”。如果只说“一张猫的照片”，出来的图可能就是任何品种、任何背景、任何光线的猫，完全不可控。提示词不是越长越好，但关键信息缺失一定会反映在出图稳定性上。

分享一个我自己的排查方法：如果连续多次生成结果都不满意，先把 prompt 拆开，看哪个维度没有写清楚。比如背景元素缺失，就补环境；光线不对，就补光线描述；构图总是很奇怪，就明确写“近景”或“平视”。把 prompt 当成给摄影师的需求单，摄影师需要的信息你都要给。

4.2 参数选择：别在高数字里找安全感

很多新人拿到采样步数、引导强度这类参数，总觉得调高一点更放心。实际并不是。以采样步数为例，默认值往往已经覆盖了大多数需求，推到很高不仅耗时增加，画面细节未必有可感知的提升。引导强度我一般稳定在默认值附近；如果发现生成画面偏离提示词，先检查 prompt 而不是无脑调这个参数。

size 的选择也有讲究。1024x1024 是相对平衡的起点；宽幅场景用 1536x1024，竖向海报用 1024x1536。不要一开始就上最高分辨率，尤其批量生成时，一张图多出来的每几秒都会乘以数量放大成本。先在小尺寸下调好 prompt，再放大尺寸重新生成，是更省钱的路径。

seed 是调试的好帮手。prompt 和参数都确定后，固定 seed 可以复现接近的结果，方便对比调整；正式业务里通常不固定 seed，保证多样性。如果想让一批图在风格上统一，可以在某个固定 seed 附近做小范围变化，而不是完全随机。

4.3 输出内容的安全与合规检查

图像生成能力放进业务之前，必须想清楚内容边界。这不是一个可选项。我的做法是三层控制：调用前对 prompt 做关键词过滤，避免明显违规的描述进入模型；返回后对图片做抽样人工审核，尤其是公开场景的内容；服务端如果提供了安全过滤开关，一定打开。作为开发者，接入这类能力时对自己的输出负责，这既是对平台方负责，也是对用户负责。

技术落地并不复杂：调用前过滤可以用关键词列表加简单正则；返回后的抽检流程可以做成异步消息，导入内部的审核看板。这一层不要省，等到上线后被人反馈内容不合适，再补救就晚了。我见过一些团队为了赶进度跳过审核环节，最后出问题返工的成本反而更高。

4.4 三个典型业务场景的接入方案

结合我身边的实际案例，列三个典型场景：

1. 电商商品图背景生成。先固定商品主体，再传入背景描述，输出后人工抽检。这类场景对风格一致性要求高，建议维护一组固定 seed 和 prompt 模板。
2. 内容平台封面图批量生成。文案转 prompt，批量提交异步任务，完成后自动入库。核心指标是出图成功率和单张成本。
3. 设计团队风格稿预演。设计师用不同 prompt 快速出多版草案，不要求直接商用，重点是把创意筛选时间缩短。

有一个通用的成本控制策略特别值得做：结果缓存。相同 prompt、相同参数、相同 seed 的生成结果，可以在业务层做一层缓存。比如运营每天重复生成同一种“木质桌面背景的保温杯”，如果每次都真的调用模型，成本会快速累积。缓存命中时直接返回历史图片，能省掉一大半无效调用。

5. 高频报错排查与限流避坑手册

接入过程中，最影响进度的不是写代码，而是排查那些看起来莫名其妙的报错。这一章整理成可检索的速查手册。

5.1 HTTP状态码速查表

状态码是最快的定位入口。很多 500 并不是业务代码的问题，而是服务方侧临时抖动；很多 429 也不是服务方坏，而是你把并发开太高了。

5.2 三个高频报错实录

第一个是invalid_prompt。触发原因一般是 prompt 超过长度上限，或者包含服务端不允许的内容。解决方式是调用前统一做长度校验和敏感词过滤，把错误拦截在自己这一侧。我一开始没有做这个校验，结果批量任务跑到一半，第一张图就报这个错，整个队列中止，排查很久才发现是某个运营同学在文案里写了一长串特殊符号。

第二个是返回的 b64_json 无法解码成有效图片。原因可能是响应体积过大、传输被截断，也可能是客户端读取超时设置太短。我遇到过一次线上任务集体保存失败，最后定位到是任务图片较大，客户端读超时设成了10秒，大图还没传完连接就断了。把读超时放宽到60秒后恢复正常。

第三个是高频 429。批量任务并发设置过大会频繁触发限流。我一开始想省时间，把并发设为20，结果任务全部进入限流等待，整体耗时反而比并发3还慢。限流是服务端保护自己的手段，业务侧要做的不是对抗，而是平滑请求。

5.3 重试与退避策略

错误重试不是所有请求都适合。幂等操作比如查询任务状态，可以放心重试；创建生成任务如果返回 4xx，一般是参数问题，重试没有意义；5xx 和网络类异常可以重试两三次。

重试中间加退避时间，并加入少量随机抖动，避免多个请求同时重试形成“惊群”。示例思路：

import time import random def retry_on_failure(func, retries=3, base_delay=1.0): for i in range(retries): try: return func() except Exception: if i == retries - 1: raise time.sleep(base_delay * (2 ** i) + random.random() * 0.5)

这只是最小实现，生产里还要区分异常类型，只对可重试异常走这个逻辑。比如 400 这种参数异常就别重试了，重试多少次都是同样的结果，白白增加调用量。

5.4 成本和性能优化清单

• 优先异步任务，批量时平滑并发。
• 相同结果做缓存，减少重复计费。
• 下载结果后转存对象存储，用 CDN 加速输出侧。
• 为每日调用量设置告警，额度快耗尽时提前感知。
• 定期清理日志中的敏感信息，避免密钥被卷入日志。

这些点单独拿出来都不复杂，但合在一起就是“生产可用”和“Demo可跑”的本质区别。我在第2周就被一个成本问题教育过：某天运营集中提交了一批重复度很高的任务，因为没有缓存，同一张图被反复生成了几十次，查看账单时才意识到问题。从那以后，凡是可以预判重复的生成需求，一律先查缓存。

6. 从Demo到生产：隐藏的工程细节

如果你走到这一章，说明你已经不满足于本地能出图了。最后一个话题是，如何把这种调用能力安全地放进业务系统。

6.1 统一封装内部网关

最忌讳的做法是业务代码里到处直接写 Nano Banana Images API 调用。几十个服务各写各的，密钥维护、限流、参数校验都会失控。正确做法是在你的服务端搭一个内部图像生成网关，对外暴露你自己的接口，对内统一管理第三方调用。好处有三个：密钥只落在网关这一层；网关可以做权限控制和调用量统计；更换模型或服务商时，业务侧接口不用跟着改。

我在项目里把网关设计成一个很小的服务，只做三件事：接收业务侧的 prompt 和参数、调用上游接口、返回图片或任务状态。业务侧甚至不需要知道上游接口长什么样，只要关心自己的业务参数就行。这个抽象层在后期换模型版本或增加审核逻辑时，价值会体现得非常明显。

6.2 日志与监控埋点

接入生产后，一定要把链路信息记下来。每个调用关联 request_id 和 task_id，记录 prompt 长度、参数、耗时、返回状态、图片大小、seed。这些数据一方面用来排障，另一方面用来分析效果，比如什么样的 prompt 成功率高，什么样的参数组合更省钱。

日志里注意不要把完整密钥打出去，曾经有团队日志系统把请求头原样打到文件，导致密钥全部泄露。打日志时对 Authorization 做掩码处理，这是基本习惯。我们现在的做法是：请求进来时生成 request_id，业务日志里只保留Bearer sk_****这样的掩码形式，需要定位问题时再通过独立的密钥审计系统去查。

6.3 密钥轮换与失败降级

密钥不要一配永逸。按周期轮换，轮换时新旧密钥并行一段时间再切走，避免业务中断。降级方案也要提前准备：当第三方返回5xx或者配额耗尽时，你的业务不能原地报错，至少要有缓存结果兜底或者临时占位图兜底。图像生成属于增强型能力，它挂了不应该拖垮主流程。

我之前遇到过配额在凌晨被其他任务打满的情况，早上一看，线上所有生成请求全部失败，还好当时已经在网关层做了降级逻辑，直接返回了占位图，主流程没有受太大影响。这种问题越早想清楚，越不会在关键时刻手忙脚乱。

6.4 灰度发布的效果验证

新的 prompt 模板、新的参数组合上线前，先小流量灰度。原因很简单，图像生成的效果不是纯逻辑判断能保证的，需要真实业务数据来验证。比如内容平台封面图，新模板先用10%流量跑一段时间，看点击率有没有变化；如果明显下降，就回滚 prompt 模板，而不是直接全量替换。灰度期间把成功率、平均耗时、成本三个指标一起看。

我习惯把灰度做成开关配置，不需要发版就能切换模板。模板信息放在配置中心，prompt 模板可以随时调整。这样即使某一版模板效果不理想，回滚也只是改一个配置项的事，不用重新上线代码。

6.5 我踩过的那几个坑

以我自己的经验收个尾。集成这套接口的前两周，我曾踩过一个最基础的坑：把密钥明文放在配置文件里，差点跟代码一起推到公开仓库，后来是巡检脚本拦下来的。后来批量任务上线，为追求速度把并发调到20，结果触发限流，线上生成任务集体排队，速度反而比之前还慢。再后来发现很多运营重复提交相同需求的 prompt，一张图被反复生成了几十次，白白烧掉不少额度，加了缓存才把这个口子堵住。

所以如果让我给一句总结性的建议，那就是：接口本身不复杂，复杂的是你周围那圈工程防线。先跑通，再加固，最后再优化参数。别一上来就满并发布任务，也别等到线上出问题才开始补缓存和监控。

现在如果你准备接 Nano Banana Images API，第一件事不是写代码，而是去控制台申请一把最小权限的密钥，把示例 curl 跑通。拿到第一张图之后，再回来重读第3章到第6章，搭建你真正能上线的调用链路。