通过 OpenAI 兼容接口给一把 key 发图片：base64 与 URL 两种传法在各后端的差异

为什么需要关注图片传入方式

在使用 OpenAI 兼容接口调用视觉模型时，图片通常有两种传入方式：base64 编码内联在请求中，或提供可访问的图片 URL。聚合站背后可能对接多个视觉后端，不同后端对这两种方式的支持程度、体积限制和 MIME 识别行为并不一致。如果不了解这些差异，可能会遇到图片被忽略、请求失败或响应质量下降等问题。

base64 内联传法

base64 方式将图片二进制编码为字符串，直接放在消息内容中。常见的消息格式如下：

{
  "role": "user",
  "content": [
    {"type": "text", "text": "描述这张图片"},
    {"type": "image_url", "image_url": {"url": "data:image/jpeg;base64,..."}}
  ]
}

体积上限差异

不同后端对 base64 字符串的长度限制不同。有些后端允许较大的图片（例如几 MB），而有些后端会严格限制请求体大小，超出时直接返回错误。由于聚合站会统一接收请求再转发，实际限制取决于目标后端。建议在客户端先压缩图片，并避免在单次请求中放入过多图片。

MIME 类型识别

base64 数据通常以 data:image/<type>;base64, 开头，用于声明 MIME 类型。部分后端会严格检查该声明，如果类型与实际内容不符（例如声明为 JPEG 但实际是 PNG），可能拒绝处理或解码失败。另一些后端则可能忽略声明，直接根据二进制内容推断。为了兼容性，建议确保 MIME 声明与实际图片格式一致。

远程 URL 传法

URL 方式将图片放在可公开访问的地址上，消息中直接传递链接：

{
  "role": "user",
  "content": [
    {"type": "text", "text": "描述这张图片"},
    {"type": "image_url", "image_url": {"url": "https://example.com/image.jpg"}}
  ]
}

可访问性与延迟

后端需要主动下载图片，因此 URL 必须可被后端服务器访问。如果图片需要认证或位于内网，后端可能无法获取，导致图片被忽略或请求失败。此外，下载过程会增加响应延迟，尤其是图片较大时。

体积与格式限制

通过 URL 传入时，后端通常有自己的下载大小限制。超出限制可能被截断或拒绝。与 base64 类似，不同后端对图片格式的支持也有差异，常见的 JPEG、PNG 一般被支持，但 WebP、GIF 等格式未必所有后端都能处理。

哪些后端可能悄悄丢掉图片

部分后端在遇到不支持的图片格式、无法访问的 URL 或过大的图片时，可能不会返回明确错误，而是直接忽略图片，仅用文本部分生成回复。这会导致用户误以为模型“没看到”图片。常见情形包括：

• URL 返回非 200 状态码或内容类型不是图片。
• base64 数据缺少正确的 MIME 前缀或前缀与内容不符。
• 图片体积超过后端隐式限制。
• 后端不支持消息中的多图或图文混合结构。

由于聚合站可能将请求路由到不同后端，同一请求在不同时间可能得到不同行为。建议在关键场景中检查响应是否引用了图片内容，或先用小图测试目标后端的实际表现。

实践建议

• 优先使用 base64 内联方式，避免 URL 可访问性问题，但注意压缩图片控制体积。
• 确保 base64 的 MIME 声明与实际格式一致。
• 如果使用 URL，确保链接公开可访问且返回正确的 Content-Type。
• 在请求中附加文本提示，明确要求模型基于图片回答，便于发现图片是否被忽略。
• 对于多图请求，控制图片数量和总体积，并测试目标后端的限制。
• 关注聚合站文档中关于视觉模型的支持说明，了解各后端的已知差异。