统一规范必须从结构开始，因其是浏览器硬编码的唯一降级机制：须全在前，必须完整闭合且src指向200状态静态资源，缺一即静默空白。
为什么统一规范必须从 <picture></picture> 结构开始
浏览器对降级的执行逻辑是硬编码的：它只认 <picture></picture> 的顺序匹配规则，不支持任何自定义 fallback 语义。你写十个 <source></source> 却漏掉底部的 <img>，或者把 <img> 写成自闭合标签 <img>，整个结构在 IE11、微信旧版 WebView 或断网时就直接空白——不是报错，是静默失效。
统一规范的第一条铁律就是结构强制：<source></source> 必须全在 <img> 前；<img> 必须是完整闭合标签；src 和 alt 不可为空；src 必须指向一个 HTTP 200 的静态资源（如 /img/fallback-800x450.jpg），不能是占位符路径或带查询参数的动态地址。
sizes 和 srcset 配对错误会导致降级“形同虚设”
只写 srcset="a-400w.jpg 400w, a-800w.jpg 800w" 而不配 sizes，浏览器默认按 100vw 推算，结果手机加载 800w 图、桌面反而加载 400w 图——这不是降级，是反向浪费。
-
sizes必须反映图片在页面中的**实际渲染宽度**，不是容器宽度。例如横幅图在小屏占满视口、大屏占 50vw，就得写sizes="(max-width: 768px) 100vw, 50vw" -
srcset中每个值必须带w描述符，且数值应覆盖设备常见宽度（如320w、768w、1200w），不能只写2x/3x密度描述符 - 所有格式图（WebP/JPEG/AVIF）的原始像素尺寸必须完全一致，否则切换时会触发布局抖动（CLS）。用
file logo.webp和file logo.jpg命令验证输出是否都显示800 x 450
type 和服务器 Content-Type 不匹配等于没写
<source type="image/webp" srcset="a.webp"></source> 看似完整，但若 Nginx 没配 types { image/webp webp; }，或 CDN 返回头是 Content-Type: application/octet-stream，Chrome 和 Firefox 会直接跳过该 <source></source>，连网络请求都不发——用户看到 fallback JPG，你却查不到任何错误。
验证方式很简单：DevTools → Network → 点开 WebP 请求 → 查 Response Headers 中的 Content-Type 是否精确等于 image/webp。AVIF 同理，必须是 image/avif，不能是 image/jpeg 或空。
常见坑：
- 本地双击打开 HTML 文件（
file://协议）时，多数浏览器忽略type判断，直接走<img>—— 开发阶段必须用python3 -m http.server启服务测试 - 把
type="image/jpeg"放在type="image/webp"前面，浏览器匹配到第一个就停，WebP 根本没机会加载 - 微信 iOS WebView 对
type支持极差，建议横幅图禁用 WebP/AVIF，只用 JPG +media断点降级
降级后视觉跳变的根本原因不是 CSS，而是尺寸失控
WebP 加载失败回退到 JPG，页面文字上推、容器突然撑开——这不是 CSS 没写好，是浏览器在加载不同格式图时，依据各自的 intrinsic 尺寸（EXIF 宽高）重新计算盒模型。JPG 若被清空元数据，浏览器会认为“无尺寸”，导致塌陷后再撑开。
真正可控的解法只有两个：
- 统一所有格式图的原始像素尺寸，并保留 EXIF：
exiftool -ImageWidth=800 -ImageHeight=450 logo.jpg - 放弃依赖图片自身尺寸，用 CSS 强制锁定：
img { aspect-ratio: 16 / 9; width: 100%; height: auto; }，并确保父容器有明确宽高约束
别指望 alt 文字兜底——它只在图片有渲染高度时才可见；也别用 background-image 多层 url() 声明“模拟降级”，CSS 本身没有 fallback 机制，那只是部分浏览器的非标准行为。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
