<picture> 不负责智能分发，真正实现格式协商的是 CDN 基于 Accept 请求头的动态响应；应使用统一路径（如 /images/hero.jpg）配合 CDN 配置，而非硬编码多格式 URL，以提升缓存命中率并支持灰度切换。
<picture> 本身不和 CDN “配合”——它只负责声明格式优先级，真正做智能分发的是 CDN 的边缘规则或源站配置。直接写 <source srcset="https://cdn.example.com/hero.avif"> 这类硬编码 URL，等于把格式决策权交给了 HTML，CDN 只是被动吐文件，完全没发挥智能作用。
为什么不能直接在 srcset 里写死 CDN 的 AVIF/WebP 地址
常见错误是开发者手动为每种格式生成三套 URL，然后一股脑塞进 <source>：
<picture> <source type="image/avif" srcset="https://cdn.example.com/hero-800.avif 800w, https://cdn.example.com/hero-1200.avif 1200w"> <source type="image/webp" srcset="https://cdn.example.com/hero-800.webp 800w, https://cdn.example.com/hero-1200.webp 1200w"> <img src="https://cdn.example.com/hero-800.jpg" alt="Hero" width="800" height="450"> </picture>
这会导致几个实际问题：
- 构建时必须预生成所有格式+尺寸组合，图片数量爆炸（n×m）
- CDN 缓存键变成
/hero-800.avif、/hero-800.webp等多个独立路径，缓存命中率低 - 客户端网络条件（如 Save-Data）或设备能力（如不支持 AVIF）无法被服务端感知，浏览器只能按
type硬选 - 后续想切格式策略（比如降级 WebP→JPEG），要全量重发 HTML，无法灰度
真正的智能分发：用单一 URL + CDN 请求头协商
现代 CDN（Cloudflare、Fastly、阿里云全站加速等）支持基于 Accept 请求头自动重写响应内容。你只需暴露一个逻辑路径，让 CDN 动态决定返回什么格式：
立即学习“前端免费学习笔记（深入）”；
- HTML 中只写一个语义化路径：
srcset="/images/hero.jpg"（注意不是完整 URL，留出 CDN 覆盖空间） - CDN 配置规则：当请求头含
Accept: image/avif且设备支持时，内部重写为/images/hero.avif并返回对应文件 - 同理，
Accept: image/webp→ 返回.webp；都不匹配 → 返回原.jpg -
<picture>退化为仅提供type声明和降级兜底，不再承担“多 URL 列表”职责
示例精简写法：
<picture> <source type="image/avif" srcset="/images/hero.jpg"> <source type="image/webp" srcset="/images/hero.jpg"> <img src="/images/hero.jpg" alt="Hero" width="800" height="450"> </picture>
关键点：srcset 值相同，但 CDN 根据请求头动态响应不同二进制内容 —— 浏览器仍走标准 <source> 匹配流程，只是底层资源由 CDN 实时协商生成。
CDN 配置必须打开的开关
若你控制 CDN 配置，以下几项漏掉一个，智能分发就失效：
- 开启
Vary: Accept响应头 —— 否则 CDN 会把 AVIF 响应缓存并错发给只接受 JPEG 的旧浏览器 - 确保源站能正确响应
Accept头（比如 Nginx 的map $http_accept $img_ext+try_files） - 禁用
gzip_vary on（尤其在大促场景）——Vary: Accept, Accept-Encoding会让缓存分裂成指数级变体 - CDN 回源时必须透传
Accept头，不能被中间层（如 Node.js 中间件）过滤或覆盖
最易被忽略的一点：CDN 的 AVIF 支持不是开箱即用的。Cloudflare 需要开启「Image Resizing」并勾选 AVIF；阿里云全站加速要单独开通「智能图像格式转换」功能，且只对 .jpg/.png 源图生效 —— 如果你上传的源图本身就是 .avif，CDN 就不会触发转换逻辑。
