最可靠响应式图片策略是纯<img>配srcset和sizes；sizes写错会导致小屏加载大图，因浏览器解析HTML时依赖sizes预判宽度；混用w/x描述符会使srcset失效；懒加载需与srcset+sizes绑定而非单独用loading="lazy"。
纯 <img> 配合 srcset 和 sizes 就是当前最可靠、最轻量、也最被浏览器深度优化的响应式图片加载策略——所谓“新型”，往往只是对这套原生机制的理解偏差或误配导致的补救动作。
为什么 sizes 写错会让小屏加载 2MB 大图
浏览器在 HTML 解析阶段就发起图片请求，此时 CSS 还没生效，sizes 是它唯一能依赖的“这张图会占多宽”的线索。写错就等于给浏览器发了错误指令。
-
sizes="100vw"→ 不管容器实际只占 300px，浏览器都按视口全宽算，再乘以 DPR（比如 iPhone 13 是 3），结果选中 1920w 图 -
sizes="(max-width: 768px) 100vw, 50vw"→ 漏掉1200px+断点，桌面端 fallback 到默认 100vw，照样拉大图 -
sizes="30rem"→rem在sizes里无效，浏览器当空值处理，行为不可控
srcset 里混用 w 和 x 描述符会直接失效
同一 srcset 值中不能同时出现 400w 和 2x，部分浏览器（如 Safari）会整个忽略该属性，退回到仅加载 src 指定的图。
- 适配宽度变化（如不同断点布局）→ 只用
w描述符：photo-400.jpg 400w, photo-800.jpg 800w - 适配设备像素比（如 Retina 屏）→ 只用
x描述符：photo-1x.jpg 1x, photo-2x.jpg 2x - 二者都要？拆成
<picture>：用<source media>控宽度，每个srcset内只用x
懒加载必须和 srcset+sizes 绑定，不能单独用 loading="lazy"
loading="lazy" 只控制“什么时候发请求”，不参与“发哪个请求”。单独加它，移动端仍会下载桌面尺寸的图，只是晚 2 秒——流量没省，LCP 更差。
立即学习“前端免费学习笔记（深入）”；
- 正确姿势：
<img srcset="..." sizes="..." loading="lazy" src="fallback.jpg" alt="..."> - 画廊等复杂场景慎用原生 lazy：滚动时视口变化快，
loading="lazy"不感知 DPR 变化，也不重选srcset，易重复加载或错配 - 真要精细控制，用
IntersectionObserver+ 手动读devicePixelRatio+ 匹配data-srcset中最适宽度
<picture> 不是“高级 <img>”，只在两类场景不可替代
日常分辨率适配，<img> 更轻、更易维护、预加载更准。<picture> 是为明确语义需求设计的：
- 艺术方向裁剪（art direction）：竖屏用竖图，横屏用横图，构图完全不同
- 格式强制降级：优先
image/avif→ 不支持则image/webp→ 最后image/jpeg，且<source type>顺序不能错 -
<img>必须放在<picture>最末尾，且带src和alt，否则不渲染
真正难的不是写对标签，而是让 sizes 的每个条件，都和你真实 CSS 媒体查询中的容器宽度逻辑严丝合缝——漏一个断点，错一张图；差一个单位，浪费几百 KB。
