Nano Banana AI 图片生成 API（2026）：官方 Gemini 接入、模型选择与可运行代码

如果你现在要找 官方 Nano Banana API，你真正要找的并不是某个单独的 Nano Banana 开发者产品，而是 Gemini API 或 Google AI Studio 里的 Gemini 原生图像生成模型。对大多数 API 场景来说，最稳妥的默认起点是 Nano Banana 2，它当前的官方 model ID 是 gemini-3.1-flash-image-preview。只有当任务能明确证明自己需要更强的文字渲染、更复杂的指令遵循，或者接近专业资产生产的高保真质量时，才值得切到 Nano Banana Pro（gemini-3-pro-image-preview）。

这个直接答案之所以重要，是因为这个 query 现在充满了会把人带偏的捷径。有些页面把 Nano Banana 当成独立应用，有些把 AI Mode 当成 API，还有些把 wrapper/gateway 写得像产品本体。正确的理解其实更简单：Nano Banana 指的是 Gemini 的原生图像家族；官方开发者路径是 Gemini API + AI Studio；而大多数团队应该先从 Nano Banana 2 开始。

下文中所有 model ID、价格与消费端额度，都已经在 2026 年 3 月 29 日 对照 Google 当前帮助中心、开发者文档与定价页重新核实。

TL;DR

先给最短可用答案。

真正有用的一句话是：把“Nano Banana API”理解成 Gemini API 问题，而不是去找一个神秘的 Nano Banana 官网入口。

Nano Banana API 现在到底指什么

Google 当前的 image generation 文档把 Nano Banana 定义为 Gemini 的原生图像生成能力，而不是单一 surface。实际落到 API 语境里，它现在对应的是一个小型家族：

很多搜索结果现在仍然没有把这件事讲清楚。这个关键词表面看上去像是你要找一个单独的“产品页”，一个账号入口，以及一个显然该选的模型。但 Google 现在已经不是这样描述它了。当前更准确的结构是 家族选择 + surface 选择：

• 你到底需要家族里的哪一个版本
• 你到底要的是官方 API、官方测试 UI，还是消费端入口

第二个必须纠正的点，是 生成图片本身已经是 Gemini 请求/响应合同的一部分，而不是藏在某个别的 Google 产品之后的黑箱。当前 image generation 文档已经直接给出了请求形状、图生图编辑、宽高比控制、图像尺寸、搜索 grounding 工具等能力。Google 还明确写到，所有生成图片都带 SynthID 水印。如果你的产品需要考虑 AI 来源标记或可追踪性，这一点并不次要。

如果你的真实问题比 API 更宽，你想看 Gemini、AI Mode 与 Google 各个入口之间的整体关系，可以继续读我们的 Nano Banana AI 图片生成器指南。但这篇文章的任务更窄：它只回答 官方 API 应该怎么接。

哪条是官方 API 路线，哪条不是

最容易把人带乱的做法，就是把 Gemini Apps、AI Mode、AI Studio、Gemini API 和 wrapper 全部放进同一个桶里。它们彼此相关，但绝不是同一个合同。

Gemini API 才是官方程序化接入路径。只要你的应用需要调用 generateContent、发送提示词或输入图片、接收 inline image 输出，或者控制宽高比和图像尺寸，这就是答案。

Google AI Studio 是围绕同一技术栈的官方测试与开发界面。它非常适合在真正写代码前先试提示词、看模型行为、观察返回结果。Google 在 2026 年 2 月 26 日发布 Nano Banana 2 的官方博客里，还明确点出一个很多文章都没写清的事实：在 Google AI Studio 里使用 Nano Banana 2，需要 paid API key。 这意味着 AI Studio 是官方开发者 UI，而不是绕开 preview 图像定价的免费入口。

Gemini Apps 和 AI Mode 当然都是真实产品，但它们属于消费端路径，不是 API 问题的直接答案。Gemini Apps Help 会区分 Nano Banana 与 Nano Banana Pro 在日常使用和高级输出上的分工；AI Mode Help 也会单独列图片创建限制，以及 Pro 在信息图/图表上的特殊定位。这些信息在你作为用户做选择时很重要，但它们 不会改变官方 API 合同是什么。

Wrapper 和 gateway 是另外一层基础设施选择。如果你的目标非常明确，比如 OpenAI 兼容调用、多模型统一账单、多厂商路由或支付层替代，它们当然可能有价值。但那是第二层判断，不是第一层。只要某个页面一上来就把 gateway 写成 Nano Banana 的定义，它给你的起点就已经错了。

最简洁的路由规则就是：

• 你要写代码，用 Gemini API
• 你要先在官方界面试提示词，用 AI Studio
• 你根本不是在问 API，而是在找消费端入口，用 Gemini Apps 或 AI Mode
• 你只有在能明确说出基础设施理由时，才该用 gateway

默认先用 Nano Banana 2，除非你能说清楚为什么要覆盖到 Pro

