触发重排的css属性包括width、height、top、left、margin、padding、border、display、position、font-size；最危险的是js中读写混用导致强制同步布局。
哪些CSS属性会触发layout（重排）
浏览器渲染时，修改某些CSS属性会让引擎重新计算元素几何信息（位置、尺寸），这个过程叫layout，开销大。真正要避开的是那些强制浏览器同步读取布局再写入的属性。
常见触发重排的属性包括：width、height、top、left、margin、padding、border、display、position、font-size。其中最危险的是在JS中「读写混用」：比如先读offsetTop，再改style.width，会强制同步layout。
- 避免在循环或高频事件（如
scroll、resize）里读取offsetHeight、getBoundingClientRect()等返回布局信息的API - 把多次样式修改合并成一次：用
className切换或cssText批量赋值，而不是逐个设style.xxx - 动画场景优先用
transform和opacity——它们只触发改写合成层（compositing），不进layout流程
用transform替代top/left移动元素
用top/left做位移，每次修改都会导致父容器及后续兄弟元素重排；而transform: translateX()只影响本元素的绘制矩阵，且通常能升格到独立图层，GPU加速更稳。
注意：transform不是万能的。如果元素本身有position: absolute且依赖父容器定位流，突然切到transform可能让布局逻辑变难理解，尤其涉及calc()或响应式百分比时。
立即学习“前端免费学习笔记（深入）”；
- 不要写
top: 20px; transform: translateX(10px)这种混合写法——top仍会触发layout - 需要居中或对齐时，优先用
transform: translate(-50%, -50%)配合left: 50%; top: 50%，但确保父容器没频繁重排 - 动画中若需动态计算位移量，用
requestAnimationFrame包裹，并缓存getBoundingClientRect()结果，避免重复读取
避免强制同步布局（Forced Synchronous Layout）
这是前端性能里最隐蔽也最常被忽视的问题：JS执行过程中，浏览器被迫暂停渲染流水线，立刻回溯计算当前样式和布局，造成卡顿。典型错误就是「读-改-读-改」模式。
比如在for循环里反复读el.offsetHeight又改el.style.height，每轮都强制layout。Chrome DevTools的Performance面板里能看到大量黄色的Layout块，就是它。
- 把所有读操作集中到前面，所有写操作集中到后面（read-write separation）
- 用
getComputedStyle(el).height代替el.offsetHeight时要小心——它同样触发同步layout，除非你确定样式已稳定 - 现代方案：用
ResizeObserver监听尺寸变化，代替轮询offsetWidth；用IntersectionObserver代替getBoundingClientRect()判断是否进入视口
使用contain属性隔离布局影响范围
contain是CSS里少有的、明确告诉浏览器“这个区域的子元素不会影响外部布局”的声明。设为contain: layout paint style后，浏览器可安全地跳过对该容器的大部分布局计算，尤其适合列表项、卡片、弹窗等独立模块。
兼容性要注意：IE全不支持，Safari 15.4+才支持layout值。生产环境可用@supports (contain: layout)做渐进增强。
- 别滥用：给body或大容器加
contain可能适得其反——它会切断内部元素与外部的布局联系，比如position: fixed子元素会相对该容器定位 - 推荐组合：
contain: layout paint+will-change: transform（仅对即将动画的元素），比全局开will-change更稳妥 - 验证是否生效：在DevTools的Elements面板选中元素，右侧Computed里看
contain是否解析成功，以及Layout Shift指标是否下降
