重排是Layout阶段的产物，需通过Performance面板定位强制同步布局或低效样式计算：检查Recalculate Style耗时（>5ms需警惕）、Layout任务前的JS读取操作、Rendering面板的闪烁区域及FPS曲线中Layout占比突增。
重排（Reflow）本身不是独立事件，而是 Layout 阶段的产物。Chrome DevTools 不会直接标出“这里发生了重排”，但能通过 Performance 面板精准定位触发重排的**真实源头**——通常是强制同步布局（Forced Synchronous Layout）或低效样式计算（Recalculate Style）。 关键不是找“重排”，而是找“谁让浏览器不得不立刻重算布局”。
看 Recalculate Style 是否异常耗时
重排前必先重算样式。如果样式匹配太慢，Layout 就被卡在起跑线上。
- 录制操作后，在火焰图中找 Recalculate Style 长条（紫色或浅蓝），点击它
- 右侧 Summary 中看 Self Time：超过 5ms 就需警惕，超 20ms 基本就是瓶颈
- 展开 Call Stack，确认是否来自 CSS 文件或内联 style；若调用栈干净（无 JS 函数），问题大概率在选择器本身
- 启用 chrome://flags/#devtools-css-selector-profiling 后，右键该任务 → View Flame Chart → 查看下方 Styles 子项，可看到本次参与匹配的具体选择器
抓 Forced Synchronous Layout 的蛛丝马迹
JS 主动读取布局信息（如 offsetHeight、getBoundingClientRect）后立即修改样式，就会触发强制同步布局——这是最典型的重排诱因。
- 在火焰图中搜索关键词：Layout、Forced Synchronous Layout 或 Update Layer Tree
- 若 Layout 任务紧挨着 JS 执行块（如某函数刚读完 offsetTop，下一帧就改了 style），基本可断定是 Layout Thrashing
- 鼠标悬停 Layout 任务，Summary 里会显示触发源：常见为 getComputedStyle、offsetHeight、clientWidth 等读取类 API
结合 Rendering 面板验证影响范围
复杂选择器或不当的 DOM 操作会让浏览器“过度响应”，哪怕只改一个 class，也可能波及大量节点。
- 打开 Rendering 面板（Cmd+Shift+P → 输入 “Rendering”），勾选 Paint flashing 和 Layout Shift Regions
- 执行疑似触发重排的操作，观察是否有大面积非预期闪烁或位移高亮——说明样式作用域失控
- 再开 Layers 面板，检查合成层中的 Nodes 列表：若大量本该被
display: none或contain: layout剪枝的节点仍存在，说明选择器干扰了渲染树优化
快速验证是否真由重排主导
别只盯着 Layout 时间，要看它在整个渲染流水线中的占比和上下文。
- 顶部 FPS 曲线出现红色低谷，同时 Main 轨道上 Layout + Recalculate Style 占比突增 → 重排相关
- 若 Layout 时间短，但 Rendering 总时间高，且 Recalculate Style 占大头 → 样式计算才是根因
- 若 Layout 时间长，但上方有大量 JS 执行（Script Evaluation），且紧跟着 getBoundingClientRect → 强制同步布局 + JS 逻辑耦合
