响应式图片自适应缩放的核心是max-width: 100%配合height: auto以保持宽高比，但需父容器有宽度约束、避免固定height、声明width/height或aspect-ratio预留空间，并合理使用srcset/sizes与loading属性防止重排和错载。
图片自适应缩放本身不慢，慢的是浏览器反复重排、错载高清图、或没预留空间导致的布局抖动。 直接加 max-width: 100% 不会卡，但若没配 width/height、sizes 或用了 loading="lazy" 却没控制触发时机，就会让首屏图片加载变成“边拉边算边跳”的连锁反应。
为什么加了 max-width: 100% 还卡？关键在 height 和容器约束
只写 max-width: 100% 没用，浏览器仍需等图片下载完才知道高度，触发强制回流。必须搭配 height: auto，且父容器要有明确宽度参照：
- 父容器不能是
display: flex且未设min-width: 0——flex 默认min-width: auto会阻止图片收缩，导致横向溢出 - 避免给容器设固定
height，尤其不要写height: 400px这类死值；如需等比占位，用padding-top: 56.25%+ 绝对定位图片更稳 -
img标签必须声明width和height属性（或用 CSSaspect-ratio），否则首次渲染无占位，图片加载后页面“跳动”
srcset + sizes 配错反而拖慢加载
只写 srcset 不配 sizes，浏览器只能按设备像素比瞎猜宽度，大概率下错图：手机加载 2x 桌面图，带宽浪费、解码变慢、内存暴涨。
- 安全写法示例：
sizes="(max-width: 480px) 100vw, (max-width: 768px) 50vw, 33vw"—— 明确告诉浏览器“这张图在小屏占满、中屏占半、大屏占三分之一视口” -
srcset中的400w描述符必须对应原图真实宽度，工具链生成多尺寸图时建议文件名带分辨率标识，如hero-800w.webp - 避免
sizes="100vw"全局硬写，侧边栏里的图也会被当成全屏宽加载
loading="lazy" 在首屏用错位置会放大卡顿
loading="lazy" 是防非首屏图抢占资源的好东西，但 banner、logo、首屏轮播图加了它，等于主动制造 FOUC（内容闪现）和布局跳动。
立即学习“前端免费学习笔记（深入）”；
- 核心内容图禁用
loading="lazy"，改用decoding="async"提前解码，不阻塞主线程 - 非首屏图才启用 lazy，且确保它们已加
height/width或aspect-ratio，避免懒加载触发时突然撑开页面 - 慎用 JS 手写 IntersectionObserver 替代原生 lazy——除非你真需要细粒度控制，否则原生更轻、兼容性更好、触发更准
object-fit 用得不对会白费 GPU 加速
object-fit 本身不卡，但它必须配合显式宽高才能生效；单独写 object-fit: cover 不会缩放，只会让图片“贴在左上角”不动。
- 要生效，至少得有
width: 100%或width: 300px+height: 200px（或aspect-ratio） - IE 不支持
object-fit，如果还要兼容，得用background-image+background-size回退，但注意：background-image绕过loading="lazy"，也无法被爬虫识别为内容图 -
object-fit: contain适合头像/图标，cover适合 banner；别在需要留白的场景硬用cover，裁剪逻辑不可控
真正卡住的从来不是“怎么缩”，而是“什么时候缩、缩成多大、缩之前有没有占好位”。很多优化失败，是因为把 max-width 当万能药，却忘了它只是链条里最前端的一环——上游没定宽高，下游就必然重排；上游没控带宽，下游就必然等图等得久。