这是这篇文章里最值得提前替你做掉的判断。

Google 当前的 image generation docs 把 Nano Banana 2 描述为 Pro 的高效率对应层，适合速度和高吞吐的开发者使用场景。Google 自己在 2026 年 2 月的 rollout 博文里甚至直接把 Nano Banana 2 称为 “our best image generation and editing model”。对一篇 API 指南来说，这意味着你不该因为“Pro 听起来更高级”就把它当成自动默认值。

更适合先用 Nano Banana 2 的情况：

• 你正在做第一版集成
• 你更看重迭代速度和价格效率
• 你预期会有明显吞吐量
• 你想用一个最稳妥的默认模型覆盖大多数图像生成和编辑任务
• 你还说不出一个明确的 Pro 级理由

更适合切到 Nano Banana Pro 的情况：

• 文字渲染质量是结果成败的核心
• 图片本身是最终资产，而不是过渡草稿
• 你需要模型在复杂视觉指令上做更强的推理
• 任务高度依赖图表、排版结构，或对品牌级精度非常敏感

而 Nano Banana（gemini-2.5-flash-image）仍然有自己的位置：

• 你已经有工作负载围绕这条旧快路径调好
• 你确实想要低延迟，而不是 Nano Banana 2 的默认行为

真正重要的细节是：这不是一个简单的“画质梯子”。它是一个 工作负载匹配 问题。Nano Banana 2 不是 Pro 的“廉价版”，而是 Google 现在官方叙事里的主流默认 API 起点。Pro 是更高成本的 override。这个判断规则，比很多 wrapper 页面上那种含糊的“想要更好画质就上 Pro”有用得多。

如果你在做完这层判断后，还想看更细的 workload 对比，可以继续读我们的 Nano Banana Pro vs Nano Banana 2 对比。这篇文章不做全面对比，它只负责帮你先走上正确起点。

Quickstart：让你的第一个请求跑起来

官方路径实际上比很多第三方教程写得更短。

1. 先拿到 Gemini API key

去 Google AI Studio 创建 key 即可。Google 让 key 的创建本身很容易，但这不应该被误读成“当前图像输出是免费合同”。按照当前 preview 图像模型的定价页，正确理解应该是：

• 创建 key 这一步很容易
• 当前 preview 图像模型本身是付费 API 路线

2. 安装当前官方 SDK

Google 当前 libraries 页面推荐的是 Google GenAI SDK，而不是更早的旧版 Gemini 客户端库。

bash

npm install @google/genai

# Python
pip install -U google-genai

如果你看到还在用 google-generativeai 的老示例，请把它当成历史代码，而不是现在最优路径。

3. 发出最小可用图像请求

对于新集成，先用 Nano Banana 2：

javascript
import { GoogleGenAI } from "@google/genai";
import fs from "node:fs";

const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

const response = await ai.models.generateContent({
  model: "gemini-3.1-flash-image-preview",
  contents: "Create a clean editorial illustration of a robot sketching a website wireframe.",
  config: {
    responseModalities: ["IMAGE"],
    imageConfig: {
      aspectRatio: "16:9",
      imageSize: "2K",
    },
  },
});

for (const part of response.candidates[0].content.parts) {
  if (part.inlineData) {
    fs.writeFileSync("output.png", Buffer.from(part.inlineData.data, "base64"));
  }
}

Python 版本的逻辑完全一致：

python
import os
from google import genai
from google.genai import types

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])

response = client.models.generate_content(
    model="gemini-3.1-flash-image-preview",
    contents="Create a clean editorial illustration of a robot sketching a website wireframe.",
    config=types.GenerateContentConfig(
        response_modalities=["IMAGE"],
        image_config=types.ImageConfig(
            aspect_ratio="16:9",
            image_size="2K",
        ),
    ),
)

for part in response.parts:
    if part.inline_data is not None:
        part.as_image().save("output.png")

如果你想直接验证原始 HTTP 形状，官方 REST 请求也很短：

bash
curl -X POST \
  "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.1-flash-image-preview:generateContent" \
  -H "x-goog-api-key: ${GEMINI_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{
      "parts": [
        {"text": "Create a clean editorial illustration of a robot sketching a website wireframe."}
      ]
    }],
    "generationConfig": {
      "responseModalities": ["IMAGE"],
      "imageConfig": {
        "aspectRatio": "16:9",
        "imageSize": "2K"
      }
    }
  }'

切到 Pro 的方式其实非常无聊，这反而是好事：保留同样的请求形状，把 model 改成 gemini-3-pro-image-preview 就够了。也正因为如此，“先上 Nano Banana 2，确定有理由再升到 Pro” 才是最实用的工作流。你不用为了测试上位层就重写整套集成。

在你围绕 wrapper 设计系统之前，官方 API 里有哪些关键能力

官方 Gemini 路线值得先被当作基线，不只是因为它“更官方”，还因为它本身已经比很多 gateway 落地页写得更完整。

