布局抖动不是报错而是性能杀手，源于JS中反复读写offsetHeight等触发重排的属性，导致“读-写-读-写”循环强制浏览器频繁同步计算布局；应使用requestAnimationFrame批量集中读写，并配合transform、contain等CSS优化避免重排。
布局抖动（Layout Thrashing）不是浏览器报错，而是性能隐形杀手——只要你在 JS 中反复读写 offsetHeight、getComputedStyle 这类触发重排/重绘的属性，就可能让页面卡顿得像在拖拽 1080p 视频。
什么时候会意外触发 layout thrashing？
典型场景是“读-写-读-写”交错执行，比如滚动监听里边计算元素位置、动态调整样式：
- 每次访问
element.offsetHeight都强制浏览器同步计算当前布局（reflow） - 紧接着调用
element.style.top = '20px'又标记该元素为 dirty，等待下次 flush - 下一次读取
getComputedStyle(element).top又触发新一轮同步 layout
浏览器被迫在单次 JS 执行中来回 flush layout → style → layout → style，帧率直接掉到 20fps 以下。
用 requestAnimationFrame 批量读写
核心原则：把所有 layout-read 操作集中到一帧开头，所有 layout-write 操作集中到同一帧末尾。浏览器会在 RAF 回调执行完后统一 flush。
立即学习“前端免费学习笔记（深入）”；
- 不要在循环里混用
offsetTop和style.transform - 先收集所有要读的值（如
el.getBoundingClientRect()），再统一写入（如el.style.transform） - 用
requestAnimationFrame包裹整块逻辑，确保它跑在渲染帧内
function updatePosition() {
const rect = target.getBoundingClientRect(); // ✅ 一次性读
const scrollY = window.scrollY;
// ❌ 不要在这里再读 offsetHeight 或 clientWidth
target.style.transform = `translateY(${scrollY - rect.top}px)`; // ✅ 一次性写
}
window.addEventListener('scroll', () => requestAnimationFrame(updatePosition));CSS 层面如何配合减少 reflow？
CSS 不是旁观者——它能帮你把很多 JS 本该干的事交给渲染引擎，天然避开 layout 计算。
- 优先用
transform和opacity做动画，它们走合成层（compositor），不触发 layout - 避免在 JS 中修改
width、height、left、top等影响几何的属性 - 给频繁动画的元素加
will-change: transform（仅当必要时），但别滥用 - 用
contain: layout paint隔离 DOM 子树，限制重排范围
调试 layout thrashing 的真实信号
Chrome DevTools 不会直接标出 “layout thrashing”，但这些现象高度相关：
- Performance 面板中出现密集的绿色 “Layout” 块（尤其在 scroll 或 resize 事件里）
- Timeline 里看到连续多个
Recalculate Style→Layout→Update Layer Tree循环 -
console.time()测出来的offsetHeight调用耗时突然升到 0.5ms 以上（正常应
真正难防的是那些藏在第三方库或 polyfill 里的隐式 layout 强制——比如某个 getBoundingClientRect() 调用被封装在 measure() 方法里，而你只看到它返回了数字。
