响应式图片性能瓶颈在于sizes错配、width/height缺位、object-fit未生效：sizes须严格对齐CSS渲染宽度，否则浏览器误载大图；width/height为防布局偏移和LCP恶化必填；object-fit需容器有明确尺寸才生效。
响应式图片排版不是“加了srcset就万事大吉”，真正卡住性能和体验的，是sizes写错、width/height缺位、object-fit没生效这三类细节问题。它们不报错，但会让 LCP 拉长、带宽翻倍、图片突然跳动。
为什么写了sizes浏览器还是加载最大图
根本不是浏览器“选错了”，而是你给的sizes值和 CSS 实际渲染宽度对不上。浏览器按sizes算出“这张图要占多宽”，再从srcset里挑最接近且不小于该宽度的资源——如果sizes写成"100vw"，而容器实际只有 720px 宽，它就会拉下 2400w 的图。
- 先写好 CSS 断点，再反推
sizes：@media (min-width: 768px) { .hero-img { width: 720px; } }→sizes="(max-width: 767px) 100vw, 720px" - 父容器有
padding就得减掉：视口 390px、padding: 0 20px→ 有效宽度 ≈350px →sizes="(max-width: 767px) 350px, 720px" - 单位必须统一：不能混用
vw和px，更不能塞rem；sizes里出现1.5rem会被忽略
object-fit: cover没效果的常见原因
object-fit不是“让图片自适应”，而是“让图片在已知尺寸的盒子里怎么填”。盒子没尺寸，它就不干活。
- 父容器只设
width: 100%、height: auto或未声明height→ 高度塌陷，object-fit直接跳过 -
<img>自带width/height属性（如width="600" height="400"）会转成内联样式，覆盖你写的width: 100%; height: 100% - 富文本编辑器插入的图，父
<div>常无高度约束，需手动设min-height或aspect-ratio - IE 完全不支持，老版 iOS Safari 需加
-webkit-object-fit；fallback 只能用background-image
width和height属性为什么不能省
没设这两个属性的<img>在加载前不占空间，内容会突然下移——这不是视觉小问题，它直接恶化 LCP，还会触发浏览器提前加载更大图来“抢时间”。
立即学习“前端免费学习笔记（深入）”；
- 必须填原始图比例：1200×800 的图，就写
width="1200" height="800" - 推荐双保险：
<img width="1200" height="800">+ CSSaspect-ratio: 1200 / 800 -
object-fit: cover不解决占位问题，它只控制裁剪；容器尺寸仍由width/height或aspect-ratio决定 - 旧版 Safari 不支持
aspect-ratio？可用padding-top技巧降级（如padding-top: 66.67%对应 16:9）
WebP/AVIF 在<picture>中加载失败
浏览器从上到下解析<source>，遇到第一个media匹配且type受支持的就停。Safari 13 及更早版本不支持 WebP，如果你把<source type="image/jpeg">放前面，它永远卡在这条，根本不会往下看 WebP。
-
WebP/AVIF必须排在JPEG/PNG前面：<source type="image/webp">→<source type="image/jpeg"> - 同一
<source>内不能混用w和x描述符，部分 Android 浏览器会直接忽略整条srcset - 只保留真实触发的断点：
<source media="(min-width: 1440px)">如果你的 CSS 根本没定义这个断点，就是冗余项 -
type拼错（如多写分号）或浏览器不支持，整条<source>就被忽略；兜底的<img>必须存在，且不能省略src和alt
这些细节没有一个会抛错误，但每一个都可能让首屏加载慢 300ms、CDN 带宽多花一倍、用户看到图片突然下跳——调优的关键，是盯着 DevTools 的 Network 和 Rendering 面板，逐条验证sizes是否对得上布局、object-fit是否真生效、width/height是否被覆盖。
