重绘和回流必然带来可测量开销：读取offset/client/scroll属性、getComputedStyle()、getBoundingClientRect()等会强制同步回流；transform和opacity因不参与几何计算而更安全；批量操作应使用DocumentFragment或离线修改以避免多次回流。
重绘和回流不是“可能影响性能”，而是只要发生，就必然带来可测量的开销——尤其在中低端设备或复杂 DOM 场景下，一次意外的强制同步布局（比如读取 offsetWidth）就能让动画掉帧。
哪些 JS 操作会立刻触发回流？
浏览器不会等你改完所有样式再统一计算，有些操作会「打断队列」，强制立即执行回流并返回准确值。这类操作常被忽视，但恰恰是卡顿高发点。
- 读取任何以
offset、client、scroll开头的属性，例如offsetHeight、clientTop、scrollTop - 调用
getComputedStyle()或getBoundingClientRect() - 访问伪元素样式（如
getComputedStyle(el, '::before')） - 在修改样式后、下一个 repaint 前读取上述任一布局信息
典型陷阱：在循环里一边改 style.width，一边读 offsetWidth 判断是否达标——每次读取都触发一次回流，100 次循环 = 100 次回流。
为什么 transform 和 opacity 更安全？
这两个 CSS 属性被现代浏览器标记为「合成层友好」，它们的变化不参与主渲染树的几何计算，只影响图层绘制或合成阶段。因此：
立即学习“前端免费学习笔记（深入）”；
- 修改
transform: translateX(10px)不会改变元素在文档流中的位置，不触发回流，只触发重绘（甚至可能被 GPU 合成跳过重绘） - 修改
opacity: 0.5只影响像素混合，不改变布局、不读取几何信息，也不触发回流 - 但注意：如果元素本身没有提升为独立合成层（比如没加
will-change: transform或transform: translateZ(0)），频繁动画仍可能引起额外的图层合并开销
批量 DOM 修改怎么避免多次回流？
一次性插入 100 个节点，如果逐个 appendChild，每插入一个都可能触发回流；而用以下方式可压缩为至多 1 次：
- 用
DocumentFragment先离线组装：const frag = document.createDocumentFragment(); for(...) frag.appendChild(el); parent.appendChild(frag); - 把元素设为
display: none（或脱离文档流如position: absolute），修改完再恢复 - 使用
element.innerHTML替代多次appendChild，但要注意 XSS 风险和事件监听器丢失 - 对已有元素样式批量变更，优先用
className或classList切换预设 CSS 类，而非链式赋值el.style.xxx
真正难优化的从来不是单次回流，而是那些隐藏在 resize、scroll、input 事件回调里的「高频小回流」——它们叠加起来比一次大回流更伤性能。监控时别只看 FPS，更要抓 Layout 阶段耗时，尤其注意 DevTools 的「Rendering」面板里黄色的 Layout 块是否密集出现。
