强制同步重排由读取布局信息触发，如offsetTop、getBoundingClientRect()等；循环中混用读写、实时集合访问、内联样式修改、频繁DOM插入及错误动画属性均会引发高成本重排。
直接改 style 属性、在循环里读 offsetHeight、用 table 布局——这些操作不是“可能”引发卡顿，而是几乎必然触发高成本重排。浏览器不会因为你写了“优化”注释就绕过渲染流水线。
哪些 DOM 操作会强制同步重排
浏览器在 JS 执行中读取布局信息时，必须立刻 flush 排队样式并重新计算几何，这不是可选行为。
-
offsetTop、offsetLeft、clientWidth、getBoundingClientRect()这类 API 一调就强制重排，尤其当它们出现在修改样式的语句前后（如先el.style.width = '200px'，再读el.offsetWidth） - 循环中反复读写：比如
for里每轮都el.style.left = i + 'px'然后el.offsetTop，等于主动制造 N 次重排 -
document.getElementsByTagName('div')是实时集合（live collection），每次访问都可能触发重排；应先转成数组：[...document.getElementsByTagName('div')]
用 class 切换代替内联 style 修改
改 element.style.color = 'red' 会立即触发布局检查；而加一个预定义的 class，让所有样式变更由 CSSOM 统一处理，浏览器能批量合并、延迟或跳过不必要的计算。
- 内联 style 修改无法复用 CSS 缓存，且每次赋值都走 style 对象 setter，间接触发样式 dirty 标记
- class 切换不改变 DOM 结构，只影响匹配规则，渲染树更新更轻量
- 避免在动画帧中混合使用：比如一边
el.classList.add('moving')，一边又手动设el.style.transform = 'translateX(10px)'，容易破坏合成层一致性
批量插入节点必须用 DocumentFragment
对 document.body 连续 appendChild() 100 次，等于告诉浏览器“请重排 100 次”；而用 DocumentFragment 收集后再挂载，浏览器只做一次 layout。
立即学习“前端免费学习笔记（深入）”；
-
innerHTML = str虽快，但会清空已有事件监听器（旧版 IE 更明显），且存在 XSS 风险；DocumentFragment是更安全的替代方案 - 如果只是替换文本内容，优先用
textContent而非innerHTML—— 后者会触发 HTML 解析流程，哪怕字符串里没标签 - 现代浏览器支持
replaceChildren()，适合整块替换，但注意兼容性：Safari 17.4+、Chrome 120+ 才稳定
动画属性必须选对，否则硬件加速白加
transform 和 opacity 能走合成层，前提是元素已提升为独立图层；但盲目加 will-change: transform 或 translateZ(0) 可能增加 GPU 内存压力和纹理上传耗时。
- 别用
top/left做位移动画：它们改变文档流位置，必重排；换成transform: translateX() -
opacity: 0不等于不可交互——它仍响应点击，要彻底移出交互流，得配pointer-events: none或visibility: hidden -
display: none或visibility: hidden切换会触发重排；若只是隐藏后还要频繁显示，opacity+pointer-events组合更稳
最常被忽略的一点：重排是否发生，不取决于你“有没有改样式”，而取决于浏览器是否能在当前帧内跳过 layout 阶段——这需要你把读操作集中、写操作批量、图层提升有节制、DOM 更新离线化。任何链式读-写-读操作，都在挑战浏览器的优化底线。
