关键在于type属性必须写标准mime类型且与服务器content-type一致，按avif→webp→jpeg顺序排列source，并强制设置带src和alt的img作为兜底。
关键不是写了 type，而是写对、排对、兜住。 浏览器不会“智能降级”，它只按顺序找第一个 <source></source>：type 声明支持 + 实际能解码 → 就用它；否则跳过，继续往下。没匹配上，最终靠 <img> 的 src 回退——这个兜底环节绝不能少，也不能错。
type 属性必须写标准 MIME 类型
浏览器靠 type 判断“该不该看这个 source”，不是靠文件后缀或内容嗅探。写错就等于告诉浏览器“这个我不要”，哪怕图片本身完全正确。
- ✅ 正确写法：
type="image/webp"、type="image/avif"、type="image/jpeg" - ❌ 错误写法：
type="webp"、type="image.webp"、type="image/jpg"（JPG 应为image/jpeg） - 服务器返回的 Content-Type 必须和 type 值一致，否则部分浏览器（如 Safari）会静默跳过，不触发 error，也不走降级
source 顺序决定加载优先级
浏览器从上到下逐条检查，遇到第一个 type 支持且资源可解码的就停止。顺序不是“谁先进来谁先用”，而是“谁最现代且设备能播谁先用”。
- 推荐顺序（兼顾效率与兼容）：
<source srcset="logo.avif" type="image/avif"></source><source srcset="logo.webp" type="image/webp"></source><source srcset="logo.jpg" type="image/jpeg"></source><img src="logo.jpg" alt="Logo"> - AVIF 放最前：Chrome 120+、Firefox 120+、Edge 120+ 已稳定支持，但旧 Safari 和部分 Android WebView 仍不支持，需靠后续 fallback
- WebP 放中间：覆盖绝大多数现代浏览器，包括 iOS 14+ Safari
- JPEG 放在最后一个
<source></source>：作为格式层面的“最后一道防线”，再往后就是<img>的 src
img 标签是强制兜底，不是可选项
<picture></picture> 本身不渲染、不请求，真正触发加载的是匹配成功的 <source></source> 或最终的 <img>。漏掉 <img>，整个结构就失效。
-
<img>必须带src和alt，否则语义缺失、无障碍失败、SEO 受损 - 即使你写了三个
<source></source>，只要浏览器一个都不认（比如全写成type="image/xxx"且服务器未配置 Accept 头透传），页面就会空白——除非<img>存在且可访问 - 不建议把
<img>的src指向 WebP 或 AVIF：它无法被旧浏览器识别，起不到降级作用
避开常见静默失败陷阱
很多“降级没生效”不是代码写错了，而是环境链路断了。
- CDN 或 Nginx 没透传
Accept请求头 → 后端无法根据Accept: image/avif,image/webp返回对应格式，导致 406 或返回 JPEG 却声明为type="image/avif"→ 浏览器直接跳过 - 移动端 Safari 对
image/avif完全不识别（iOS 16.4 才开始实验性支持），写了也白写；但image/webp在 iOS 14+ 是安全的 - 某些 Android WebView 声称支持 AVIF，实际解码崩溃 → 建议搭配
media="(min-width: 0px)"强制保底，或用canPlayType()主动探测（适合 JS 控制场景）
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
