> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apiyi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 图片编辑报 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，报错是下面两句之一：

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

```text theme={null}
Unable to submit request because it has an empty inlineData parameter. Add a value to the parameter and try again.
```

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

## 原因

**请求里 `inlineData.data` 是空的，原厂没有拿到图片内容。** 两句报错是同一个原因，只是不同节点的措辞不同：一句直接说「inlineData 参数为空」，另一句说「无法处理输入图片」，后者容易让人误以为是图片格式损坏或图片链接打不开。

> [!NOTE]
>
> **和图片 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**

```javascript theme={null}
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**

```python theme={null}
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
```

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

## 想直接传图片 URL 怎么办

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

```json theme={null}
{
  "fileData": {
    "fileUri": "https://your-bucket.example.com/ref.png",
    "mimeType": "image/png"
  }
}
```

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

### URL 传图报 Cannot fetch content from the provided URL

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

```json theme={null}
{
  "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 秒左右返回**。

> [!NOTE]
>
> **图片能在浏览器里秒开，不代表谷歌拉得动。** 我们用海外对象存储（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 的地址。这能缓解，但不能保证不超时。

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

## 常见问题

> **我的图片是公网可读的，为什么还会报这个错？**
>
> 用 `inlineData` 发送时原厂不会访问任何链接，图片是否公网可读不影响结果。请检查程序把图片转成 base64 的环节，确认发出去的 `data` 字段不是空的。

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

## 相关文档

> **[Nano Banana 开发指南](/api-capabilities/nano-banana-dev-guide)**
>
> 输入图片要求、URL 传图与超时设置

> **[Gemini 生图错误处理指南](/api-capabilities/gemini-image-error-handling)**
>
> 各类报错与 finishReason 的处理方式

> **[上传图片报 MIME type 不匹配？](/faq/image-mime-type-mismatch-with-query)**
>
> 图床链接带处理参数导致的格式不符

> **[图片压缩与分辨率](/api-capabilities/image-compression-resolution)**
>
> 参考图压缩不影响输出画质


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.