先分清两件完全不同的事
调用图像模型时，有两个「分辨率」，它们在请求里是互相独立的两个字段，不要混为一谈：
一句话：压缩的是「你喂进去的图」，分辨率参数控制的是「模型吐出来的图」。两者各管各的。
压缩质量还是压缩尺寸？先搞懂「压缩」压的是什么
「压缩」这个词经常被笼统使用，实际上图片有两个互相独立的「大小」，对应两种不同的压缩手段：
两者可以严重不成比例。一个真实例子（经验值，具体随编码实现变化）：
- iPhone 16 Pro 拍的一张照片，尺寸 4284×5712（约 2400 万像素，很大），文件体积却只有 4.6 MB——因为系统保存时已经做了高效率的有损编码；
- 同样像素的照片如果以高质量直出，体积可能接近 30 MB。
- 像素尺寸决定模型「看图」能获得的信息量上限，以及解码/理解的处理成本；
- 文件体积决定传输环节的成本：Base64 编码膨胀约 33%、上传耗时、单文件 20 MB 上限，冲着的都是体积。
输出分辨率由「尺寸参数」决定，不由提示词决定
这是最常见的误解，结论先行： 不同模型用不同的尺寸参数，常见的几类：以 gemini-3-pro-image 为例
它通过imageSize 档位控制输出分辨率，可选 1K / 2K / 4K（不传时默认 1K），同时用 aspectRatio 控制画幅比例：
imageSize 才是真正决定输出分辨率的字段。不同比例 + 档位对应的精确像素是固定映射，例如 1:1 在 1K/2K/4K 分别约为 1024×1024 / 2048×2048 / 4096×4096，16:9 约为 1376×768 / 2752×1536 / 5504×3072。
GPT 图像系列以 size 像素串控制
个别模型（如某些自适应出图的型号）不接受尺寸参数，输出分辨率由模型自行决定（通常约 1–1.5K）。这类模型即使想要 4K 也无法通过参数强制，更不可能靠提示词实现。以各模型文档/能力声明为准。
压缩输入图，会不会影响出图清晰度？基本不会
结论：对绝大多数场景，合理压缩输入参考图，几乎不影响输出图的清晰度。 原因有三：-
输出是「重新生成」的，不是把你的图放大。
模型按你指定的尺寸参数新画一张，输出分辨率只看
imageSize/size，跟输入图原本多少像素无关。输入图 3000px 还是压到 2000px，你选 4K 出来就是 4K。 - 输入图压缩字段与输出尺寸字段彼此独立。 压缩只改变请求里「图片数据」那个字段的体积/像素，完全不碰尺寸参数字段。两者在请求里没有任何关联。
- 推荐的压缩力度本就很轻，远高于模型「看图」所需。 实践中把参考图最长边压到约 2048px、JPEG 质量 0.9 左右，对模型理解构图、配色、风格、主体细节已经绰绰有余——这些模型内部本就会把输入图缩到不高的分辨率再编码理解。
严谨地说一句「边界」
在图生图 / 精细编辑（要求严格保留输入图某块区域的微小纹理、细小文字）这类任务里，如果把输入图压得过狠（例如长边压到几百像素、质量压到 0.5 以下），理论上可能丢失一些细节，间接影响编辑结果对原图的还原度。 但只要遵循「长边 ≤ 2048px、质量 ≥ 0.85」这类温和标准，这种影响在实际使用中可忽略。所以更准确的表述是：合理压缩（长边 2048px、质量 0.9）→ 对输出清晰度无可感知影响； 只有极端过度压缩才可能在精细编辑场景里造成细节损失。
输入图压缩的实践经验
如果你也要在调用前压缩输入图，建议采用以下温和标准，既省带宽又不损失有效信息：
多图自适应思路：
单张目标体积 = clamp(总预算 ÷ 张数, 0.3MB, 1.5MB)。张数越多、每张分摊越小，保证合计可控；已达标的图原样通过、不二次压缩。
生成图用于下游工作流：同样建议先处理
API 产出的图片往往比想象中大。以 Nano Banana Pro 的 4K 档位为例（实测经验值，具体随渠道编码实现变化）：
同为 4K 档位，不同渠道的编码实现不同，体积可以差一倍。
如果要把产出图作为下一环节的输入（再编辑、多图合成、当参考图），按输入图的同一标准先压缩再传（长边 2048px、质量 0.9）。否则一张 18 MB 的图经 Base64 膨胀约 33% 后约 24 MB，很容易触顶请求体/单文件限制，还拖慢上传。Base64 膨胀细节见 Nano Banana 系列开发指南。
如果产出图只用于展示/存档、不回传模型，可考虑 Nano Banana OSS 分组：图片以 URL 形式输出，省去 Base64 传输压力。
更多图片处理最佳实践
除了压缩，以下几件事在 API 调用场景同样建议在上传前做好：- EXIF 方向先「烘焙」进像素：手机照片的横竖方向常常存在 EXIF Orientation 标记里，而不是像素本身。部分处理链路会忽略这个标记，导致模型看到横竖颠倒的图。上传前先把旋转应用到像素上（多数压缩库在重编码时会自动完成）。
- 上传前剥离 EXIF 隐私信息：原图 EXIF 常包含 GPS 经纬度、设备型号、拍摄时间等敏感信息。把用户照片发给第三方 API 前建议剥离元数据——重编码压缩通常会顺带完成这一步，但注意顺序：先应用方向、再剥离。
- 格式兼容：iPhone 默认的 HEIC/HEIF 格式多数图像 API 不支持，上传前先转 JPEG/PNG；带透明通道的图用 PNG/WebP；GIF 动图通常只有首帧会被读取。
- 色彩空间转 sRGB：苹果设备照片常用 Display P3 色彩空间，部分处理链路不识别色彩描述文件会产生色偏，建议上传前转成 sRGB。
- 传输方式按场景选：输入侧 Base64 最稳，URL（
fileUri）上传对图床/CDN 要求高，取舍见 Nano Banana 系列开发指南；输出侧不想处理 Base64 可用 Nano Banana OSS 分组 直接拿 URL。 - 按需选择输出档位：不需要 4K 交付就别请求 4K——生成更慢、体积更大、下游传输和处理成本更高。中间迭代用 1K/2K，确认满意后终稿再上 4K。
- URL 输出及时转存：以 URL 形式返回的图片链接有时效，拿到后及时转存到自有存储，不要把临时 URL 当永久资源引用。
速查总结
- 输出分辨率 = 尺寸参数（
imageSize/size/aspect_ratio），不是 prompt 里的文字。想要 4K，请设参数，别写在提示词里。 gemini-3-pro-image用imageSize，档位 1K / 2K / 4K（默认 1K）；GPT 图像系列用size像素串。- 输入图压缩 与 输出图分辨率 互不相干，是请求里两个独立字段。
- 像素尺寸和文件体积是两回事：压缩 = 先缩边（长边 2048px）再降质（0.9），是否处理看体积（大于 1.5MB 才压）。
- 合理压缩输入图（长边 2048px、质量 0.9）不影响输出清晰度；只有极端过度压缩才可能在精细编辑里掉细节。
- 输入压缩推荐：大于 1.5MB 才压、长边 ≤2048px、质量 0.9、保持原格式、多图合计 ≤6MB、单文件 ≤20MB、失败回退原图。
- 生成图进下游工作流前也要先压缩：Nano Banana Pro 4K 单张约 9–18 MB（随渠道而异），直接回传很容易触顶限制。
- 上传前处理好 EXIF 与格式：方向烘焙进像素、剥离 GPS 等隐私元数据、HEIC 转 JPEG、Display P3 转 sRGB。