<picture> 必须包含 <img> 作为最后一个直接子元素，因其不渲染内容且 <source> 仅为条件匹配，无匹配时若无 <img> 则空白；<img> 需带 src 和 alt，且宽高或 aspect-ratio 不可省。
为什么不能只写 <picture> 而不放 <img>
因为 <picture> 本身不渲染任何内容，它只是个“调度容器”；所有 <source> 都是可选条件，一旦都不匹配，页面就会一片空白——除非你提供一个兜底的 <img>。这个 <img> 不是可有可无的补充，而是强制必需的最后一个子元素。
常见错误现象：写了多个 <source>，但小屏或旧浏览器下图片完全不显示；检查 DOM 发现 <picture> 内部没有 <img>，或者把它写在了 <source> 前面（顺序错）。
-
<img>必须是<picture>的**直接子元素**，且必须在所有<source>之后 -
<img>仍需带src和alt，这两个属性不会被<source>继承 - 即使你用
type="image/webp"兜住了现代浏览器，也要为 Safari 13 以下、IE 等不支持<picture>的环境留好退路
<source> 的 media 与 srcset 怎么配才不白写
浏览器按顺序读取 <source>，遇到第一个满足 media 条件的就停止，并加载其 srcset 指定的资源。如果 media 写得过宽或顺序颠倒，后面更精确的规则就永远没机会执行。
例如：media="(min-width: 768px)" 放在 media="(min-width: 1200px)" 前面，那么 1440px 屏幕也会命中 768px 规则，加载中等尺寸图而非大图。
立即学习“前端免费学习笔记（深入）”；
- 把最具体的条件（如
(min-width: 1200px)）放在前面，最宽泛的（如(max-width: 767px)）放后面 -
srcset里可以写单个文件（photo.webp），也可以写多分辨率版本（photo-480w.webp 480w, photo-800w.webp 800w），但注意：此时sizes属性要同步加在<source>上，否则浏览器无法判断视口内该占多宽 - 不写
media的<source>是“无条件触发”，会直接覆盖后续所有规则，慎用
格式降级时，type 属性和文件实际 MIME 类型必须一致
浏览器靠 type 属性决定是否支持某格式，但它**不校验文件内容**。如果你写 type="image/webp"，但服务器返回的响应头是 Content-Type: image/jpeg，部分浏览器（尤其是旧版 Chrome）会直接跳过这个 <source>，哪怕文件本身能解码。
典型表现：本地双击 HTML 能看到 WebP 图，但部署到 Nginx/Apache 后始终 fallback 到 JPEG；查 Network 面板发现 WebP 请求返回 404 或 MIME 不匹配。
- 确认 Web 服务器已配置 WebP 的 MIME 类型（Nginx 加
types { image/webp webp; }，Apache 加AddType image/webp .webp） -
<source>的type值必须严格匹配标准写法：image/webp、image/avif、image/jpeg，不能写成webp或image/.webp - 用
curl -I your-image.webp检查响应头中的Content-Type是否正确
图片未设置宽高导致布局抖动，<img> 的 width/height 依然关键
<picture> 不改变 <img> 的渲染行为，它只是换了个方式指定图片源。所以当网络慢、图片还没加载完时，浏览器仍需要知道这块区域该预留多大空间——否则文字/卡片会突然下移，用户体验断裂。
很多人以为用了 srcset + sizes 就不用设尺寸了，其实不然：那些属性只帮浏览器选图，不告诉它“这张图该画多大”。
- 给内部的
<img>显式写上width和height属性（推荐用原始像素比，如width="1200" height="800"） - 或者用 CSS 的
aspect-ratio配合width: 100%，但注意 IE 不支持aspect-ratio，兜底仍需属性 - 别依赖
<source>的srcset自动推导尺寸——浏览器不会根据文件名里的-1200w去算宽高
最容易被忽略的一点：就算你把 <source> 写得再精准，只要 <img> 缺了 alt，整张图对屏幕阅读器就是不可见的；而缺了 src，连 fallback 都失效。这两个属性不是“优化项”，是语义与可用性的底线。
