是唯一零JS、不发额外请求、SEO友好、原生支持的WebP/AVIF降级方案；其生效依赖type与Content-Type严格匹配、AVIF→WebP→JPEG顺序、为静态JPEG/PNG兜底且不可省略。
<picture></picture> 是唯一能零 JS、不发额外请求、SEO 友好、原生支持的方案。别绕弯子，直接用它。
为什么 <picture></picture> 里 <source type="image/webp"></source> 不生效
不是浏览器“不支持”，而是链路中某处 MIME 类型没对上。浏览器只认标准 type 字符串，且必须和服务器返回的 Content-Type 响应头完全一致。
-
type="webp"或type="image.webp"—— 缺image/前缀或用错分隔符，直接跳过该<source></source> - Nginx 未配置
types { image/webp webp; }，导致返回Content-Type: text/plain或空 - CDN 没透传
Accept: image/webp请求头，后端无法判断客户端能力，统一返回 JPEG - DevTools Network 面板看到状态是
blocked:mime-type或406 Not Acceptable，基本可定位到服务端配置问题
<source></source> 的顺序为什么必须是 AVIF → WebP → JPEG
浏览器从上到下逐个尝试 <source></source>，遇到第一个 type 支持且媒体条件满足的就加载并停止。这不是“建议”，是执行逻辑本身。
-
<source srcset="a.avif" type="image/avif"></source>必须放最前：Chrome 120+、Firefox 120+ 已稳定支持，但旧 Safari 和部分 Android WebView 仍不支持，需靠后续 fallback -
<source srcset="a.webp" type="image/webp"></source>居中：覆盖 iOS 14+ Safari、Android 4.0+、几乎所有桌面浏览器 - JPEG/PNG 回退必须放在
<img alt="如何通过HTML实现图片格式兼容降级" >的src属性里，不能写成第三个<source></source>；否则 IE、旧 Android WebView 会空白 - 把
image/jpeg写在image/webp前面，哪怕设备支持 WebP，也永远加载不到
<img alt="如何通过HTML实现图片格式兼容降级" > 的 src 为什么不能带查询参数或动态地址
<img alt="如何通过HTML实现图片格式兼容降级" > 是所有不支持 type 的老浏览器（如 IE、旧 Android WebView）唯一能识别的入口。它必须指向一个静态、可直访、无需协商的 JPEG 或 PNG 地址。
立即学习“前端免费学习笔记（深入）”；
-
src="logo.jpg?format=webp"或src="logo.jpg?x-oss-process=image/format,avif"在不支持 WebP 的浏览器里可能触发406或返回损坏数据，导致图片不显示 -
src地址要能单独粘贴进浏览器地址栏并正常显示图片 - 漏掉
<img alt="如何通过HTML实现图片格式兼容降级" >，整个<picture></picture>就失效——<picture></picture>本身不渲染、不请求，真正触发加载的是匹配成功的<source></source>或最终的<img alt="如何通过HTML实现图片格式兼容降级" > -
<img alt="如何通过HTML实现图片格式兼容降级" >必须含src和alt，否则语义缺失、无障碍失败、SEO 受损
所有格式图片尺寸与构图必须一致
这是最容易被忽略的一点：如果 a.avif、a.webp、a.jpg 宽高不同、裁剪比例不同、甚至构图偏移，响应式切换时会出现拉伸、模糊或视觉跳变。
另外，fetchpriority="high" 要加在 <img alt="如何通过HTML实现图片格式兼容降级" > 上，不是 <source></source> —— 加在后者上无效；所有 srcset 值里的图片分辨率、质量档位、裁剪比例也要一致，否则响应式切换逻辑就乱了。
