紫色条形持续超过50ms即表明CSS布局（Layout）阻塞主线程；Performance面板中purple块代表Rendering阶段的Layout与Recalculate Style，单个>50ms说明布局过重，连续密集出现多因强制同步布局，若其后紧跟大块green则还引发大量重绘。
紫色条形持续超过 50ms，基本就是 CSS 布局（Layout）卡住了主线程。这不是猜的，是 Performance 面板里颜色编码直接告诉你的事实——它不骗人，但得会看。
怎么在 Performance 面板里一眼揪出 Layout 问题
打开 Chrome，F12 → Performance → 点录制 → 操作页面（比如滚动、展开菜单、输入触发重排）→ 停止。生成报告后，盯住时间轴里的 purple 条形（Rendering 下的 Layout 和 Recalculate Style）：
- 单个
purple条宽 > 50ms：说明这次布局计算太重，浏览器来不及在 16ms 内完成一帧 - 连续多个
purple条密集出现：大概率是强制同步布局（forced synchronous layout）在作祟 - Layout 后紧跟大块
green（Paint）：说明样式变更还引发了大量重绘，可能动了太多视觉属性 - 如果 Layout 耗时集中在某个 JS 函数调用栈下，点开它，看是不是你在读取
offsetTop、getBoundingClientRect()之后立刻改了style.width这类操作
哪些 CSS 操作最容易触发昂贵的 Layout
不是所有样式修改都一样。有些改法浏览器能跳过 Layout 直接 Composite，有些则非算不可：
- 触发 Layout 的典型操作：
width、height、top、left、margin、padding、display、font-size、line-height - 不触发 Layout 但可能触发 Paint 的：
color、background-color、visibility（注意：不是display: none） - 既不 Layout 也不 Paint、只走 Composite 的：
transform、opacity（前提是该元素已提升为独立图层） - 特别危险的组合：在循环里反复读写布局相关属性，比如
for (let i = 0; i
查到 Layout 热点后，怎么验证和改
火焰图里点开耗时最高的 Layout 任务，看 Summary 面板的 “Layout Shifts” 或 “Layout Count” 是否异常高；再切到 Bottom-Up 标签页，按 “Total Time” 排序，找最顶上的 JS 函数名：
立即学习“前端免费学习笔记（深入）”；
- 如果是你自己的函数，检查它是否在读取布局后立即写入样式 —— 把读操作批量提前，写操作批量延后（用
requestAnimationFrame包一层） - 如果是第三方库（比如
compromise-three.cjs里某段 DOM 计算），先确认它是否真有必要每帧都算；能缓存就缓存，能节流就节流 - 用
chrome://flags/#enable-layout-instability-api开启布局偏移监控，配合layout-shift事件捕获意外重排 - 别依赖“看起来没卡” —— 即使帧率没掉，频繁小 Layout 也会抬高能耗、拖慢低端设备，Performance 面板里
Layout时间轴不会说谎
Layout 瓶颈藏得深，但 Performance 面板给的线索足够直接：紫色越宽、越密、越靠上，问题就越实。真正难的不是发现，而是判断哪一行 CSS 或 JS 改动能把它干掉，而不是换个地方再长出来。
