浏览器按顺序匹配<source>，首个type可解码且media满足即加载；WebP未生效主因是MIME类型不匹配，如type缺image/前缀、服务器未返回Content-Type: image/webp或CDN未透传Accept: image/webp。
为什么 <source type="image/webp"> 写了却还是加载 JPEG
不是浏览器“不支持”，而是链路中某处 MIME 类型没对上。浏览器只认标准 type 字符串，且必须和服务器返回的 Content-Type 响应头完全一致。常见静默失败点：
-
type="webp"或type="image.webp"—— 缺image/前缀或用错分隔符，直接跳过该<source> - 服务器返回
Content-Type: text/plain或空，Nginx 未配置types { image/webp webp; } - CDN 没透传
Accept: image/webp请求头，后端无法判断客户端能力，统一返回 JPEG - DevTools Network 面板里看到请求状态是
blocked:mime-type或406 Not Acceptable，基本可定位到服务端配置问题
<picture> 中 <source> 的顺序为什么不能调换
浏览器从上到下逐个匹配 <source>，遇到第一个 type 可解码 + media 条件满足的就加载并停止。这不是“建议顺序”，是执行逻辑本身。
- AVIF 必须放最前：
<source type="image/avif">（Chrome 120+/Firefox 120+/iOS 16.4+） - WebP 居中：
<source type="image/webp">（覆盖 Safari 14+、绝大多数 Android WebView） - JPEG/PNG 不能写成第三个
<source>，必须放在<img src="xxx.jpg">的src里 —— 这是 IE 和旧 WebView 唯一能识别的部分 - 把
<source type="image/jpeg">放在 WebP 前面，哪怕设备支持 WebP，也永远加载不到
能否用 <img srcset> 替代 <picture> 实现 WebP 回退
不能。srcset 只按分辨率（w）或像素密度（x）选图，完全不识别格式。你写 srcset="a.avif 1x, a.webp 1x, a.jpg 1x"，浏览器会当成三个同尺寸 URL，随机挑一个发请求 —— 不支持 AVIF 的设备可能拿到 a.avif 然后报错或白屏。
-
<source type>是唯一由浏览器原生驱动的格式协商机制，无 JS、零延迟 -
<img>单标签兜底只适用于背景图（background-image: url(x.webp)）这类非语义化场景，且无降级能力 - 想让 WebP 在 CSS 里也回退？做不到。CSS 不支持
type或srcset，只能靠服务端内容协商（需后端配合）
fetchpriority="high" 和 loading="lazy" 该加在哪儿
fetchpriority 必须加在 <img> 上才生效，<source> 上加无效；loading="lazy" 同理，只作用于 <img>，对 <source> 完全无意义。
立即学习“前端免费学习笔记（深入）”；
- 首屏关键图（如 banner、logo）应在
<img>上加fetchpriority="high"，提升 LCP -
<img>是最终渲染载体，所有性能提示都得落在它身上 - 不要给
<source>加loading或decoding—— 浏览器忽略，还可能干扰解析 -
<img>的src必须是可直访的 JPEG/PNG，不能是带?format=webp这类动态参数的地址，否则 IE 或旧 WebView 会 404
最容易被忽略的是：所有 <source> 的 srcset 列表里，各格式图片的裁剪比例、宽高比、质量档位必须严格一致。否则响应式切换时，同一张图在不同尺寸下会拉伸、偏移或模糊 —— 这不是兼容性问题，是视觉一致性崩了。
