OBS 图片处理 + CDN：WebP 自适应下发的三种做法

一、问题

桌宠素材是带 alpha 的整帧 PNG，单张 200~600 KB。Android 端直接显示没问题，但在弱网下首屏要等好几秒；换成 WebP 通常能小 40% 左右，还能保留透明通道。难点不在转码本身，而在“什么时候转、在哪里转、缓存怎么切”。

二、方案一：上传时预转码

最稳的做法是在上传流水线里同时产出 PNG 和 WebP，两套对象并存：

frames/
  frame-neutral.png
  frame-neutral.webp

优点是边缘节点只做静态分发，命中率高；缺点是存储翻倍，改质量参数要重跑一遍。适合素材版本稳定、更新不频繁的场景。

三、方案二：OBS 图片处理参数

OBS 支持在 GET 请求上带图片处理参数，按需输出指定格式和尺寸，不用预先存多份：

https://cdn.example.com/v3/frame-neutral.png?x-image-process=image/resize,w_384/format,webp/quality,q_85

客户端按屏幕密度拼不同宽度，服务端实时处理。注意两点：首次请求会回源处理，延迟比静态对象高；处理结果是否被 CDN 缓存，取决于 CDN 是否把 query string 纳入缓存键——不纳入的话，第二次请求可能拿到错误尺寸。

四、方案三：CDN 边缘自适应

让 CDN 根据 Accept 头自动选 WebP，客户端不用改 URL：

Vary: Accept

听起来最优雅，实际最容易翻车：缓存键里加了 Accept 之后，同一个 URL 会按浏览器头拆成多份缓存，命中率骤降；某些机型发的 Accept 顺序不同，还会被当成新变体。要在控制台确认 CDN 支持按 Vary 分流，否则会出现“有的手机拿到 PNG、有的拿到 WebP”的随机现象。

五、怎么选

素材量小、更新少：方案一，简单可控。素材多、尺寸组合多：方案二，用 query 明确表达意图，别依赖隐式协商。只有在 CDN 明确支持且缓存键配置正确时，才考虑方案三。

六、两个细节

第一，WebP 的 alpha 是有损的，边缘容易出现半透明脏边，质量参数不要低于 80；第二，给 format,webp 的响应加上 Content-Type: image/webp，否则部分 WebView 会按扩展名猜类型，直接不渲染。

七、小结

转码放在哪一层，本质是“把复杂度留给构建期还是请求期”。桌宠这种素材固定的产品，构建期多产一份 WebP 最省心；等素材规模上来，再把尺寸组合交给 OBS 图片处理，CDN 只负责缓存和回源。