上个月产品经理跑过来说，用户反馈有些手机上商品图不显示，全是裂图。我第一反应是 CDN 挂了，查了一圈没问题。后来发现是运营上传了一批 WebP 格式的图片，而部分老款 Android 机和 iOS 14 以下的 Safari 根本不支持 WebP。图片存了，用户看不见，等于没存。

WebP 确实是好东西——同样画质下体积只有 JPEG 的 60% 左右，做图片多的业务能省下一大笔带宽。但兼容性这个坑，处理不好就是事故。

今天聊聊怎么既能吃到 WebP 的红利，又不让老用户看到一屏裂图。

WebP 为什么好，又为什么烦

先看一组实测数据。同一张 1920×1080 的照片：

原始 PNG：  2.1MB
JPEG 85%：  420KB
WebP 85%：  260KB   ← 比 JPEG 小 38%
AVIF 85%：  180KB   ← 更小，但兼容性更差

同样的视觉效果，WebP 能省将近一半的带宽。如果你的业务每天有 100 万次图片请求，平均每张 300KB，换成 WebP 后每张 180KB，一天能省 120GB 的流量。

但问题在哪？Can I Use 上 WebP 的支持率大约 97%。听起来很高对不对？但反过来想——每 100 个用户里就有 3 个看不到图，如果你的日活是 100 万，那就是 3 万人看到裂图。业务能接受吗？

而且这个 3% 不是均匀分布的。老款手机、旧版系统、某些嵌入式浏览器，WebP 支持率在这些设备上可能掉到 80% 以下。

思路：服务端判断，客户端不操心

不要让前端去判断"我的浏览器能不能显示 WebP"。浏览器种类太多、版本太杂，前端判断不过来。

正确的做法是：服务端根据请求头判断，自动返回浏览器能解码的格式。

HTTP 协议本身就提供了一套机制——Accept 请求头。浏览器在请求图片时会告诉你自己能接受哪些格式：

# Chrome 的 Accept 头：
Accept: image/webp,image/avif,image/apng,image/*,*/*

# Safari 13 的 Accept 头（不支持 WebP）：
Accept: image/png,image/svg+xml,image/*;q=0.8,*/*

看到了吗？Chrome 会说"我要 WebP"，Safari 13 不提 WebP。服务端只要读这个头，就知道该返回什么格式。

方案设计：三层降级策略

基于 Accept 头的判断，做一个三层降级链：

用户请求图片
  │
  ├─ 检查 Accept 头是否包含 image/webp
  │    ├─ 是 → 返回 WebP 版本
  │    └─ 否 → 继续检查
  │
  ├─ Accept 头是否包含 image/avif
  │    ├─ 是 → 返回 AVIF 版本
  │    └─ 否 → 继续降级
  │
  └─ 都没有 → 返回 JPEG（兜底）

伪代码大概这样：

function getImageFormat(acceptHeader):
    if acceptHeader contains "image/avif":
        return "avif"
    if acceptHeader contains "image/webp":
        return "webp"
    return "jpeg"

但这个判断有个容易被忽略的场景：用户把图片 URL 直接复制到地址栏打开。这时候浏览器发的 Accept 头是 text/html,application/xhtml+xml,...，不会有 image/webp。如果你按上面的逻辑会降级到 JPEG，但其实打开它的浏览器可能支持 WebP。

怎么处理？加一个降级开关：URL 后面带上 ?format=webp 参数时强制返回 WebP，不走 Accept 判断。平常的 <img> 标签请求走 Accept 逻辑，直接访问 URL 由前端显式指定格式。

上传时预生成多格式，不要请求时实时转

有人会在图片请求的瞬间用 ImageMagick 转格式。千万别这么干。

图片转码是 CPU 密集型操作，一张 2000×2000 的图转 WebP 可能要 100ms。如果并发 100 个请求同时触发转码，服务直接打满。

正确的做法：上传的时候一次性生成所有格式，请求的时候直接取对应文件。

用户上传 original.jpg
  │
  ├─ 生成 original_webp.webp    （质量 85%）
  ├─ 生成 original_avif.avif    （质量 85%）
  └─ 生成 original_jpeg.jpg     （质量 85%，兜底）

然后 CDN 或者 Nginx 根据 Accept 头路由到对应文件，应用层甚至不用参与。

存储成本确实会增加——同一张图存三份。但考虑到图片转码的 CPU 开销远大于多存两份文件的成本，这个 trade-off 是划算的。而且如果真的对存储敏感，可以只保留原始图 + WebP，JPEG 兜底版用时效更短的缓存策略。

