动态内容插入前未预留高度会导致body成为最大cls贡献者，因js向body或main追加无高div会迫使下方内容下移；必须在html源码中用min-height等预设占位，且width/height属性需同时存在、为无单位整数，font-display:swap须配合size-adjust对齐字体度量，getcls()需启用reportallchanges才能捕获真实偏移。
动态内容插入前没预留高度，body 就是最大 CLS 贡献者
只要 JS 往 body 或 main 里 append 一个没设高度的 div，下方所有内容立刻下移——Lighthouse 报告里 body 占 CLS 总分 80% 以上，实际就是它在“背锅”。这不是 bug，是浏览器按标准流渲染的必然结果。
常见错误写法：<div id="comments"></div>（空容器）<div id="ads" style="visibility: hidden"></div>（visibility: hidden 不占空间）
- 必须在 HTML 源码中就写好占位，比如
<div id="comments" style="min-height: 320px"></div>，高度取历史加载完成后的 P75 值 - 避免用
height: 0+ JS 后续 expand，哪怕加了 transition，CLS 值照样累加 - 第三方广告或推荐模块，优先用
contain: layout style paint包裹，但前提是容器本身有明确宽高约束（否则无效）
img 的 width 和 height 属性漏一个，CLS 就翻倍
浏览器解析 HTML 时，只看到 width="800" 没看到 height，就会当它是 0×0；等图片加载完再重排，下方文字/按钮直接被顶下去。这不是 CSS 能补救的——style="width: 100%; height: auto" 完全无效。
-
width和height必须同时存在，且为无单位整数（如width="1200" height="800"），不能是"1200px"或"100%" -
<picture></picture>场景下，<img>标签仍要填原始图尺寸，和srcset实际加载哪张图无关 - 响应式场景可用
style="aspect-ratio: 16/9; width: 100%; height: auto"，但 Safari 15.4+、Firefox 89+ 才稳定支持，旧环境必须 fallback 到 padding-top 百分比方案
font-display: swap 加了但 CLS 还高，问题出在字体度量没对齐
用了 font-display: swap，文本确实不阻塞渲染了，但系统字体和 Web Font 行高差 2px，换字瞬间段落撑开，下面按钮就被往下顶——这算典型 CLS 片段，且常被忽略。
- 必须配合
@font-face中的size-adjust: 102%或descent-override（Chrome 109+、Firefox 114+ 支持） - 关键文案容器（如
<h1></h1>、CTA 按钮）要预设line-height和min-height，防止字体切换时高度塌缩或突增 - 别在
font-family里混用等宽和比例字体（如"Monaco", "Helvetica"），ch/ex单位行为不一致，宽度跳变更隐蔽
用 getCLS() 监控却看不出问题，因为你没开 reportAllChanges
getCLS() 默认只上报“稳定后”的最终值，用户滚动到广告位、评论加载完成这些真实偏移事件，全被过滤掉了。你看到的 0.05 可能掩盖了 12 次 >0.002 的抖动。
- 生产环境务必启用
{ reportAllChanges: true }，配合attribution查具体元素 - 单页应用中，路由切换后新页面的偏移可能计入上一页 CLS 总和，需监听
navigation事件并手动调用reset() - 别只信 Lighthouse：它只跑一次模拟慢网，而真实用户可能在广告延迟 3s 后才触发偏移——用 Chrome DevTools 的 Rendering 面板开启
Layout Shift Regions才能实时盯住“谁在跳”
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
