结论：++三层结构配合srcset和sizes，是唯一能同时响应设备像素比、视口宽度与构图需求的可控方案；按media/type顺序匹配首个生效项，为强制兜底且必须含src和alt。
直接说结论：用 <picture></picture> + <source></source> + <img> 三层结构，配合 srcset 和 sizes，才是当前最可控、浏览器兼容性足够（Chrome 38+、Firefox 38+、Safari 9.1+、Edge 13+）、且能真正响应「设备像素比 + 视口宽度 + 网络条件」三重变量的方案。
为什么不能只靠 img[src] 或 img[srcset]？
单靠 src 完全无法响应；只用 srcset（无 sizes）时，浏览器按默认 100vw 计算，实际布局中图片常占视口一部分（比如 50% 宽），会导致加载远超需要的高清图，浪费带宽。更关键的是：srcset 只能切换分辨率（x 倍图），不能切换不同构图的图片（如桌面端横幅 vs 移动端竖版裁切图）——这必须靠 <source></source> 的 media 属性。
常见错误现象：
- 在 Flex/Grid 布局里用了
srcset却没写sizes，结果移动端加载了 2000px 宽的图 - 想为高 DPR 设备提供 2x 图，却把
2x写成2x.jpg（2x是描述符，不是文件名） - 用
media="(min-width: 768px)"匹配<source></source>，但 CSS 中该图片容器实际在 740px 就已变宽——媒体查询断点必须和真实布局断点严格一致
<picture></picture> 的正确嵌套顺序和 fallback 规则
浏览器从上到下解析 <source></source>，遇到第一个匹配 media 或 type 的就停止，加载其 srcset。最后一个 <img> 是强制 fallback，它没有闭合标签，且必须包含 src 和 alt —— 缺少 src 会导致整个结构不渲染，连 placeholder 都不显示。
实操建议：
- 把最常用、兼容性最好的格式（如
image/webp）放在前面，用type="image/webp"；后面跟type="image/jpeg"的<source></source>；最后是无type的<img> -
media查询优先级高于type，所以如果要「桌面 WebP + 移动 JPEG」，得拆成两个<source></source>，各自带media和type -
<img>的src不参与响应式选择，仅作降级；它的srcset和sizes会被忽略
<picture><source media="(min-width: 768px)" type="image/webp" srcset="hero-desktop.webp 1x, hero-desktop@2x.webp 2x"><source media="(min-width: 768px)" type="image/jpeg" srcset="hero-desktop.jpg 1x, hero-desktop@2x.jpg 2x"><source media="(max-width: 767px)" type="image/webp" srcset="hero-mobile.webp 1x, hero-mobile@2x.webp 2x"> @@##@@ </source></source></source></picture>
sizes 的值怎么写才不翻车？
sizes 不是 CSS 宽度，而是告诉浏览器「这张图在不同视口宽度下，预期会占用多少 CSS 像素宽」。它的值是一组逗号分隔的「媒体条件 + 宽度描述」，最后必须有一个无条件的默认宽度（如 100vw 或 50vw）。
典型陷阱：
- 写成
sizes="(min-width: 768px) 768px, 100vw"—— 错！768px 是固定像素，但实际布局可能用max-width: 768px或calc(100% - 2rem)，应换算成相对单位 - 在 Grid 中图片占
grid-column: span 2，但sizes还写100vw，导致浏览器误判尺寸 - 使用
clamp()响应式字体时，忘了sizes也得同步适配，比如sizes="(min-width: 1200px) 40vw, (min-width: 768px) 50vw, 90vw"
简单原则：打开 DevTools → 切换设备 → 看该 <img src="hero-fallback.jpg" alt="活动主图"> 元素的 computed width（CSS 像素值），把这个值直接填进对应断点的 sizes 项里。
现代方案要不要加 loading="lazy" 和 decoding="async"？
要，但有前提：loading="lazy" 对非首屏图片可减少初始加载压力，但若图片在视口内（比如 banner 图），加上反而可能触发额外重绘；decoding="async" 能避免解码阻塞主线程，对大图（>1MB）效果明显。
注意点：
-
loading="lazy"在 Safari 15.4+ 才支持<img>（旧版只支持<iframe></iframe>），iOS Safari 目前仍不支持 -
decoding="async"不影响渲染时机，只影响解码线程，无需搭配loading使用 - 不要给
<picture></picture>加这些属性，它们只作用于内部的<img>标签
复杂点在于：当图片同时受 IntersectionObserver 动态控制 + loading="lazy" + CSS contain: layout 影响时，懒加载行为可能出现竞态——这时候宁可手动用 JS 控制 src 注入，也不依赖原生 lazy。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
