触发重排的css属性包括width、height、padding、margin、border、top、left、position、display、font-size、line-height等；读取offsettop等api会强制同步布局；应避免读写混用，优先使用transform和opacity。
哪些 CSS 属性会触发重排（reflow）
重排是浏览器重新计算元素几何属性（位置、尺寸）的过程，开销极大。只要修改了影响布局的属性，就会触发整个渲染树中相关节点的重排。
常见触发重排的属性包括：width、height、padding、margin、border、top、left、position、display、font-size、line-height 等。尤其是读取 offsetTop、clientWidth、getBoundingClientRect() 这类“强制同步布局” API 时，如果前面有未提交的样式变更，浏览器会立刻 flush style 并重排。
- 避免在循环中反复读写：比如
for循环里先改div.style.width，再读div.offsetWidth，每次都会触发一次重排 - 把读操作集中到写操作之前或之后，形成“读-读-写-写”模式，而非“读-写-读-写”
- 用
transform和opacity替代top/left或visibility实现位移/显隐，它们只触发重绘（repaint）甚至合成（compositing），不触发重排
如何用 will-change 提前告知浏览器优化意图
will-change 是一个提示性 CSS 属性，告诉浏览器某个元素即将发生变化，建议提前为其创建独立图层或启用硬件加速。但它不是“开关”，滥用反而增加内存开销和管理成本。
- 只对明确会频繁动画的元素设置，例如：
will-change: transform;或will-change: opacity; - 不要在父容器上盲目加
will-change: transform，尤其当子元素数量多时，会导致大量图层分裂 - 动画结束后建议通过 JS 移除该属性（如
el.style.willChange = ''），避免长期占用资源 - 它无法替代正确的动画策略，比如用
requestAnimationFrame批量更新 + 合理使用transform才是根本
为什么 transform 和 opacity 更快
这两个属性被浏览器专门优化过：它们不改变文档流、不影响其他元素布局，且通常能落到单独的合成层（compositor layer），由 GPU 直接处理，跳过了主线程的样式计算、布局和绘制流程。
立即学习“前端免费学习笔记（深入）”；
/* 推荐：只触发合成 */
.element {
transform: translateX(10px);
opacity: 0.8;
}
<p>/<em> 避免：触发重排+重绘 </em>/
.element {
left: 10px;
visibility: hidden;
}-
transform: translateZ(0)或transform: translate3d(0,0,0)可强制提升为合成层，但仅在必要时使用（如解决闪烁、z-index 异常） - 注意：过度提升图层会导致内存暴涨和纹理上传开销，Chrome DevTools 的
Layers面板可直观查看图层数量 -
opacity动画必须确保元素已处于自己的合成层，否则仍可能触发重绘；若背景复杂，可配合isolation: isolate明确隔离
JS 操作 DOM 时怎样最小化布局抖动
所谓“布局抖动（layout thrashing）”，就是 JS 在同一帧内反复触发读-写-读-写模式，导致浏览器多次强制同步计算样式与布局。
- 批量读取：用
getComputedStyle(el)一次性获取所有需要的值，而不是反复调用el.offsetHeight等 - 批量写入：把多个样式修改合并成一次
el.style.cssText = '...'，或使用Object.assign(el.style, {...}) - 异步更新：用
requestAnimationFrame将写操作统一调度到下一帧开始前，确保浏览器有完整时间做优化 - 避免在
scroll或resize中直接操作样式，务必节流（throttle）并分离读写逻辑
最隐蔽的问题是：哪怕你只改了一个 className，只要这个 class 里包含 width 或 display，就可能引发重排——所以优化不能只看 JS，CSS 定义本身也得审慎。
