懒加载本身不导致抖动，根本原因是浏览器首次解析html时缺乏确定性尺寸信息；必须为img设置width/height属性，否则即使lazy也会因占位失准引发cls。
懒加载本身不导致抖动，但和图片尺寸缺失、占位图错配、父容器约束失效组合时，会放大布局抖动（CLS）——根本问题从来不是loading="lazy"，而是浏览器在首次解析 HTML 阶段没拿到足够确定性尺寸信息。
为什么loading="lazy" + 无width/height必抖
浏览器对懒加载的触发依赖初始占位预判：它需要知道元素“该有多大”，才能决定是否提前 fetch 或等待滚动进入。如果<img>既没width也没height，首帧渲染就按 0×0 或行内默认尺寸（通常 1em 高）占位，等图片真正加载完成才重排——此时不管是不是懒加载，下方内容都被顶下去。
- 即使写了
style="max-width: 100%; height: auto"，CSS 计算晚于 HTML 解析，无法参与初始布局 -
srcset+sizes不能替代width/height：浏览器可能先按默认尺寸占位，再根据sizes调整，造成两次偏移 - iOS Safari 15.4 之前不支持
aspect-ratio，仅靠它 fallback 不足，仍会抖
占位图尺寸错配是隐藏雷区
用data-src或 CSS background-image实现占位，本质是绕过浏览器原生懒加载机制，反而破坏尺寸锚定。占位图必须通过src属性注入，且宽高必须与真实图一致。
-
<img src="placeholder.svg" style="max-width:90%" style="max-width:90%" loading="lazy">✅ 浏览器首帧即知尺寸，真实图加载后直接填充 -
<img src="placeholder.svg" style="max-width:90%" style="max-width:90%" loading="lazy">❌ 占位太小，真实图加载后撑开容器，抖动发生 -
<img src="" loading="lazy">或src="data:image/gif;base64,..."→ Chrome 直接忽略loading="lazy"，降级为 eager 加载 - CSS
background-image占位完全无效：loading属性对其不生效，也无法用 JS 安全切换
父容器约束失效放大抖动感知
懒加载图片若放在flex、grid自适应容器里，或父级设了overflow: hidden、transform，会导致 Intersection Observer 判定失效，占位图长期挂着，真实图永不加载；或者容器高度塌陷，让抖动从局部变成全局。
- 确保父容器有明确宽高约束：
min-height、aspect-ratio或固定尺寸 - 避免在
transform、will-change、overflow: hidden容器内使用懒加载图片 - 嵌套滚动容器（如局部
overflow: auto）会干扰视口检测，优先用html { overflow-y: scroll }锁定 body 宽度，而非局部滚动 - 首屏图片别全打
loading="lazy"：前 3–5 项应设loading="eager"或配合<link rel="preload">
动态插入图片时的结构陷阱
JS 动态创建<img>并设loading="lazy"，等于放弃 HTML 解析阶段的尺寸锚定机会——浏览器已走完 layout，此时插入就是硬塞节点，必然引发重排。
- 广告、评论、推荐模块等动态内容，必须在 HTML 源码中写好占位：
<div id="ad-slot" style="min-height: 250px"></div> - 禁止用
visibility: hidden或opacity: 0占位：它们不脱离文档流，但无尺寸，等于没占 - 若必须 JS 插入，优先用
position: absolute或transform: translateY()，让元素不参与流式布局 - 第三方脚本注入的图片，可在其父容器加
contain: layout（Chrome 85+），但前提是该容器已有明确宽高
所有抖动最终都归结到一个事实：浏览器在解析 HTML 时，需要确定性尺寸信号。懒加载只是把不确定性的爆发时间推迟到了滚动时刻，而不是消除了不确定性本身。写死width和height不是过时做法，而是现阶段唯一能被所有浏览器在最早阶段识别的尺寸声明方式。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
