chrome devtools 的 computed 标签页用于定位布局抖动（cls）根源：检查 width/height/margin 等 layout-impacting 属性是否动态变化、contain-intrinsic-size/aspect-ratio 是否为 none、composited layer 是否失效，以及是否存在强制同步布局或占位缺失。
Chrome DevTools 没有独立的“计算样式”面板——你实际使用的是 Elements 面板右侧的 Computed 标签页。它不直接标出“抖动源”，但能精准暴露那些在渲染后仍反复触发重排（Layout）或破坏合成前提的 CSS 属性，从而定位布局抖动（CLS）的深层原因。
重点检查“Layout-impacting”属性是否动态变化
布局抖动本质是元素几何尺寸或位置在无用户操作时意外改变。Computed 标签页能帮你确认哪些属性被 JS 或 CSS 动态覆盖，进而引发位移：
- 选中疑似抖动的元素（如图片、广告容器、弹窗内容区），在 Computed 中搜索 width、height、margin、padding、top、left 等字段
- 对比页面加载完成前后：如果这些值从固定像素（如
200px）变成auto或fit-content，说明 JS 删除了关键样式，或 CSS 优先级被覆盖 - 特别留意 contain-intrinsic-size 和 aspect-ratio 是否为
none：现代浏览器依赖它们预留空间；若缺失，图片/iframe 加载后会突然撑开容器，直接造成 CLS
验证“合成层断裂”是否放大抖动影响
即使单个元素只轻微位移，若它本该是稳定合成层却频繁重建，抖动会被放大并扩散到相邻区域：
- 在 Computed 中展开 Rendered Fonts / Layer 区域，查看 Composited layer 是否为
true - 若为
false，再检查 transform、opacity、will-change 是否生效；常见抑制项包括：overflow: hidden、clip-path、父级transform: none - 结合 Layers 面板观察：同一元素在滚动或 hover 后是否从列表中“消失又重现”——这代表 JS 正在动态开关提升层声明，每次重建都会拖慢重绘，加剧视觉不稳定
揪出隐藏的“强制同步布局”链路
JS 读取某些布局属性会立刻触发同步计算，哪怕只读一次，也可能打断渲染流水线，让后续样式变更更易引发抖动：
- 在 Computed 中点击右上角 ⋯ → Show layout shifts（需开启 Rendering 面板的 Layout Shift Regions）
- 若某元素旁出现黄色高亮边框，说明它正因 JS 读取
offsetHeight、getBoundingClientRect()等而被强制布局 - 此时回看 Styles 面板的 Applied 样式：检查是否有类名切换导致
display: none ↔ block或visibility: hidden ↔ visible，这类切换常伴随隐式几何重算
快速验证图片/字体类抖动的占位完整性
超过 60% 的 CLS 来自资源异步加载缺乏预估，Computed 是确认占位是否生效的最终依据：
- 选中
<img>元素，在 Computed 中查找 width 和 height：必须显示具体像素值（如320px），而非auto；若为auto，说明 HTML 中缺width/height属性或被 CSS 覆盖 - 对字体相关元素，检查 font-size、line-height、font-family 在字体加载前后是否一致；若
font-display: swap导致 fallback 字体行高不同，Computed 会清晰显示变化值 - 对广告容器，确认 aspect-ratio 或 padding-bottom 是否计算生效：若 Computed 中
height显示为0px，说明占位 hack 失效
