<picture>是唯一零JS、不发额外请求、SEO友好、原生支持的WebP/AVIF降级方案；失效主因是type与Content-Type不匹配、顺序错误（AVIF→WebP→JPEG）、或缺失必需的<img src>兜底。
直接用 <picture>，别绕弯子——这是唯一零 JS、不发额外请求、SEO 友好、原生支持的方案。
为什么 <source type="image/webp"> 写了却还是加载 JPEG
不是浏览器“不支持 WebP”，而是链路中某处 MIME 类型没对上。浏览器只认标准 type 字符串，且必须和服务器返回的 Content-Type 响应头完全一致。
- 服务器返回
Content-Type: text/plain或空 → 浏览器静默跳过该<source> - Nginx 未配置
types { image/webp webp; }→ .webp 文件被当成application/octet-stream - CDN 没透传
Accept: image/webp请求头 → 后端无法判断客户端能力，统一返回 JPEG
<source> 的顺序为什么不能调换
浏览器从上到下逐个尝试 <source>，遇到第一个 type 可解码且 media 条件满足的就加载并停止。这不是“建议顺序”，是执行逻辑本身。
-
image/avif必须放最前：<source srcset="a.avif" type="image/avif"> -
image/webp居中：<source srcset="a.webp" type="image/webp"> - JPEG/PNG 回退必须放在
<img>的src属性里，不能写成第三个<source> - 把
<source type="image/jpeg">放在 WebP 前面，哪怕设备支持 WebP，也永远加载不到
<img> 的 src 是强制兜底，不是可选项
<picture> 本身不加载图片，真正触发加载的是内部匹配成功的 <source> 或必需的 <img>。没有 <img>，就不会渲染任何内容，也不会发请求。
立即学习“前端免费学习笔记（深入）”；
-
<img>不是“备用 source”，而是所有不支持type的老浏览器（如 IE、旧 Android WebView）唯一能识别的入口 -
<img src>不能是带查询参数的动态地址（如?format=webp），也不能是 404 路径；否则整个<picture>会退化为仅显示alt文本 - 首屏关键图应在
<img>上加fetchpriority="high"，提升 LCP；加在<source>上无效
路径写错导致降级失效的常见坑
所有格式图片必须尺寸一致、构图一致，否则响应式切换时会出现拉伸或视觉跳变；但更基础的问题是：路径一错，连兜底都进不去。
- 本地双击打开 HTML 时，
src="logo.png"可能失败，而src="./logo.png"更可靠 - 路径中所有斜杠必须是正斜杠
/，Windows 显示反斜杠\，但 HTML 里一律不用 -
../images/logo.jpg表示上一级目录里的images文件夹，注意..后必须跟/，写成..images/logo.jpg就错 - 绝对路径如
file:///C:/project/logo.jpg理论可行，但跨设备即失效，开发阶段禁用
最容易被忽略的是：所有格式的图片 URL 必须真实可访问，且服务端返回的 Content-Type 和 type 属性必须字面完全一致——少一个字母、多一个空格，降级就静默失效。