图像编辑是原生能力。 当前 image-generation docs 展示的是 text-and-image-to-image 工作流，而不是只支持 prompt 生图。如果你的产品要做编辑，而不是单次出图，这一点很关键。

宽高比和图像尺寸可以显式控制。 官方 API 支持 imageConfig.aspectRatio。对当前 preview 图像模型，Google 也明确给出了从 0.5K 到 4K 的图像尺寸文档。这意味着你可以在自己产品里明确管理成本和延迟，不用被迫让所有请求都走同一尺寸。

搜索 grounding 已经在官方栈里。 image-generation docs 现在展示了把 google_search 工具接到图像生成上的方式。这对图表、天气可视化、需要当前事实支撑的信息图尤其有价值。当然，这也不是“免费魔法”。Google 的定价页把 search grounding 当成单独的计费层，超过共享免费额度后会产生额外费用。

SynthID 已经由平台处理。 如果你的产品要处理 AI 溯源、标记或合规呈现，这件事比很多 gateway 页承认的重要得多。Google 明确写到，所有生成图片都包含 SynthID 水印。

如果你先通过 wrapper 页面认识 Nano Banana，这些能力很容易被盖过去。但它们才是你决定“官方路线上限够不够高”的关键。

价格与免费边界：最容易被写混的一段

大多数关于 Nano Banana API 的错误信息，都是在这里开始跑偏的。

当前 Gemini Developer API 定价页 对两个 preview 图像模型都明确标着 Free Tier: Not available。截至 2026 年 3 月 29 日，官方付费价格如下：

只要你记住这张表，很多排名页就会立刻暴露出它们在混合同：

• 免费创建 key
• AI Studio 的试用语言
• Gemini 或 AI Mode 的消费端额度
• 更早期或不相关的 free tier 叙事

这些根本不是一回事。

消费端 surface 自己当然有规则。Gemini Apps Help 当前列出的 Nano Banana 2 图片生成与编辑额度是 20 / 50 / 100 / 1000 images / day，分别对应无套餐 / Google AI Plus / Google AI Pro / Google AI Ultra。AI Mode Help 也给出了同样的 20 / 50 / 100 / 1000 images in a 24-hour period 结构，并且明确写到 AI Mode 里的 Nano Banana Pro 为信息图和图表做了优化。这些事实在你以用户身份选择入口时有价值，但它们 不会把当前 preview 图像 API 变成免费 API。

如果你的真实问题是“Nano Banana API 到底多少钱”，那就继续读我们的 Nano Banana 2 API 定价指南 和 Gemini 3 Pro Image API 定价指南。这篇文章优先解决的是路由与接入，不是完整价格建模。

30 秒内做决定

如果你只想要最小决策树，就记住下面几句：

要做新的官方集成，就用 Gemini API + Nano Banana 2。

只有当你能明确说出任务为什么更依赖文字渲染、画面保真或专业资产质量时，才切到 Nano Banana Pro。

想先在 Google 自己的界面里试提示词，就用 AI Studio。

如果你真正要解决的是消费端使用，不是在问 API，那就去 Gemini Apps 或 AI Mode。

如果你需要 wrapper，请先说清楚基础设施理由，比如 OpenAI 兼容调用或多厂商统一计费。不要让 wrapper 反过来定义产品本身。

这就是当前这个关键词最干净、最可执行的答案。

常见问题

官方 Nano Banana API 到底是什么？
它对应的是 Gemini 的原生图像生成家族，通过 Gemini API 和 Google AI Studio 暴露出来，而不是一个独立的 Nano Banana 开发者产品。

我应该先用哪个模型？
先从 gemini-3.1-flash-image-preview 开始，除非你一开始就知道自己需要更高阶的 Pro 层。

Nano Banana Pro 的官方 model ID 是什么？
gemini-3-pro-image-preview。

Nano Banana API 是免费的吗？
按照当前价格页，preview 图像模型本身不提供 free tier 图像输出。消费端产品额度和 AI Mode 使用上限是另外的合同。

我该用 AI Studio 还是 Gemini API？
两者一起用最合理：AI Studio 用来做官方提示词验证，Gemini API 用来接到你的应用里。

AI Mode 算 API 的一部分吗？
不算。AI Mode 是 Search 里的消费端 surface，有自己的图像限制和产品行为。

API 支持图像编辑，不只是 text-to-image 吗？
支持。Google 的 image-generation 文档里已经有官方的图生图工作流。

生成图片会带水印吗？
会。Google 说明所有生成图片都包含 SynthID 水印。

如果我需要 gateway 额外提供的东西怎么办？
按现在的能力范围看，官方 Gemini API 已经覆盖了多数团队真正需要的高价值控制项：模型选择、图像编辑、宽高比、图像尺寸和搜索 grounding。只有在这些还不够时，gateway 才应该被当成明确的基础设施选择，而不是默认起点。