<picture>的<source>顺序不能乱，因为浏览器从上到下匹配，遇到第一个type和media同时满足的<source>即加载并停止；若JPEG写在AVIF/WebP之前，支持新格式的浏览器也不会加载更优格式。
直接用 <picture> 是最稳妥、原生、零 JS 依赖的兼容方案，但必须按 AVIF → WebP → JPEG/PNG 顺序写 <source>，且所有格式的 srcset 和尺寸需严格对齐，否则会白屏或加载错误。
为什么 <picture> 的 <source> 顺序不能乱
浏览器从上到下逐个尝试 <source>，遇到第一个 type 匹配且媒体条件满足的就加载并停止。如果把 image/jpeg 放在前面，哪怕后面有 image/avif，AVIF-capable 浏览器也永远不会加载它。
常见错误现象：<source type="image/jpeg"> 写在最前 → 所有浏览器都只加载 JPEG，AVIF/WebP 彻底失效。
- AVIF 必须放第一个：
<source srcset="a.avif" type="image/avif"> - WebP 次之：
<source srcset="a.webp" type="image/webp"> - JPEG/PNG 回退必须放在
<img>的src属性里，不能写成第三个<source> - 所有
srcset值里的图片分辨率、质量档位、裁剪比例要一致，否则响应式切换时会出现拉伸或模糊
<img> 单标签能否支持 WebP/AVIF 自动降级
不能。单 <img src="x.jpg"> 只能加载一个 URL，浏览器不会主动替换格式。即使你用 CDN 动态转码（如 xxx.jpg?x-oss-process=image/format,avif），不支持 AVIF 的浏览器仍会收到 406 或损坏数据，导致图片不显示。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
使用场景：<img> 适合背景图（background-image: url(x.webp)）、图标、头像等无需艺术方向控制的静态资源 —— WebP 在 Chrome/Firefox/Safari 14+/Edge 全支持，足够稳；AVIF 则建议只用于首屏大图，且必须搭配 <picture>。
- 纯 CSS 背景图无法做格式回退，
background-image不识别type或srcset - 服务端内容协商（如 Nginx 的
$http_acceptmap）可实现单 URL 多格式，但需后端配合，前端不可控 - JS 特征检测（
canvas.toDataURL('image/avif')）可行，但增加请求延迟和代码复杂度，不如原生<picture>简洁
IE 和旧 Android WebView 怎么兜底
<picture> 在 IE 中完全不被识别，会忽略整个标签，只渲染内部的 <img> —— 这反而是优势：只要 <img src="x.jpg"> 存在，IE 就能显示 JPEG。但旧版 Android WebView（<picture> 出错，导致空白。
关键点：不要给 <img> 加 srcset 或 sizes，它只负责兜底，不是响应式主力。
- 确保
<img>的src是可直接访问的 JPEG 或 PNG，不能是带查询参数的动态地址（如?format=webp） - 避免在
<picture>外再包一层<div>做 fallback，IE 不解析<picture>时，DOM 结构可能错乱 - 若必须兼容 Android 4.4 WebView，加一行
<meta http-equiv="X-UA-Compatible" content="IE=edge">并测试渲染是否正常
最容易被忽略的是：所有 srcset 中的图片必须真实存在且 HTTP 状态为 200。浏览器不会因为某个 <source> 404 就跳到下一个 —— 它会卡住、报错，甚至阻塞后续资源加载。上线前务必用 curl 或 DevTools Network 面板验证每个 URL 是否可访问。
