概述
gemini-3-pro-image-preview(即 Nano Banana Pro)对内容安全有严格控制,会在多个层级拒绝不合规的请求。简单的「生成失败」提示无法帮助用户理解问题,一套好的错误处理需要做到:
- 精准识别拒绝原因 —— 区分内容违规、知识库限制、技术错误
- 友好的用户提示 —— 把技术错误转化为可理解的说明
- 可操作的建议 —— 告诉用户怎么改才能成功
- 完整的技术信息 —— 供开发者调试排查
当请求返回 HTTP 200 但没有图片 时,这通常是谷歌侧的安全判定。API易 透明代理只是如实转发结果——我们同样希望客户成功出图。判断与文案处理需要在你的应用侧完成。
谷歌内容审核政策(2026 更新)
谷歌的图片生成采用两层安全机制:- 可调节过滤器:覆盖骚扰、仇恨言论、露骨色情、危险内容等四类,可通过
safetySettings调整 - 内置保护:针对核心危害(如儿童安全)始终生效,无法通过参数关闭
- 生成式 AI 禁止使用政策:
policies.google.com/terms/generative-ai/use-policy - 生成式内容常见错误说明:
ai.google.dev/api/generate-content
三个核心判断指标
按优先级从高到低依次检查:1. candidatesTokenCount(最高优先级)⭐
- 位置:
response.usageMetadata.candidatesTokenCount - 含义:API 生成的候选内容 token 数
- 规则:等于
0表示在内容审核阶段就被直接拒绝,连候选内容都没生成,这是最严格的拒绝
2. finishReason(次优先级)
- 位置:
response.candidates[0].finishReason - 规则:不等于
STOP即为非正常结束,需要特殊处理
finishReason 取值(注意 Nano Banana 系列新增了 IMAGE_ 前缀的图片专用值):
3. 文本拒绝说明(重要)
- 位置:
response.candidates[0].content.parts[].text - 规则:
finishReason为STOP,但parts里只有text、没有图片数据时,说明 API 返回的是拒绝说明而非图片。文案可能是中文或英文,例如:
错误场景速查
处理流程(决策顺序)
代码实现(核心)
将上面的判断顺序整合为一个解析函数:C 端友好提示文案
设计原则:简洁明了、正面引导、可操作、避免指责。推荐模板:- C 端用户:默认只显示友好说明 + 修改建议
- B 端 / 工具服务商:默认展开技术详情(
finishReason、candidatesTokenCount等) - 开发者:提供「展开/收起」查看完整 JSON 响应
最佳实践
- 严格按优先级检测:
candidatesTokenCount→finishReason→parts→ 提取数据 → 关键词识别 - 先收集 text 再判断 thoughtSignature,避免拒绝说明丢失
- 保留完整响应:开发/测试工具务必保存原始 JSON,便于排查
- 支持中英文拒绝文案:谷歌可能返回中文或英文,关键词匹配两者都要覆盖
- 友好降级:能智能识别就给具体提示,否则直接展示 API 文本,再否则用
finishReason友好名称,最后才是通用提示 - 永不显示「未知错误」:始终带上可操作建议或完整响应
常见问题 FAQ
为什么同一个提示词有时能生成有时不能?
为什么同一个提示词有时能生成有时不能?
谷歌的安全过滤存在随机性和上下文相关性:参考图内容、提示词组合方式都会影响判断。建议调整描述方式、使用更委婉的表达。
如何区分是内容问题还是技术问题?
如何区分是内容问题还是技术问题?
candidatesTokenCount: 0 或 finishReason: PROHIBITED_CONTENT → 内容问题;Failed to fetch 或 HTTP 错误 → 技术问题;有 API 文本说明 → 通常是内容问题。C 端用户应该看到多少技术信息?
C 端用户应该看到多少技术信息?
分层展示:默认显示友好说明 + 修改建议;可选展开技术详情;开发模式下显示完整 JSON 响应。
是否需要为每个 finishReason 单独写处理?
是否需要为每个 finishReason 单独写处理?
不需要。用映射表 + 通用兜底即可:
reasonMessages[finishReason] || + 显示原始值。