强制同步布局表现为performance面板中recalculate style与layout高频紧邻成对出现，尤其在滚动等交互中单次任务内反复触发3–8ms布局，是毫秒级阻塞的典型信号。

直接用 Chrome 的 Timeline（现整合进 Performance 面板）录制并识别“强制同步布局”，关键在于捕捉 JS 执行中穿插的 recalculate style 和 layout 小块，尤其当它们高频、成对、紧贴出现在单个长任务里时——这就是典型的毫秒级阻塞信号。

一、精准录制：让抖动行为暴露在 Timeline 中

强制同步布局往往藏在用户交互中（如滚动、输入、鼠标移动），所以录制必须复现真实触发路径：

• 打开 DevTools → Performance 面板 → 点击录制按钮（●）
• 立即执行目标操作：比如快速滚动列表、拖拽元素、或连续点击触发 DOM 更新的按钮
• 保持操作 2–3 秒后停止录制；避免空等，否则抖动信号会被稀释
• 勾选 “Screenshots”（截图）和 “Web Vitals”（可选），有助于关联视觉卡顿与时间点

二、定位抖动帧：看 timings 轨道里的“绿色+深绿”组合

在录制结果中切换到 timings 轨道（下方默认视图），重点扫描：

• 绿色小方块（Recalculate Style）：表示样式重新计算。单独出现不危险，但若后面紧跟深绿色长条，就是预警
• 深绿色长条（Layout）：浏览器被迫立即执行布局。长度越长（哪怕仅 5–10ms），说明该次同步布局越重
• 典型抖动模式：Recalculate Style → Layout → Recalculate Style → Layout 在同一主线程任务内反复出现，间隔极短（

三、下钻根因：从 Main 轨道跳转到具体函数栈

在 Main 轨道中找到一个含密集 layout/recalc 的长任务（紫色为主 + 绿/深绿夹杂），右键 → “Zoom to selected”，再点击该任务：

• 切换到 Bottom-Up 标签页，按 “Self Time” 排序
• 查找调用栈顶部含 getBoundingClientRect()、offsetHeight、clientWidth、scrollHeight 等读取布局 API 的函数
• 常见高危位置：滚动事件回调（onscroll）、ResizeObserver 回调、Vue 的 updated 钩子、React 的 useEffect 中未防抖的 DOM 查询

四、验证与对比：加一行 console 就能确认抖动是否存在

在疑似代码段前后插入计时标记，实测是否真被 layout 拖慢：

• console.time('before-read');
• const h = el.offsetHeight; // 触发强制 layout 的读取
• console.timeEnd('before-read');
• el.style.height = '200px'; // 后续写入
• 如果 before-read 耗时明显 >1ms（尤其在滚动中反复打印出 3–8ms），基本可断定是强制同步布局在作祟