智能画质调整：不是所有图都需要 85% 的质量

固定质量值是最简单的做法——比如所有图一律 85%。但不同的图对压缩的容忍度不一样：

• 纯色背景的 Banner 图：质量 60% 肉眼也看不出区别
• 细节丰富的照片：质量 80% 以下就能看到噪点
• 带文字的截图：压缩太狠字体会糊

所以"智能"意味着根据图片内容动态选择压缩参数，而不是一刀切。

一个实用但不过度复杂的方案——按场景分档，而不是去分析图片内容：

PNG 图片：
    包含透明通道 → 保持 PNG，不做格式转换
    不包含透明通道 → 转 JPEG/WebP

普通照片：
    尺寸 ≤ 2000px → 质量 80%
    尺寸 > 2000px → 先缩到 1920px，再质量 80%

Banner / 头图：
    规定尺寸 → 质量 70%（纯色区域多，压缩率高）

长图 / 截图：
    如果高度 > 宽度 × 3 → 质量 85%（保证文字清晰）

这个逻辑不复杂，但在实际业务中效果很明显。

进一步的话，可以做结构相似度（SSIM）判断：压缩后跟原图对比，如果 SSIM 低于 0.95 就适当提高质量参数。但这个就属于进阶优化了，大多数场景用场景分档就够了。

完整的上传 → 存储 → 分发链路

把上面的内容串起来：

==================== 上传阶段 =====================

用户上传图片 → 服务端

1. 分析图片特征：
   - 原始格式（PNG / JPEG / GIF）
   - 是否有透明通道
   - 尺寸（宽 × 高）
   - 宽高比

2. 确定处理策略：
   - 有透明通道 → 保留 PNG
   - 纯色 Banner → JPEG 70% + WebP 70%
   - 普通照片 → JPEG 80% + WebP 80%
   - 长截图   → JPEG 85% + WebP 85%

3. 生成多版本：
   original_webp.webp
   original_jpeg.jpg
   original_thumb.webp（缩略图，质量 60%）


==================== 分发阶段 =====================

用户浏览器请求 https://cdn.example.com/img/abc123

Nginx / CDN 层：
   if Accept contains "image/webp":
       返回 abc123.webp
   else:
       返回 abc123.jpg

注意分发层用的是 Nginx 或者 CDN 的规则，不经过应用服务器。图片转码只发生在上传的那一次。

这里有个配置上的小技巧：CDN 的 Vary 响应头要加上 Accept：

Vary: Accept

这样 CDN 会为同一个 URL 根据不同的 Accept 头缓存不同的版本。否则 Chrome 用户第一次访问缓存了 WebP，Safari 用户第二次访问拿到缓存的 WebP 就会裂图。

几个实践的坑

GIF 动图不要转 WebP

GIF 的本质是多帧动画，转成 WebP 静态图只会保留第一帧，动图信息全丢。除非你专门转成 WebP 动画格式（Animated WebP），但那还不如保持原样。

判断方式很简单：读文件头，如果是 GIF 且帧数大于 1，直接保留原始文件。

注意 EXIF 方向信息

手机拍的照片通常带 EXIF 元数据，里面有一个 Orientation 字段标记拍摄方向。如果你压缩的时候不处理这个字段，竖着拍的照片压缩出来可能横着显示。

在转码前先读 EXIF，根据 Orientation 把图旋转到正确方向，然后再压缩。Java 里可以用 metadata-extractor 库来处理。

别忽视 SVG 和 WebP 的尺寸上限

WebP 格式最大支持 16383×16383 像素。如果有人上传了一张超大的长图（比如完整的网页截图），转 WebP 会失败。加一个尺寸上限检查，超限的图保持原格式或者用 JPEG。

总结

图片优化这件事，不是选一个最先进的格式就完事了。你的用户用什么设备你控制不了，但你能控制的是——在服务端做好兼容，让每个人看到的都是他能打开的、体积最小的版本。

核心就三点：

多格式预生成 —— 上传时一次转好，请求时直接取，不实时转码。

Accept 头自动降级 —— 浏览器说支持 WebP 就给 WebP，没说的老老实实给 JPEG，CDN 层配好 Vary: Accept。

场景分档压缩 —— Banner 和照片用不同的质量参数，不搞一刀切的 85%。

做完了这些，你的图片平均体积大概能降 40% 到 50%，关键是不会有用户来投诉"图挂了"。

有用的话转给还在直接让运营上传 5MB PNG 的前端。