必须用<picture>而非<img>的场景有三：一是根据视口切换不同构图（如桌面横幅、手机竖版特写）；二是按浏览器支持优先加载avif/webp并降级jpg；三是同时响应断点与格式，而<img>仅能处理同一构图下的分辨率适配。
什么时候必须用 <picture>，而不是只靠 <img>？
当你要根据屏幕尺寸切换不同构图的图片（比如桌面显示横幅全景、手机显示竖版特写），或者要按浏览器支持情况优先加载 avif / webp 但降级到 jpg，就必须用 <picture>。这些场景 <img> 做不到——它只能选分辨率，不能换内容或格式。
常见错误是把 <picture> 当成“高级 <img>”来滥用：比如只写一个 <source> 加一个 <img>，还自以为做了响应式。其实这纯属冗余，反而增加解析开销。
<img> 的 srcset + sizes 能解决什么？
它能解决「同一张图、不同分辨率」的加载问题，比如 hero-320w.jpg、hero-768w.jpg、hero-1200w.jpg。浏览器根据 sizes 描述的布局宽度 + 设备像素比，自动挑最匹配的 srcset 项加载。
关键点：
立即学习“前端免费学习笔记（深入）”；
-
sizes必须写真实布局宽度（如(max-width: 768px) 100vw, 50vw），不能写成固定像素值加单位（如500px）否则失效 -
srcset中的w单位是图片固有宽度，不是 CSS 宽度；漏写w或写成x会导致浏览器无法计算密度匹配 - 不支持
media查询或type格式声明——这些只能交给<picture>
<picture> 的 <source> 是怎么被选中的？
浏览器从上到下逐个检查 <source>，遇到第一个满足全部条件的就停，加载它的 srcset，不再往后看。顺序很重要。
容易踩的坑：
-
media和type可以同时存在，但只要任一条件不满足，整个<source>就被跳过 - 没写
<source>时，<img>是强制兜底；但写了<source>却没覆盖所有设备（比如漏了max-width: 480px），结果在小屏上可能加载错图甚至空白 -
<source>里不能写alt——这个属性只属于最后的<img>，否则校验失败
兼容性与性能实际影响有多大？
<picture> 在所有现代浏览器中都支持（Chrome 38+、Firefox 33+、Safari 9.1+、Edge 13+），IE 完全不支持。如果项目还需兼容 IE，必须配 JS 回退或直接放弃 <picture>。
性能方面：
-
<picture>解析成本略高于<img>，但差异可忽略；真正影响加载速度的是图片体积和 CDN 缓存策略 - 滥用
<source>（比如塞 10 个不同尺寸+格式组合）会拖慢 HTML 解析，建议控制在 3–4 个以内 -
loading="lazy"只对<img>有效，<picture>内部的<source>不响应该属性——懒加载逻辑得靠外层<img>承担
最常被忽略的一点：<picture> 不是“更优”的替代品，而是补足 <img> 力所不及的边界场景。多数静态图、头像、图标，用好 <img srcset> 就够了。强行套 <picture> 反而让代码变重、维护变难。
