一篇来自图片处理项目的格式选择实践
同一张图在不同页面里，往往不是"能不能显示"的问题，而是"要不要保留透明、能不能接受有损压缩、访问端是否足够稳定"的问题。格式选错，常见结果是商品图边缘出现白底、截图文字变糊，或者网页加载变慢。本文结合我在图片猫项目中维护图片格式转换和导出流程时遇到的实际代码，把 JPG、PNG、WebP 的选择拆成一套可以落地的判断步骤。
先说明范围：下文的项目代码摘录来自当前前端实现，示例会标明"项目代码摘录""教学简化示例"或"建议方案"。文中没有把未做过的浏览器兼容性压测、文件体积对比或线上数据写成测试结论。
图 1 格式选择的第一层判断：先看透明度和目标场景（合成示意图）
一、先别看扩展名：真正要判断的是四件事
-
是否需要透明通道。JPG 没有 alpha 通道，透明区域只能被填成某种颜色；PNG 和 WebP 可以保存透明信息。
-
图像内容能否接受有损压缩。照片的连续色调通常能容忍一定压缩，文字、线稿、截图边缘则更容易暴露色块和毛边。
-
最终文件由谁读取。浏览器、旧版客户端、设计软件、打印链路对格式的支持范围不同；"网页能打开"不等于"所有下游都能打开"。
-
是否还会继续编辑。需要反复修改的原始素材，应保留原图或无损版本；把唯一原图先转成有损 JPG，后续每次导出都可能继续累积误差。
一个实用的顺序是：先排除不满足透明度的格式，再在剩余格式里比较体积与兼容性，最后才调质量参数。这样不会为了省几十 KB，把必须保留的透明边缘直接丢掉。
二、JPG、PNG、WebP 的取舍表
|------------|-----------|-----------------------------|-----------------------------|-----------------------------|
| 格式 | 透明度 | 压缩与体积 | 更适合 | 常见风险 |
| JPG / JPEG | 不支持 alpha | 有损压缩；照片通常体积可控 | 照片、没有透明背景的封面、需要广泛兼容的静态图 | 文字和锐利边缘容易出现块状伪影；透明区域会被填色 |
| PNG | 支持 alpha | 无损；截图、线稿和透明素材更稳，但照片可能偏大 | Logo、贴纸、界面截图、需要像素精确或透明背景的素材 | 文件可能较大；不适合把所有照片默认保存成 PNG |
| WebP | 支持 alpha | 支持有损和无损；网页场景通常能取得较好的体积/质量平衡 | 网页图片、缩略图、需要透明且希望控制体积的素材 | 历史软件或旧客户端可能不支持；下游链路需要准备回退方案 |
这张表是决策起点，不是固定排名。MDN 的格式指南也把照片、透明、精确复现和浏览器回退列为主要判断因素；Google 的 WebP 文档则明确说明 WebP 同时覆盖有损、无损和透明模式。链接放在文末，便于按目标浏览器和业务链路复核。
三、图片猫项目里，格式选择是怎样落到代码上的
在图片猫的批量格式转换页，当前实现允许选择 JPG、PNG、WebP，也接收 BMP、HEIC/HEIF；HEIC/HEIF 会先在浏览器本地预转换，再进入后续批量流程。设置区把质量参数限定为 JPG / WebP 使用，透明转 JPG 时另外提供填充颜色。这个设计把三个容易混淆的开关拆开了：目标格式、质量、透明区域处理方式。
普通上传入口仍复用 BaseImageUpload.vue，格式和 MIME 类型的归一化集中在 cosDirectUpload.ts。这样做的价值不在于"少写几行组件代码"，而在于不同工具不会各自发明一套扩展名判断，减少 `.jpg`、`.jpeg` 和 `image/jpeg` 互相不认的问题。
1）透明背景决定默认格式
证件照导出是一个很直观的例子：当前 IdPhoto.vue 会根据背景颜色是否为 transparent，决定输出 PNG 还是 JPEG；JPEG 才传入质量值。这是项目代码摘录，省略了 canvas 绘制和下载调用上下文：
项目代码摘录：webClientVue/src/components/IdPhoto.vue。只保留与格式决策直接相关的片段。
const format = bgColor.value === 'transparent' ? 'image/png' : 'image/jpeg';
const quality = format === 'image/png' ? undefined : 0.95;
canvas.toBlob(
(blob) => {
// 省略：更新结果尺寸、文件大小等状态
},
format,
quality
);
这里有一个容易被忽略的边界：PNG 的"无损"不代表文件一定更小，WebP 的"支持透明"也不代表任何软件都能继续编辑它。若输出要给打印、旧版办公软件或第三方接口使用，仍要按接收方的格式白名单验收。
2）照片和电商封面通常优先考虑 JPG 或 WebP
当前 EcommercePlatformCover.vue 的预览和导出都使用 JPEG，并设置了 0.95 / 0.92 的质量参数。原因不是 JPEG 永远最好，而是平台封面本身是有实色背景的照片型画面，透明通道没有收益，兼容性和可预测的导出结果更重要。若同一资源主要在网页中展示，可以再生成 WebP 版本；如果要给不支持 WebP 的下游系统，保留 JPEG 作为回退。
项目代码摘录：展示 JPEG 导出选择，省略了画布尺寸和错误处理上下文。
// 项目代码摘录：EcommercePlatformCover.vue
desktopPreviewUrl.value = canvas.toDataURL('image/jpeg', 0.95);
return new Promise((resolve) =>
canvas.toBlob((blob) => resolve(blob), 'image/jpeg', 0.92)
);
3）批量转换不只是改后缀名
BatchFormatConvert.vue 会先从 MIME 或文件名识别源格式，再根据目标格式生成结果文件名；相同格式默认跳过，用户也可以选择重新压缩。目标是把"改后缀"变成一次真正的重新编码，并在批量下载时按目标扩展名打包。教学上可以把决策逻辑缩成下面这样，但它不是项目可直接复制运行的完整实现：
教学简化示例：用于说明判断顺序，不代表项目内部函数名。
// 教学简化示例：真正的项目代码还要处理 File、Blob、错误和批量任务状态
function chooseFormat(hasAlpha, isPhoto, targetIsWeb) {
if (hasAlpha && !targetIsWeb) return 'png';
if (targetIsWeb) return 'webp';
return isPhoto ? 'jpg' : 'png';
}
这个顺序的关键是"目标约束优先"：有透明且接收方不接受 WebP 时选 PNG；明确是网页资源时优先考虑 WebP；其余照片再回到 JPG。实际项目还必须把尺寸、质量、透明填充色和失败重试纳入同一个任务状态。
四、一个真实案例：同一张风景图转换后，应该看什么
下面的配图来自项目现有的 image-format-convert 展示素材，左右是转换前后案例图的组合展示。它用于说明"转换任务有前后结果"，不是我在本文重新执行的一次性能测试，也不能据此宣称固定的压缩比例。判断转换是否合格时，我会同时看主体边缘、天空渐变、水面细节和文件属性，而不是只看肉眼缩略图。
图 2 项目格式转换展示案例素材组合图（Before / After），非本文现场测试截图
五、按使用场景给出更稳的选择
|--------------------|-----------------|-----------------------|------------------------------|
| 场景 | 首选 | 备选 / 回退 | 验收重点 |
| 网页中的照片、文章配图 | WebP（有损质量按内容调整） | JPG | 清晰度、首屏体积、目标浏览器是否需要回退 |
| 透明 Logo、贴纸、抠图结果 | PNG 或无损 WebP | PNG | 边缘 alpha、透明区域是否被填白、编辑软件能否打开 |
| 后台截图、流程图、文字密集图片 | PNG | 无损 WebP | 文字边缘、细线、放大后是否有彩边 |
| 电商平台封面或接口白名单只收 JPG | JPG | 按平台规则保留原图 | 背景是否实色、质量参数、尺寸和文件大小上限 |
| 需要长期留档、后续反复编辑 | 保留原始文件 | 另存 PNG / 无损 WebP 工作副本 | 不要只保存一次有损 JPEG；记录尺寸、色彩和元数据策略 |
如果业务同时面向网页和下载，建议把"源文件"和"交付文件"分层：源文件保留可编辑或无损版本，交付层按浏览器、平台和文件大小生成 JPG / PNG / WebP。不要为了省事让一个文件承担所有链路。
六、当前实现、尚未完善与建议方案要分开看
|--------------|------------------------------------------------------------------------------------------|-------------------------------------------|
| 状态 | 在本项目中的具体内容 | 边界 |
| 当前已经实现 | 批量 JPG / PNG / WebP 互转；BMP、HEIC/HEIF 输入；JPG / WebP 质量设置；透明转 JPG 的填充色；同格式跳过或重压缩；批量结果 ZIP。 | 这些是代码和界面中已经存在的处理路径，不等同于每种输入都得到相同体积。 |
| 尚未完善 / 需外部验证 | 不同浏览器、设计软件、办公软件和第三方接口的 WebP 支持深度不完全相同；Canvas 重编码还可能影响色彩配置、元数据和细节。 | 当前文章没有做跨版本兼容矩阵、ICC 色彩对比或大批量性能压测，因此不下统一结论。 |
| 建议方案 | 在发布链路加入透明检测、目标 MIME 白名单、尺寸与体积阈值、关键区域视觉抽检；网页用 picture 提供 JPG / PNG 回退。 | 这是后续验收和架构建议，不要写成图片猫当前已全部具备的能力。 |
七、发布前的验收清单
-
透明素材：在白底、深色底和棋盘格背景各看一次，确认边缘没有被填白或出现黑边。
-
质量参数：照片重点看天空渐变、皮肤和水面；截图重点看文字、细线和图标，不要只凭文件大小判断。
-
兼容性：用实际接收方打开结果，检查 MIME、扩展名、尺寸、色彩和下载行为；网页资源准备必要的 JPG / PNG 回退。
-
链路安全：保留原图，避免重复有损转码；批量任务要验证同名文件、失败项、取消操作和 ZIP 内部目录。
-
记录边界：把已验证的浏览器和软件版本写进发布记录，把尚未验证的项目列成待验收项。
如果只记住一句话，可以记成：透明度决定能不能选 JPG，内容类型决定能不能接受有损，交付对象决定是否要回退，原始素材决定是否应该保留无损母版。格式选择是一个小决策，但它会影响上传校验、画布导出、CDN 体积和后续编辑整条链路。
参考资料
-
MDN：Image file type and format guide：Image file type and format guide - Media | MDN
-
Google Developers：WebP overview：https://developers.google.com/speed/webp
-
MDN：MIME types：Media types (MIME types) - HTTP | MDN
本文案例来自我正在维护的图片猫图片处理项目，演示入口：图片猫PicCat