picture标签本身不优化性能，它只是把选择权交给浏览器；media值必须严格符合css媒体查询语法（如“(max-width: 768px)”），sizes缺失或错误会导致浏览器默认按100vw选图，type与服务器content-type不一致将导致格式降级失败。
picture 标签本身不优化性能，它只是把选择权交给浏览器——你写错一个括号、漏掉 sizes、type 大小写不对，浏览器就直接跳过所有 source，只加载 <img> 的 fallback 图，白忙一场。
media 属性括号写错，整条 source 被忽略
浏览器对 media 值极其严格：必须带完整括号，且是 CSS 媒体查询语法。写成 media="max-width: 768px" ❌，必须是 media="(max-width: 768px)" ✅。
- Chrome DevTools 的 Network 面板里如果某张图完全没发请求，大概率是
media不合法，导致该source被静默跳过 - 多个断点别重叠，比如
(max-width: 768px)和(min-width: 768px)在 768px 宽度时行为未定义；推荐用开区间：(max-width: 767px)→(min-width: 768px)→(min-width: 1201px) - 不写
media的source会无条件参与匹配，但优先级低于带media的——容易干扰预期逻辑，慎用
sizes 属性缺失或写错单位，浏览器瞎下大图
没有 sizes，浏览器默认按 100vw 计算“这张图该用多宽的源”，哪怕它在 CSS 里只占 300px 宽，也可能拉一张 1920w 的图下来。
-
sizes必须是媒体条件 + 宽度单位组合，例如sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"✅；写成"100%"或"300px"❌ - 值要真实反映 CSS 布局：用
grid-template-columns: repeat(3, 1fr)？那大屏下图宽≈33vw，不是100vw - 用 DevTools → Elements → 查看 computed styles →
width，确认各断点下元素实际渲染宽度，再反推sizes值
type 与服务器 Content-Type 不一致，格式降级失败
写 type="image/webp"，但 Nginx 返回 text/plain 或 image/jpg（注意拼写、大小写、空格），Chrome 会标为 blocked:mime-type，直接跳过该 source。
- 用 curl 或 DevTools → Network → Response Headers 检查服务器实际返回的
Content-Type - WebP 优先、JPEG 降级的关键是顺序：所有
webpsource放 JPEG 前面，浏览器从上到下匹配，遇到第一个支持且条件满足的就停 - 别混用
w和x描述符：同一srcset里只能选一种，"photo-400w.jpg 400w, photo@2x.jpg 2x"❌，Safari 可能整条跳过
img 标签没设 width/height，布局偏移拖慢感知速度
picture 不解决回流问题，最终渲染靠内部的 <img>。如果没设 width 和 height，或者设的是 auto，浏览器无法预留空间，图片加载完成前占位空白，一渲染就触发重排——用户觉得“卡了一下”，这不是网络慢，是渲染阻塞。
- 给
<img>加内联width和height（如width="800" style="max-width:90%"），值按原始图比例来，不是响应式尺寸 - 更稳妥用 CSS
aspect-ratio: 16/9，但注意 Safari 15.4+ 才完全支持；老版本得用padding-top技巧降级 -
object-fit: cover不改变容器尺寸计算逻辑，该闪还是闪
最常被忽略的其实是 sizes 和 media 的协同精度——它们不是写个大概就行的配置项，而是浏览器做资源决策的输入依据。差一个像素、少一对括号、单位写错，性能优化就变成性能拖累。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
