Gemini 图片 API 集成到应用：Firebase AI Logic 还是服务端路由？

如果你的应用必须直接从移动端或 Web 客户端调用 Gemini 图片生成，优先用 Firebase AI Logic；如果你自己掌控可信服务端，并且需要更完整的图片控制能力，就把调用放到服务端 Gemini API。 这是当前最稳的默认答案，因为 Firebase AI Logic 本来就是面向客户端直连设计的，而更底层的 Gemini 图片 API 仍然提供了 Firebase 端暂时没有暴露出来的控制项。

这个路线判断，比第一段示例代码更重要。这个话题里最常见的错误，不是“语法写错”，而是安全边界选错。移动端 App 或浏览器前端都不应该直接暴露原始 Gemini API key。Firebase 的当前入门文档在 2026 年 3 月 23 日 复核时，仍然明确写着不要把 Gemini API key 放进应用代码，并且建议尽早加上 App Check。也就是说，只要你真的是客户端直连场景，默认就应该先考虑 Firebase AI Logic，而不是先把 provider key 塞进前端再说。

还有一个必须放在开头说明的 caveat。Firebase 的图片生成文档同样在 2026 年 3 月 23 日 复核时，明确把 Firebase AI Logic 里的 Gemini 图片生成标成 Preview，同时说明 Gemini 图片模型需要 Blaze 计费方案，并且当前还不支持显式设置 aspect_ratio 和 image_size。如果你的产品对输出尺寸、比例、审计链路或服务端策略有更强要求，那么更合适的路线就是把图片调用放在你自己的服务端。

要点速览

• 移动端或 Web 客户端必须直接调 Gemini 图片时，先用 Firebase AI Logic。
• 如果你掌控可信服务端，并且需要 aspectRatio、imageSize 这类显式控制，就走服务端 Gemini API。
• 不要把原始 Gemini API key 放进 App 或前端代码。
• 大多数新项目默认从 gemini-3.1-flash-image-preview 开始；只有文字很多、失败成本更高的图片任务，才考虑 gemini-3-pro-image-preview。
• Firebase AI Logic 里的 Gemini 图片生成当前仍是 Preview，并且需要 Blaze。
• 上线前一定要把 App Check、每用户限流和成本上限一起考虑进去。

如果你还没把 App、AI Studio、API 三个入口分清楚，可以先看Gemini 图片生成教程：App、AI Studio 和 API。如果你现在更关心的是代码形状而不是架构选择，可以直接看Gemini 图片生成代码示例。如果下一步主要是预算和单价判断，则更适合看Gemini 图片生成价格指南。

先选对 Gemini 图片集成路线，再写代码

这个关键词的搜索结果容易让人混淆，因为它把三个本质不同的问题混到了一起。Firebase 文档在回答“怎么从应用里调用 Gemini”；Gemini 图片文档在回答“底层图片 API 到底支持什么”；Android 文档则更多是在讲移动端接入视角。如果你没有先建立一个路线判断规则，就很容易把这些页面看成彼此矛盾，实际上它们各自只覆盖了一部分答案。

最实用的规则其实很简单：如果这个功能必须由客户端直接触发并直接调用模型，用 Firebase AI Logic；如果你的后端可以安全接管请求，并且你更在意控制力，就把图片生成放在服务端。 这个判断比你用 Next.js、Android、Flutter 还是别的框架更重要。

Firebase AI Logic 的优势，在于它就是为移动端和 Web 应用的直连能力设计的。它把 App Check、安全网关和 Firebase 生态放在同一个故事里，很适合做“在聊天里直接生成图片”“在用户上传的照片上直接做编辑”这类前台交互型功能。

服务端路线的优势，则在于你不必把模型调用暴露给客户端。只要你已经有 API 路由、worker 或后端服务，底层 Gemini API 就能让你更容易做请求校验、用户级配额、日志审计、提示词模板保护、输出尺寸统一控制，以及后续的存储和回溯。这些事情，在 demo 阶段看起来都不紧急，但一旦功能真的进入生产，它们反而会变成最先暴露的问题。

