图片编辑报 Unable to process input image 怎么办？

Nano Banana 图片编辑返回 400「Unable to process input image」或「empty inlineData parameter」，原因是请求里 inlineData 的图片数据为空，与图片 URL 是否可访问无关；改用 URL 传图时报 Cannot fetch content 则是谷歌拉图超时。逐项排查 base64 转码步骤并在发送前加一道检查即可。

​

症状

调用 Nano Banana 系列（gemini-3.1-flash-image-preview、gemini-3-pro-image-preview、gemini-nano-banana-2.1 等）做带参考图的图片编辑时，接口返回 HTTP 400，报错是下面两句之一：

{
  "error": {
    "message": "Unable to process input image. Please retry or report in https://developers.generativeai.google/guide/troubleshooting",
    "code": 400
  }
}

Unable to submit request because it has an empty inlineData parameter. Add a value to the parameter and try again.

通常是一段时间内连续报错、换个时间又正常，看起来像是接口不稳定。

​

原因

请求里 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。

​

发送前加一道检查

在组装请求之前加几行校验，问题会在本地直接暴露，不用等接口报错：

JavaScript

const b64 = (imageBase64 || '').replace(/^data:[^;]+;base64,/, '');
if (!b64) {
  throw new Error('参考图 base64 为空，请检查下载 / 转码步骤');
}

const payload = {
  contents: [{
    parts: [
      { text: prompt },
      { inlineData: { data: b64, mimeType: imageMimeType } }
    ]
  }],
  generationConfig: {
    responseModalities: ['IMAGE'],
    imageConfig: { imageSize: '2K' }
  }
};

Python

import base64, re

def to_inline_data(image_bytes: bytes, mime_type: str) -> dict:
    if not image_bytes:
        raise ValueError("参考图内容为空，请检查下载 / 读取步骤")
    b64 = base64.b64encode(image_bytes).decode()
    return {"inlineData": {"data": b64, "mimeType": mime_type}}

def strip_data_url(s: str) -> str:
    b64 = re.sub(r"^data:[^;]+;base64,", "", s or "")
    if not b64:
        raise ValueError("参考图 base64 为空")
    return b64

这类 400 是请求本身的问题，原样重试不会成功。修好之后不需要做任何平台侧的配置。

​

想直接传图片 URL 怎么办

Gemini 原生端点也支持直接传图片链接，写法是 fileData，不是 inlineData：

{
  "fileData": {
    "fileUri": "https://your-bucket.example.com/ref.png",
    "mimeType": "image/png"
  }
}

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

​

URL 传图报 Cannot fetch content from the provided URL

用 fileData.fileUri 传图时，还可能遇到另一种 400，这次是会直接报错的：

{
  "error": {
    "message": "Cannot fetch content from the provided URL. Please ensure the URL is valid and accessible. Status: URL_REJECTED-REJECTED_FC_TIMEOUT",
    "code": 400
  }
}

这是谷歌的服务器下载你的图片超时了，和 inlineData 为空不是一回事。谷歌拉取 URL 的时间上限约 60 秒，图床响应谷歌服务器慢时就会撞上，所以典型特征是每次失败都恰好在 60 秒左右返回。

图片能在浏览器里秒开，不代表谷歌拉得动。 我们用海外对象存储（AWS S3 美西）上一张约 500KB 的 PNG 实测：同一个链接在本地 1 秒内下载完成，但交给谷歌拉取时，8 次里有 5 次在约 60 秒时报上面这个错，成功的那几次也要 60–77 秒；同一张图改成 base64 内联发送，次次成功，约 18 秒出图。换渠道结果一样，说明问题出在谷歌与该图床之间，与 API易 的渠道无关。

解决办法：

1. 改用 inlineData 发送 base64（推荐）：先自己把图片下载下来再转 base64，不再依赖谷歌去拉图，这个错误会彻底消失。记得按上文加一道「base64 不为空」的检查。
2. 必须用 URL 时，尽量降低谷歌拉取的耗时：上传时把对象的 Content-Type 设成真实格式（如 image/png，而不是 S3 默认的 binary/octet-stream），并优先给出 CloudFront 等全球 CDN 的地址。这能缓解，但不能保证不超时。

同一个 URL 第二次请求往往会变快，因为谷歌会缓存拉过的图片。所以「我重试一下就好了」只说明这张图被缓存了，换一张新图还会再超时，不能当作问题已解决。

​

常见问题

我的图片是公网可读的，为什么还会报这个错？

用 inlineData 发送时原厂不会访问任何链接，图片是否公网可读不影响结果。请检查程序把图片转成 base64 的环节，确认发出去的 data 字段不是空的。

这类失败的请求会扣费吗？

不会。请求在原厂入口就被拒绝了，不会生成图片，也不会产生费用；URL 拉图超时的 400 同样不扣费。具体以控制台调用日志为准。

​

相关文档

Nano Banana 开发指南

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

Gemini 生图错误处理指南

各类报错与 finishReason 的处理方式

上传图片报 MIME type 不匹配？

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

图片压缩与分辨率

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