Skip to main content

症状

调用 Nano Banana 系列(gemini-3.1-flash-image-preview、gemini-3-pro-image-preview、gemini-nano-banana-2.1 等)做带参考图的图片编辑时,接口返回 HTTP 400,报错是下面两句之一:
通常是一段时间内连续报错、换个时间又正常,看起来像是接口不稳定。

原因

请求里 inlineData.data 是空的,原厂没有拿到图片内容。 两句报错是同一个原因,只是不同节点的措辞不同:一句直接说「inlineData 参数为空」,另一句说「无法处理输入图片」,后者容易让人误以为是图片格式损坏或图片链接打不开。
和图片 URL、图床是否公网可读无关。 用 inlineData 发送时,图片是以 base64 的形式放在请求体里的,原厂不会去访问任何链接。报这个错说明 base64 字符串本身是空的,问题出在你的程序把图片转成 base64 的那一步。
一个可以自查的旁证:在控制台日志里看这几次请求,失败的请求输入 token 很少(只有提示词的量),而正常带图的请求输入 token 会多出几百到几千。

逐项排查

1

图片下载或转码那一步是否真的成功了

很多程序是先从对象存储(COS / OSS / S3)把图片下载下来,再转成 base64。如果下载失败、超时,或者异步步骤还没完成就发出了请求,拿到的就是空字符串。先在发送前把 base64 的长度打印出来确认。
2

变量是否为 undefined

JavaScript 的 JSON.stringify 会直接丢掉值为 undefined 的字段。如果 imageBase64 是 undefined,序列化后的请求里 inlineData 只剩 mimeType,data 字段整个消失,原厂同样会报 inlineData 为空。这种情况在代码里看不出来,必须打印实际发出的请求体才能发现。
3

data 里是否带了 data URL 前缀

inlineData.data 只放纯 base64。如果把 data:image/png;base64,iVBORw0... 整串放进去,要先去掉逗号及之前的前缀。
4

mimeType 是否与图片实际格式一致

mimeType 写 image/png、image/jpeg 或 image/webp,要与图片的真实格式一致。文件扩展名不可靠,比如有些手机拍的 .jpg 实际是多帧格式,最稳妥的做法是转码时统一重新编码成 PNG 或 JPEG。

发送前加一道检查

在组装请求之前加几行校验,问题会在本地直接暴露,不用等接口报错:
这类 400 是请求本身的问题,原样重试不会成功。修好之后不需要做任何平台侧的配置。

想直接传图片 URL 怎么办

Gemini 原生端点也支持直接传图片链接,写法是 fileData,不是 inlineData:
用 URL 传图时,图片要由谷歌的服务器去下载。如果图床只走国内 CDN(例如腾讯云对象存储的默认配置),谷歌经常拉不到,表现通常是生成结果不参考这张图,而不是报错。条件允许的话,更推荐 base64 方式,稳定性最高。完整说明见 Nano Banana 开发指南。

常见问题

用 inlineData 发送时原厂不会访问任何链接,图片是否公网可读不影响结果。请检查程序把图片转成 base64 的环节,确认发出去的 data 字段不是空的。
不会。请求在原厂入口就被拒绝了,不会生成图片,也不会产生费用。具体以控制台调用日志为准。

相关文档

Nano Banana 开发指南

输入图片要求、URL 传图与超时设置

Gemini 生图错误处理指南

各类报错与 finishReason 的处理方式

上传图片报 MIME type 不匹配?

图床链接带处理参数导致的格式不符

图片压缩与分辨率

参考图压缩不影响输出画质