因此，这里真正要做的不是“二选一站队”，而是尽早决定哪条边界最符合你的产品。很多团队一开始用 Firebase AI Logic 快速验证功能，等功能跑通之后，再把图片生成逐步迁到服务端。这是合理的迭代路线。真正的问题，是从一开始就把两条路线当成完全一样的东西。

Firebase AI Logic 是移动端和 Web 直连的默认路线

Firebase 的总览文档其实已经把结论说得很直白：如果你需要从移动端或 Web 应用直接调用 Gemini，而不是从服务端调用，就用 Firebase AI Logic client SDK。这也是为什么，这篇文章会把它作为“接入应用”场景下的默认答案。

它的价值并不只是“写起来方便”。更关键的是安全边界。Firebase 的入门流程会先让你在项目里启用 Gemini Developer API、创建密钥，但同时又明确告诉你不要把这个 key 放进应用代码里，并且建议尽早接入 App Check。相比那些直接让你在浏览器里塞 provider key 的教程，这才是当前更安全、更负责任的默认路径。

下面是当前 Web 端最典型的 Firebase AI Logic 调用形状。代码沿用了 Firebase 官方示例的结构，但对于新项目，我们把旧示例里的 gemini-2.5-flash-image 换成了当前支持列表里更值得默认推荐的 gemini-3.1-flash-image-preview。

javascript
import { initializeApp } from "firebase/app";
import {
  getAI,
  getGenerativeModel,
  GoogleAIBackend,
  ResponseModality,
} from "firebase/ai";

const firebaseConfig = {
  // ...
};

const firebaseApp = initializeApp(firebaseConfig);
const ai = getAI(firebaseApp, { backend: new GoogleAIBackend() });

const model = getGenerativeModel(ai, {
  model: "gemini-3.1-flash-image-preview",
  generationConfig: {
    responseModalities: [ResponseModality.TEXT, ResponseModality.IMAGE],
  },
});

const prompt =
  "Create a clean onboarding illustration for a budgeting app. Use a calm blue palette and leave room for headline text.";

const result = await model.generateContent(prompt);
const imagePart = result.response.inlineDataParts()?.[0];

if (imagePart) {
  console.log(imagePart.inlineData.mimeType, imagePart.inlineData.data);
}

这里有两个要点必须记住。第一，Firebase AI Logic 当前的 Gemini 图片生成会返回文字和图片一起的响应，所以客户端要准备好处理两种内容。第二，因为 Firebase AI Logic 还不支持显式 aspect_ratio 和 image_size，所以你只能先在 prompt 里用自然语言去描述“留出标题空间”“竖版海报”“1:1 封面图”这类布局意图。能用，但也意味着它更适合做直连型产品功能，而不是做对输出规格要求很死的生产链路。

这个位置也必须把计费说清楚。Firebase 更广义的 Gemini onboarding 文案会让人以为“先免费试试问题不大”，但对这个具体用例来说，真正应该信的是更窄、更新的图片生成文档：Gemini 图片模型在 Firebase AI Logic 下当前需要 Blaze。所以最安全的说法不是“Gemini 接入应用免费”，也不是“一定很贵”，而是：一般性的 Gemini 接入可以先低成本启动，但图片生成这条线今天就是付费路线。

需要更强图片控制时，就改走可信服务端

如果你的产品本来就有后端，那么更底层的 Gemini API 很多时候才是更适合长期维护的形态。原因不是“后端更高级”，而是控制力。

Gemini 官方的图片生成文档已经明确提供 imageConfig，包括 aspectRatio 和 imageSize 这样的显式控制项。但 Firebase 的图片生成文档又明确说了，这些控制项在 Firebase AI Logic 里目前还没有直接暴露。对于很多产品来说，这一个差别就足够改变架构选择。只要你的业务需要稳定的 16:9 hero、1:1 商品图、9:16 内容流素材，或者要区分低成本和高质量输出档位，服务端路线就会明显更舒服。

