图片宽高比缺失会导致布局抖动，应通过内联width/height、CSS aspect-ratio或padding-top hack提前占位，响应式图片需按最大视口尺寸声明宽高，第三方图片优先用aspect-ratio兜底。
图片宽高比缺失导致布局抖动
浏览器解析 HTML 时，如果 <img alt="CSS布局中的图片占位占空比优化_减少页面闪烁的方案" > 没有明确的 width 和 height，或 CSS 中未设置宽高比容器，就会等图片加载完成才确定尺寸——这期间内容往下“掉”，用户看到的就是闪烁或跳动。
现代方案不是靠 JS 算尺寸，而是用 CSS 原生能力提前占位：
- 给
<img alt="CSS布局中的图片占位占空比优化_减少页面闪烁的方案" >直接写内联width和height（如<img style="max-width:90%" style="max-width:90%" alt="CSS布局中的图片占位占空比优化_减少页面闪烁的方案" >），浏览器能据此推算宽高比，即使没加载完也预留空间 - 若用响应式图片（
srcset），仍需保留内联宽高，否则 Safari 和部分 Chrome 版本会忽略宽高比推算 - 避免只写 CSS
width: 100%却不设aspect-ratio或父容器高度，这种写法在图片加载前高度为 0
用 aspect-ratio 安全兜底（2023+ 主流浏览器支持）
aspect-ratio 是目前最干净的占位方案，但要注意兼容性断层点：它在 Firefox 89+、Chrome 88+、Safari 15.4+ 才稳定支持；旧版 Safari 需要 min-height + padding-top 的 hack。
推荐写法：
立即学习“前端免费学习笔记（深入）”；
.img-container {
aspect-ratio: 4 / 3;
width: 100%;
}
.img-container img {
width: 100%;
height: 100%;
object-fit: cover;
}
- 不要把
aspect-ratio写在img上，而应写在包裹容器上，否则object-fit可能失效 - 若需兼容 IE 或老安卓 WebView，得回退到
padding-top百分比方案，此时必须确保父容器position: relative，且子元素position: absolute -
aspect-ratio接受数字比（如16 / 9）或无单位数值（如1.777），但别混用单位，aspect-ratio: 400 / 300和4 / 3效果一致，前者易读但无实质区别
响应式图片 + srcset 场景下的宽高处理
很多人以为写了 srcset 就不用管宽高了，其实反而更危险——浏览器可能选中一个分辨率更高的图，但原始 width/height 是按小图标的值写的，导致预留空间错位。
- 内联
width/height应基于「设计稿中该图片在最大视口下的渲染尺寸」来定，不是原图尺寸 - 例如设计稿里图片在桌面端宽 800px、高 450px，那就写
<img style="max-width:90%" style="max-width:90%" alt="CSS布局中的图片占位占空比优化_减少页面闪烁的方案" >，哪怕srcset里有1600w的图 - 服务端生成的图片 URL 若带动态参数（如
?w=800&h=450），不能依赖这些参数让浏览器自动识别宽高比；仍需显式声明 - Vite / Webpack 插件（如
vite-plugin-image-presets）可自动注入宽高，但前提是构建时能读取原始图片元数据，对远程图或 CMS 输出无效
第三方图片（CDN、CMS、用户上传）无法控制宽高的应对方式
当图片 URL 来自外部，你拿不到原始尺寸，也没法改 HTML，这时候只能靠 CSS 强约束。
- 用
aspect-ratio+width: 100%是首选，但必须加min-height: 0防止 Flex/Grid 容器下拉伸失真 - 慎用
object-fit: cover配合固定容器宽高——它不解决占位问题，只解决裁剪，如果容器本身没预留空间，照样闪 - JS 补救仅作最后手段：监听
load事件后补style，但用户首次访问仍会闪；可用loading="lazy"配合decode()提前解码，但不能替代占位 - 真正省心的做法是服务端加一层代理，统一返回带宽高头信息的响应，前端再用
fetch读取后渲染，但这已超出纯 CSS 范畴
宽高比不是视觉细节，是布局契约。漏掉它，等于让浏览器在加载完成前“猜”页面结构——而用户看到的，就是这个猜测过程的抖动。
