重排比重绘更昂贵，因重排需重新计算几何属性并影响渲染树；重绘仅更新像素颜色等不改变布局的样式；强制同步布局和频繁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()，又没做节流。这类问题不会报错，但会让滚动卡顿得非常明显。 