更重要的是，服务端路线让你更容易把“图片生成”当成业务流程的一部分，而不只是一个 prompt 输入框。你可以做更严格的输入校验、用户级计费限制、敏感词或违规提示处理、存储与审计、团队后台工作流，甚至保护那些不想暴露给客户端的模板 prompt。这些事情一旦放进自己的后端，治理成本会低很多。

下面是一个当前很实用的 JavaScript 服务端调用形状。这个版本适合放在你自己的 API route 或 worker 里，用来拿到更稳定、更可控的图片输出。

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

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

export async function createMarketingImage(prompt) {
  const response = await ai.models.generateContent({
    model: "gemini-3.1-flash-image-preview",
    contents: prompt,
    config: {
      responseModalities: ["IMAGE"],
      imageConfig: {
        aspectRatio: "16:9",
        imageSize: "2K",
      },
    },
  });

  const imagePart = response.candidates?.[0]?.content?.parts?.find(
    (part) => part.inlineData
  );

  if (!imagePart?.inlineData) {
    throw new Error("No image returned from Gemini");
  }

  return {
    mimeType: imagePart.inlineData.mimeType,
    data: imagePart.inlineData.data,
  };
}

这条路线更适合做生产素材生成、管理后台创意工具、需要统一输出规格的功能，以及任何你希望把尺寸、比例、存储、日志和限流都稳稳掌握在自己手里的场景。如果你仍然喜欢 Firebase 生态，但又想把 AI 工作流收回服务端，Firebase 自己也在总览页里把 Genkit 作为服务端方向给出来。这可以作为一个清晰的思路：客户端直连看 Firebase AI Logic，复杂编排和后端治理看 Genkit 或你自己的服务端 API。

Web 应用里，Next.js 或 App Hosting 最关键的是边界，而不是框架名

对 Web 应用来说，问题往往不在于你用什么框架，而在于请求边界到底落在哪里。

如果用户真的需要在前端会话里直接生成或编辑图片，Firebase AI Logic 是最短、最安全的起点。你的前端通过 Firebase 网关发起请求，可以配合 App Check，也不需要把原始 provider key 暴露到浏览器里。这很适合内容创作工具、对话式图片功能、轻量编辑器等前台互动型能力。

如果这个功能更偏“业务处理”而不是“即时互动”，那就应该用自己的后端。无论是 Next.js route handler、Cloud Function 还是 App Hosting 后端，只要图片要落库、要规范化、要经过审计或计费控制，那么服务端路线都会更自然。

简单概括就是：

• 前端 Firebase AI Logic 路线：用户发起请求，客户端直接获得交互式结果；
• 后端 Gemini API 路线：客户端只请求你的后端，由后端统一决定模型、尺寸、比例、存储与限流策略。

很多团队真正的返工，不是因为模型效果不好，而是因为一开始没先想清楚这一层。

Android 场景里，Firebase AI Logic + App Check 最顺手

Android 是最容易自然接受 Firebase AI Logic 的平台，因为 Google 自己的文档就是这样组织的。对很多 Android 团队来说，这条路线看起来几乎像默认值。

Kotlin 代码形状也很直接。和 Web 端一样，真正要记住的不是只有 SDK 调用本身，而是：这段代码应该运行在一个已经接好 App Check、并且为 AI 功能单独考虑过配额的 Firebase 项目里。

kotlin
val model = Firebase.ai(backend = GenerativeBackend.googleAI()).generativeModel(
    modelName = "gemini-3.1-flash-image-preview",
    generationConfig = generationConfig {
        responseModalities = listOf(ResponseModality.TEXT, ResponseModality.IMAGE)
    }
)

val prompt = "Create a 1:1 travel sticker of Seoul at night in a bright flat illustration style."
val response = model.generateContent(prompt)

val image = response.candidates
    .first()
    .content
    .parts
    .filterIsInstance<ImagePart>()
    .firstOrNull()
    ?.image

