<picture>不是可选优化项，而是不可绕过的决策节点；它解决艺术方向、格式降级和语义裁剪等<img>无法处理的内容适配问题，通过<source>顺序匹配与fallback机制精准控制加载结果。
什么时候必须用 而不是 ![HTML中picture标签在前端性能优化中的地位]()
当你的场景同时满足以下任一条件时，<img> 就已力不从心：
- 需要为移动端展示竖版特写图、桌面端展示横版全景图（即艺术方向控制）
- 想默认用
image/avif，降级到image/webp，再降级到image/jpeg，且要求浏览器按格式支持度自动跳过不识别的type - 同一张图在不同视口下需完全不同的裁剪逻辑（比如 banner 图：手机只保留人脸区域，桌面显示整栋建筑）
这些都不是“分辨率适配”问题，而是“内容语义适配”问题。<img> 的 srcset 只能告诉浏览器“哪个更清晰”，而 <picture> 的 <source> 能告诉浏览器“哪个才是对的”。
<source> 的匹配顺序和 fallback 机制怎么影响加载结果
浏览器从上到下逐个检查 <source>，遇到第一个 media 匹配且 type 受支持的就立即加载，不再继续；如果所有 <source> 都不满足，则加载 <img> 的 src。
- 顺序即优先级：把
type="image/avif"放最前，即使media="(min-width: 1200px)"也匹配，只要浏览器支持 AVIF 就不会去读后面的 WebP -
media不生效 ≠ 条件写错：如果<source>没写type，但当前浏览器不支持该图片格式（比如 Safari 16.4 之前不支持 AVIF），即使media匹配也会跳过 -
<img>必须存在：它是唯一渲染出口，也是所有不支持<picture>的旧浏览器（如 IE）的唯一入口
常见性能陷阱：你以为在优化，其实增加了请求或阻塞
以下写法看似合理，实则引入额外开销或兼容风险：
立即学习“前端免费学习笔记（深入）”；
- 多个
<source>都没写type，只靠media区分，但所有图片都是 JPEG —— 这和用<img srcset>效果一致，还多一层 DOM 结构 -
<source>的srcset里混用不同格式（如"a.avif 1x, b.jpg 2x"）—— 浏览器无法按像素比+格式双重判断，会退化为仅按srcset解析，失去格式降级能力 - 在
<picture>外层又套了loading="lazy"—— 无效，懒加载必须写在内部的<img>上 - 用 JavaScript 动态插入
<picture>，但未等document.readyState === 'interactive'就执行 —— 可能导致首屏图片被漏掉预加载时机
真正关键的点不在语法多复杂，而在于是否清楚每一张图的「内容意图」：是换尺寸？换格式？还是换画面？一旦混淆这三者，<picture> 就会从性能杠杆变成维护负担。
