必须用 + 显式声明格式链， 仅作最终兜底，否则高清图在旧浏览器或 MIME 错配时直接空白；因 AVIF/WebP 为可选支持格式，仅现代浏览器原生支持，单写 遇不支持环境会静默留空。
必须用 <picture></picture> + <source type></source> 显式声明格式链，<img alt="HTML怎么为高清图片做降级" > 仅作最终兜底，否则高清图在旧浏览器或 MIME 错配时直接空白
为什么单写 <img src="x.avif" alt="HTML怎么为高清图片做降级" > 不行
AVIF 和 WebP 是“可选支持”格式，不是所有浏览器都认。Chrome 85+、Safari 16.4+ 才原生支持 AVIF；Firefox 直到 115+ 才稳定支持。只写 <img src="a.avif" alt="HTML怎么为高清图片做降级" >，遇到不支持的环境（比如微信 iOS 旧版 WebView、企业内网 IE11 兼容模式），浏览器既不加载，也不报错，更不会 fallback —— 页面就留一个空框。
-
<picture></picture>是 HTML5 原生协商机制，按顺序检查<source></source>，第一个type匹配且资源可加载的就用它 -
<img alt="HTML怎么为高清图片做降级" >必须存在、带有效src（推荐 JPG）、非空alt，它是语义底线，也是 IE11 等环境唯一能渲染的部分 - 漏掉
<img alt="HTML怎么为高清图片做降级" >或把它写在<source></source>前面，降级逻辑就断了
<source></source> 的 type 和顺序怎么写才生效
浏览器不看文件后缀，只认 HTTP 响应头里的 Content-Type。你写 type="image/avif"，但服务器返回 Content-Type: image/jpeg，这个 <source></source> 就会被静默跳过。
- 顺序必须从现代到兼容：
<source type="image/avif"></source>→<source type="image/webp"></source>→<img src="fallback.jpg" alt="HTML怎么为高清图片做降级" > - 每个
<source></source>必须显式带type，不能只靠srcset推断 - 验证方式：DevTools → Network → 点开 AVIF 请求 → 查
Response Headers中的Content-Type是否精确等于image/avif
srcset 和 sizes 配错等于没写高清图
只写 srcset="a-800w.avif 800w, a-1200w.avif 1200w" 没用。浏览器不知道这张图在页面里占多宽，没法判断该选哪个。它会退回到默认估算（通常是 100vw），结果手机加载了 1200w 的 AVIF，浪费流量还拖慢首屏。
立即学习“前端免费学习笔记（深入）”；
-
sizes必须反映图片**实际渲染宽度**，例如：sizes="(max-width: 768px) 100vw, 50vw" -
srcset每项必须带w描述符（如800w），不能混用x（如2x），否则部分浏览器忽略整条<source></source> - 每个
<source></source>的srcset至少提供两个宽度选项，否则 Safari 可能跳过它
微信和旧 WebView 的特别坑点
微信 iOS 8.0.33 以前的 WebView 对 type 属性识别极差，常把 image/webp 当成未知类型直接跳过；部分安卓 WebView 则对 srcset 解析不完整。这时候纯靠 HTML 标签已不可靠。
- 路径必须用绝对路径（如
/img/a.avif），相对路径在嵌套路由下极易 404 - 避免依赖
media做格式切换，优先用type+ 顺序降级 - 开发阶段加全局 error 监听：
document.querySelectorAll('img').forEach(i => i.addEventListener('error', () => i.src = '/placeholder.jpg'))，快速暴露加载失败点
最易被忽略的是服务端 MIME 配置 —— HTML 写得再标准，只要 AVIF 文件返回 Content-Type: application/octet-stream，整个降级链就静默失效。别只盯着前端代码，先确认 Network 面板里每个图片请求的响应头是否干净。
