WebP、PNG、JPG 都要交时，怎样避免从低清副本反复转格式？

同一张图要给网页、设计文件和上传系统使用时，常常会同时要 WebP、PNG、JPG。真正容易翻车的不是格式按钮，而是上游关系：先把原图压成 JPG，再拿 JPG 转 WebP，最后从 WebP 另存 PNG，三份文件看似同源，实际已经共享了前一轮的损失。

更稳的做法是建立“一份母版、多个分支”。母版负责保存已经确认的内容、尺寸和构图；每个交付分支只做自己必须的格式或容量处理，不把任何交付版反过来当母版。

先写清三种格式各自服务谁

分支	适合的交付条件	需要提前确认的边界
WebP	接收方明确支持 WebP 的网页或系统	不能把“浏览器能打开”当成所有软件都能导入
PNG	需要透明或希望保留无损像素	文件可能更大，不能假定有统一质量旋钮
JPG	明确只接收 JPG 的普通照片场景	不保留透明，底色必须先确认

这是分支决策表，不是第三方平台兼容清单。接收说明没有写清楚时，用实际入口做一张小样验证，不要用网上的“通用格式”替代。

母版是唯一上游

母版至少要完成三件事：像素和构图已经确认，文字和主体内容已经确认，文件能够再次打开。保留原始文件，再另存一份用于导出的工作母版；不要把一个已经压过的 JPG 改名为“MASTER”。

可以按这样的关系管理：

位置	示例	版本规则
“source/”	“product-master.psd” 或确认过的原图	只读保存
“exports/web/”	“product-web.webp”	只服务网页分支
“exports/transparent/”	“product-transparent.png”	只服务透明分支
“exports/upload/”	“product-upload.jpg”	只服务上传分支

某个系统退回时，只回到母版重导对应分支。已经通过的另外两份不跟着改名或覆盖，这样每一次变化都有明确的上游。

三条分支分别编码，不要串行转码

WebP 分支

从母版直接导出 WebP，记录实际宽高、文件大小和是否保留透明。不要把“同画质下通常更小”写成某个平台的必然结果；接收方是否支持仍需单独验证。

PNG 分支

需要透明时从母版直接导出 PNG，并在浅色、深色背景上各看一次边缘。PNG 是无损格式，容量过大时不能靠改后缀解决；若接收方允许 WebP，重新从母版生成 WebP 分支，而不是把 PNG 先压成 JPG 再转回来。

JPG 分支

JPG 没有透明通道。母版有透明区域时，要先由交付负责人确认底色，再生成 JPG。图叮的图片格式转换与压缩可输出 JPG、PNG、WebP 或 AVIF，也可按目标大小处理；它只负责当前编码分支，不负责替你判断接收系统的兼容性。使用容量模式后，仍要复核实际尺寸，因为为了达到限额可能会得到不同宽高。

每个分支都做同一轮验收

三份文件不必追求字节完全相同，但每份都要能回答五个问题：

1. 宽高和构图是否符合这条分支的用途；
2. 文字、细线、边缘和渐变在实际显示大小下是否可接受；
3. PNG 或 WebP 的透明需求是否真的保留；
4. JPG 的底色是否已经由负责人确认；
5. 目标入口是否能打开、导入或上传这份真实附件。

记录表可写成“分支 / 来源母版 / 输出格式 / 宽高 / 字节数 / 透明 / 接收结果 / 检查时间”。不要只保存一个“最终版”，否则下一位处理人无法知道它属于哪个入口。

拿错上游时，先回退

现象	不要做什么	正确动作
JPG 已经压糊，还要 WebP	不要 JPG→WebP→JPG 继续试	回母版直接导出 WebP
JPG 铺错底色，还要透明	不要从 JPG 抠回透明	回透明母版或原始源
PNG 太大	不要改后缀或反复另存	先确认接收方是否接受 WebP/JPG
某分支上传失败	不要顺手替换其他分支	只针对失败入口重验格式和容量

如果想了解动图 WebP 只显示一帧时该如何区分查看器和文件本身，可参考WebP 动图打开后只有一帧？先分清查看器、预览和格式转换；遇到转 JPG 后颜色变化，再看WebP 转 JPG 后颜色变灰或偏色？先分清预览器、透明底和色彩配置。

分支导出不能让不支持的系统突然支持某种格式，却能让每份文件的来源、损失和用途都可追溯。母版不覆盖、分支不串行、附件逐份验收，才是多格式交付的完整链路。