重排无法避免，关键在于减少触发次数并规避强制同步布局：调用offsetWidth等API、读写混用、live collection访问均会打断浏览器样式合并机制，导致layout thrashing；应坚持读写分离、批量操作、class切换及transform替代布局变更。
重排不是“要不要触发”的问题，而是“怎么让它只触发一次、甚至被跳过”的问题。浏览器本就会合并样式变更，但你写的 JS 一打断它，就立刻 flush layout——这才是卡顿的根源。
哪些 JS 操作会强制同步重排
只要调用以下任一 API，浏览器就必须立刻计算当前布局，无法延迟或合并：
-
offsetWidth、offsetHeight、offsetTop、offsetLeft -
clientWidth、clientHeight、scrollWidth、scrollHeight getBoundingClientRect()-
getComputedStyle()（哪怕只读一个color，也强制 flush）
常见陷阱：在 for 循环里写 el.style.left = i + 'px'; console.log(el.offsetTop);——每轮都触发一次重排。更隐蔽的是用 document.getElementsByTagName('div') 这类 live collection，每次取 length 或遍历 item 都可能回滚样式队列。
为什么“读-写分离”比“节流”更重要
很多人想用 requestAnimationFrame 或防抖来缓解重排，但根本矛盾不在频率，而在链式依赖。浏览器能合并 100 次 style.width = '200px'，但只要中间插一句 el.offsetWidth，前面所有待生效样式就被强制结算，后面再改又触发新一轮。
立即学习“前端免费学习笔记（深入）”；
- ✅ 正确顺序：先批量读（
offsetTop、getBoundingClientRect()），再批量写（className、style.cssText） - ❌ 错误模式：读 → 写 → 读 → 写 → …… 形成 layout thrashing
- ⚠️ 注意：
getComputedStyle(el).width和el.offsetWidth效果等价，都强制 flush；不要以为“只读不写就安全”
DocumentFragment 为什么只对插入有效
DocumentFragment 是离线容器，往它里面 append 元素、改 class、设 style 都不触发任何重排——但它本身不渲染，所以这些操作只是内存变更。真正代价发生在 fragment.appendChild() 被挂到真实 DOM 的那一刻。
- 适合场景：动态生成一整块列表、表格、卡片组，且后续不再单独更新其中某个子项
- 不适合场景：需要频繁增删单个子节点，或插入后还要立即读取其
offsetHeight - 替代方案：对高频变动元素，优先用
transform+will-change: transform提升图层，让位移/缩放走 GPU 合成，绕过 layout 计算
class 切换为何比 style.xxx 更高效
直接赋值 el.style.width = '100px' 会覆盖内联样式，还可能触发单次重排；而 el.classList.add('resized') 只是标记状态，实际样式由 CSS 规则控制，浏览器可批量处理多个 class 变更，并与其它样式变更合并。
- CSS 中预设好
.resized { width: 100px; height: 200px; margin: 10px; }，JS 只管开关 - 避免混合使用：
el.style.width和el.classList共存时，内联样式权重更高，容易导致意外交互 - 注意：
el.style.cssText = '...'是一次性写入，比逐个赋值快，但仍不如 class 切换语义清晰、可维护性强
真正的难点不在知道哪些 API 会触发重排，而在于识别那些“看起来无害”的读写混用——比如一行 console.log(el.clientHeight) 插在样式修改中间，就能让优化全盘失效。性能瓶颈往往藏在最不像问题的地方。