对于真正的前台交互型功能，这就是很好的第一条 Android 路线。但团队在上线前仍然要有运营视角。Firebase AI Logic 的配额文档写得很清楚：Firebase AI Logic API 默认是每用户 100 RPM，而且 provider 侧的 Gemini 配额仍然优先生效。也就是说，一旦你的图片功能开始有真实流量，默认值很快就不够精细。你应该把每用户限制调到业务可承受的水平，而不是一直沿用默认设置。

如果 Android 端做的不是前台互动，而是后台素材生产、团队内部工具或高成本生成任务，那么服务端路线通常同样更合适。移动端文档会天然强化“客户端 SDK 就是默认答案”，但它只适合那些真的需要客户端直连的场景。

模型怎么选、什么时候该换路线

大多数新应用集成里，默认从 gemini-3.1-flash-image-preview 开始最稳。Google 的价格页和弃用页在 2026 年 3 月 23 日 的复核结果，都支持这个判断。Flash Image 是当前默认快车道，而 gemini-2.5-flash-image 已经变成带有明确退场日期的 legacy 路线，关闭日期写的是 2026 年 10 月 2 日。

gemini-3-pro-image-preview 只应该在产品结果真正需要它时再引入。最典型的情况，是海报、信息图、重文本图片，或者那种第一版做不好就会明显增加返工成本的高价值素材。如果你的任务只是“让用户在应用里快速生成一张图”，Flash Image 更像默认答案；如果你的任务是“让图片里的文字本身也很重要”，那 Pro 才更有必要进入默认流程。

编辑工作流也是路线可能变化的地方。Firebase AI Logic 很适合它当前支持的会话式编辑场景，但一旦你的流程开始依赖更多参考图、文件输入、复杂后处理，或者必须稳定控制输出规格，服务端路线就会更合适。Firebase 的FAQ也明确说了，Gemini Developer API 的 Files API 目前并不支持通过 Firebase AI Logic SDK 直接使用。这本身就是一个信号：更复杂的图片流程，应该留给后端。

所以，真正稳妥的路线不是一成不变的。前台交互型功能先上 Firebase AI Logic，等你需要更强控制、更完整工作流或更严格成本治理时，再切到服务端。这样做才符合这个功能在真实产品里的成长路径。

上线前，先把安全、配额和成本策略定下来

这一部分恰恰是当前搜索结果最容易轻描淡写带过的地方。

App Check 不是锦上添花，而是架构的一部分。 Firebase 当前的入门文档虽然允许你在非常早期先不接，但也明确说明，一旦应用开始对外分享，就应该尽早加上 App Check。如果你准备把直连式图片功能真正给用户用，这一步就不应该等到上线后再补。

Firebase AI Logic 有一层配额，Gemini 本身还有一层配额。 Firebase 的配额页写着 Firebase AI Logic API 默认是每用户 100 RPM，但 provider 侧限制仍然优先生效。Google 的rate limits 文档则说明 Gemini 的限制是按项目计算，而且 Preview 模型更严格。也就是说，一个应用出现 429，不一定只有一种原因：可能是 Firebase 网关层，也可能是底层 Gemini 提供方限制。

价格必须转化成模型策略，而不是只写在注脚里。 Google 的价格页在 2026 年 3 月 23 日 复核时显示：gemini-3.1-flash-image-preview 大约是 0.5K 每张 $0.045、1K 每张 $0.067、2K 每张 $0.101、4K 每张 $0.151；而 gemini-3-pro-image-preview 大约是 1K 或 2K 每张 $0.134、4K 每张 $0.24。这些数字应该直接影响你的产品默认值。大多数应用都不应该默认把所有用户请求直接送去高成本路线。

Preview 状态会改变你的上线方式。 Firebase AI Logic 图片生成目前仍是 Preview，而 Google 也明确提示 Preview 模型的限制更紧。这不意味着你不能上线，而是意味着你要带着护栏上线：功能开关、用户级限额、清晰的失败提示、以及保守的默认尺寸策略。

