重排比重绘更昂贵,因重排需重新计算几何属性并影响渲染树;重绘仅更新像素颜色等不改变布局的样式;强制同步布局和频繁DOM操作是主要性能瓶颈。

重排(reflow)和重绘(repaint)到底谁更贵
重排一定触发重绘,但重绘不一定触发重排。真正吃性能的是重排——它需要重新计算元素的几何属性(位置、尺寸),并影响整个渲染树中相关节点。比如修改 offsetTop、clientWidth,或任何会读取布局信息的操作,都可能强制浏览器立即执行一次重排。
- 常见触发重排的操作:
offsetLeft、getComputedStyle()(读取某些属性时)、scrollTo()、改变className或内联style中影响盒模型的属性(如width、padding、display) - 只触发重绘的操作:修改
color、background-color、visibility(注意不是display: none)等不改变几何信息的样式 - 现代浏览器会批量处理样式修改,但一旦你读取布局信息(如
offsetHeight),就会打破队列,强制同步重排
批量读写分离:避免 forced synchronous layout
所谓“强制同步布局”,就是你在 JS 中一边改样式一边立刻读取尺寸,导致浏览器不得不中断当前渲染流程,立刻计算并返回结果。这是最常被忽视的性能杀手。
- ❌ 错误写法:
element.style.height = '200px'; console.log(element.offsetHeight); // 强制重排
- ✅ 正确做法:先批量读、再批量写,或用
getBoundingClientRect()替代多次读取 - 更稳妥的方式是把读操作全部前置,写操作全部后置;或者使用
requestAnimationFrame()把写操作推迟到下帧开始前
用 transform 和 opacity 做动画替代 top/left/width
只要元素开启了硬件加速(例如有 transform: translateZ(0) 或 will-change: transform),浏览器会把它提升为独立图层,后续对 transform 和 opacity 的修改就只触发合成(composite),完全跳过重排和重绘。
- ❌ 避免:
top、left、width、height动画(每次修改都重排) - ✅ 推荐:
transform: translateX(100px)、transform: scale(1.2)、opacity: 0.5 -
will-change不要滥用:只在动画开始前设置,动画结束及时清除,否则长期占用 GPU 内存
DOM 操作尽量少而集中
频繁增删、移动 DOM 节点会反复触发重排。哪怕只是往 document.body 追加 10 个 div,逐个 appendChild() 也会造成 10 次潜在重排。
立即学习“Java免费学习笔记(深入)”;
- 用
DocumentFragment批量插入:const frag = document.createDocumentFragment(); for (let i = 0; i < 10; i++) { const el = document.createElement('div'); el.textContent = `item ${i}`; frag.appendChild(el); } document.body.appendChild(frag); // 仅一次重排 - 隐藏元素再操作:
el.style.display = 'none'→ 修改 →el.style.display = '',适用于复杂子树更新 - 避免在循环中访问
innerHTML或innerText,它们会触发解析和重排
resize 或 scroll 回调里反复调用 getBoundingClientRect(),又没做节流。这类问题不会报错,但会让滚动卡顿得非常明显。











