CLS数值高无需重写页面，主因是少数未约束DOM节点；<img>必须用内联width/height（非CSS）确保HTML解析时预留空间，srcset/sizes不能替代，iframe同理；动态内容需HTML源码级占位；字体加载须font-display:swap配合size-adjust；滚动条突变需html{overflow-y:scroll}锁定宽度。
CLS 数值高，不等于要重写整个页面结构——绝大多数抖动来自几个可定位、可约束的 DOM 节点，调优重点是让浏览器在解析 HTML 阶段就能确定关键元素的尺寸边界。
为什么 <img> 必须带 width 和 height 属性，仅 CSS 无效
浏览器解析 HTML 时，<img> 没有内联 width/height 就按 0×0 占位；等图片加载完成再重排，下方内容必然下移。CSS 设置（如 width: 100%; height: auto）发生在样式计算阶段，晚于初始布局，无法提供占位依据。
-
<img src="a.jpg" width="600" height="400">是唯一能被 HTML 解析器立即识别的尺寸声明 - 响应式场景下可搭配
style="aspect-ratio: 16/9; width: 100%; height: auto;"，但 Safari 15.4+、Firefox 89+ 才稳定支持，旧版仍需 fallback 内联尺寸 -
srcset+sizes不能替代width/height：浏览器可能先按默认尺寸占位，sizes解析后再调整，造成两次偏移 -
<iframe>同理，YouTube 或广告嵌入必须带width和height，否则loading="lazy"也救不了
动态插入内容前，DOM 中就得有“空壳”占位
广告、评论、推荐模块这类 JS 动态注入的内容，只要没提前占位，插入瞬间就会把原有内容往下顶——Lighthouse 常报 <body> 贡献 CLS，根源往往就在这里。
- 在 HTML 源码里直接写占位容器：
<div id="ad-slot" style="min-height: 250px"></div>，高度尽量接近历史均值（可用服务端预估或客户端缓存） - 避免用
visibility: hidden或opacity: 0：它们不脱离文档流，但无尺寸，等于没占位 - 第三方脚本注入节点不可控，可在其父容器加
contain: layout（Chrome 85+ 支持），但前提是该容器已有明确宽高约束 - 若必须 JS 插入，优先用
position: absolute或transform: translateY()，不参与文档流布局
字体加载引发的文本块高度跳变怎么压住
自定义字体加载期间用系统字体渲染，加载完再换——若两套字体行高、字宽差异大，文本块高度突变，就会把下面内容往下顶。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 禁用
font-display: optional：它可能跳过加载，导致字体反复切换，CLS 更糟 - 用
font-display: swap，但必须配合@font-face中的size-adjust（如size-adjust: 102%）或descent-override对齐度量值 - 关键容器（如
<h1>、按钮）预设line-height和min-height，防止高度塌缩或撑开 - 避免在
font-family列表混用等宽与比例字体（如"Monaco", "Helvetica"），ch/ex单位行为不一致，易引发宽度跳变
滚动条显隐导致的全局宽度突变不是 CLS，但会放大抖动感知
这不是 CLS 计算范围（CLS 不统计用户交互触发的位移），但滚动条出现/消失会让 body 宽度突变 12–17px，所有居中、width: 100% 元素瞬间重排，加剧抖动观感。
-
html { overflow-y: scroll; }可锁定宽度，消除该突变源；Safari 在某些 zoom 场景下可能微调，极少需加margin-left: -webkit-scrollbar补偿 - 副作用是滚动条常驻，若设计不允许，应改用「隐藏全局滚动条 + 局部滚动容器」方案
- 第三方组件库（如 Vue 的 el-scrollbar、微信小程序
scroll-view）内部设position: fixed会导致定位基准错乱，表现为高频跳动——必须把fixed元素移出滚动容器，挂到body下
真正难处理的不是你写的那几行 HTML，而是第三方脚本在 DOMContentLoaded 后偷偷注入无尺寸声明的 <div>，或者组件库生命周期里反复读写 offsetHeight 却没做防抖。这类问题不会出现在 Lighthouse 报告里，得靠 Chrome DevTools 的 Layout Shifts 面板逐帧抓取，再结合 getCLS({ reportAllChanges: true }) 上报片段定位具体节点。