实际操作上，这个功能的上线 checklist 至少应该包括：

• 打开 App Check
• 下调每用户 RPM 到业务可承受范围
• 设定一个默认模型和一个明确的高质量升级路线
• 记录模型选择、成功率和配额错误
• 提前决定图片只保存在客户端，还是也要进入服务端存储与审计

如果这些不提前做，真正先暴露的问题通常不会是 prompt，而是滥用、限流和成本。

FAQ

不用 Firebase，可以直接从前端调用 Gemini 图片生成吗？

不应该这样做。原始 Gemini API key 不应该进入前端或移动端代码。如果这个功能真的需要客户端直连，就用 Firebase AI Logic；如果不需要直连，就把调用放到你自己的服务端。

Firebase AI Logic 现在支持显式 imageSize 和 aspectRatio 吗？

截至 2026 年 3 月 23 日，还不支持显式设置。Firebase 当前的图片生成文档明确说这些能力还没开放，所以只要你的功能强依赖输出尺寸和比例控制，服务端 Gemini API 就会更合适。

在 Firebase AI Logic 里做 Gemini 图片生成，需要付费吗？

需要。Firebase 当前的 Gemini 图片生成文档写得很明确：Gemini 图片模型需要 Blaze 计费方案。这才是这个具体用例下最应该参考的答案。

容易导致返工的几个错误

第一个错误，是把原始 Gemini API key 放进客户端。Firebase 当前文档已经明确不建议这么做。如果某篇教程还在这么写，那篇教程就已经不符合当前这个主题的质量线了。

第二个错误，是把 Firebase AI Logic 和底层 Gemini API 当成同一套控制面。它们不是。Firebase 当前图片文档已经说了，显式 aspect_ratio 和 image_size 还没有暴露出来；而底层 Gemini 图片 API 文档已经有这些控制项。如果你的产品离不开精确输出规格，就应该更早决定走服务端。

第三个错误，是把泛化的 Gemini onboarding 文案理解成“Firebase 图片生成是免费的”。这太宽了。针对这个具体问题，真正应该信的是更窄、更新的图片生成文档，而它明确要求 Blaze。

第四个错误，是把旧的 gemini-2.5-flash-image 示例当成今天新项目的默认起点。Firebase 某些代码块里仍然能看到这个模型，但支持列表和 Google 的弃用页已经足够清楚：新项目默认应该先从 gemini-3.1-flash-image-preview 开始，除非你有明确理由走 legacy 路线。

第五个错误，是把配额问题当成以后再考虑的事。Firebase 的配额页和 Gemini 的 rate-limit 文档都已经说明，图片能力在代码“看起来没问题”的情况下，仍然会因为项目级或用户级限制而出错。正因为如此，配额规划应该属于建设阶段，而不是上线后补锅阶段。

如果你接下来卡在的是实现细节，可以继续看Gemini 图片生成代码示例。如果你要解决的是图片编辑本身，可以看Gemini 图生图编辑指南。如果你已经遇到配额问题，Gemini API 限流说明会比再看一篇图片教程更有帮助。

最后的结论

“怎么把 Gemini 图片 API 接进应用”这个问题，今天最重要的答案不是某个 SDK 名字，而是先选对架构边界。

当功能必须由移动端或 Web 客户端直接触发时，用 Firebase AI Logic；当你的团队掌控可信服务端，并且更需要显式图片控制、可观测性和成本治理时，改走服务端 Gemini API。模型上，大多数新项目默认从 gemini-3.1-flash-image-preview 开始，只有在图片质量和文本表现真的会影响业务结果时，才升级到 gemini-3-pro-image-preview；而 gemini-2.5-flash-image 应该被看成 legacy 路线，而不是未来默认值。

当前 page one 最大的问题，就是没有把这套判断一次讲透。只要你先把路线选对，后面的接入、调优和上线，都会轻松得多，也便宜得多。