用aspect-ratio: 4/3设在图片父容器上可稳定Grid项高度，避免加载抖动；配合srcset/sizes正确匹配、img宽高属性及DevTools布局偏移检测，能系统性解决异步图片导致的重排问题。
Grid容器里图片没加载完就占位不稳？用aspect-ratio锁死比例
图片异步加载时，Grid项高度从0突然撑开，触发整行重排抖动，本质是容器缺乏高度预期。现代方案是让图片容器自带宽高比约束，不依赖内容撑开。
关键不是等图片加载完再渲染，而是让父容器在图片为空时也“知道该占多高”：
-
aspect-ratio: 4 / 3写在图片的直接父容器（比如<div>）上，比写在<code><img alt="CSS如何处理由于图片未加载完成导致的Grid高度重排抖动" >本身更可靠——部分浏览器对<img alt="CSS如何处理由于图片未加载完成导致的Grid高度重排抖动" >的aspect-ratio支持不稳定 - 如果必须兼容旧浏览器（如 Safari padding-top技巧：父容器设
position: relative，子<div>设<code>padding-top: 75%（对应4:3），再把<img alt="CSS如何处理由于图片未加载完成导致的Grid高度重排抖动" >绝对定位塞进去 - 别给
<img alt="CSS如何处理由于图片未加载完成导致的Grid高度重排抖动" >设height: 100%却不配object-fit——这会导致拉伸变形，且仍无法阻止初始高度塌陷 - 若图片尺寸相对统一（如卡片列表），直接写
grid-template-rows: repeat(auto-fill, 250px)，配合overflow: hidden和object-fit: cover - 若需响应式，用
@container查询（需开启container-type: inline-size）替代minmax()，但注意当前仅 Chromium 和 Safari 支持较好 - 绝对避免
minmax(0, 1fr)——0会让Grid在无内容时彻底坍缩，抖动更剧烈 - 首屏内Grid项里的图片，务必去掉
loading="lazy"；否则滚动未开始，图片已该出现却卡在加载队列里 -
decoding="async"在Chrome中可能导致解码完成时间点飘移，与CSS布局计算不同步，建议仅对超大图（>2MB）启用 - 用
img { will-change: transform }对Grid内图片做轻量提示，能减少合成层切换带来的视觉跳变，但别滥用——每个都加会拖慢渲染 - Grid项宽度由
grid-template-columns或flex决定？那就用sizes="(max-width: 768px) 100vw, 33vw"这类具体值，别写100%（无效） - 用
img[width][height]属性提供原始宽高，即使被CSS覆盖，也能让浏览器提前算出宽高比，缓解初始塌陷 - 开发期打开DevTools → Rendering → “Layout Shift Regions”，能直接看到哪些元素在抖动，比猜快得多
Grid模板行高写minmax()还是固定值？看内容是否可预测
用grid-template-rows: repeat(auto-fill, minmax(200px, 1fr)))看似灵活，但图片加载前高度为0，minmax()下限失效，Grid项会压缩到几乎看不见，等图片一来又猛弹开。
更稳的做法是放弃“自适应最小值”，明确告诉Grid：“这个区域至少得这么高”：
立即学习“前端免费学习笔记（深入）”；
loading="lazy"和decoding="async"会放大抖动？要分场景关掉
这两个属性本意是优化性能，但在Grid布局中可能适得其反：浏览器延迟加载+异步解码，导致图片“迟到”时间更不可控，加剧重排时机混乱。
不是所有图片都适合懒加载：
后备图srcset和size配置错，也会引发二次重排
当srcset提供多个分辨率图，但sizes没匹配视口宽度，浏览器可能先选错一个尺寸（比如选了太小的图），等高清图加载完再替换，造成“先糊后清”的尺寸变化，Grid再次抖动。
检查sizes是否真实反映容器最终宽度：
真正难处理的是那些宽高完全不可预知的用户上传图——这时候与其硬扛CSS，不如服务端统一转成带exif宽高的WebP，并强制返回content-length头，让浏览器尽早分配空间。
