table、inline+float混用、inline-block配vertical-align三类HTML结构会立刻触发强制重排，因浏览器无法跳过layout计算，改td整表重排、加浮动回溯整行、vertical-align依赖兄弟高度需逐个计算。
哪些 HTML 结构会立刻触发强制重排
不是所有结构改动都“看起来慢”，但 table、inline + float 混用、inline-block 父容器配 vertical-align 这三类，浏览器根本没法跳过 layout 计算——改一个 td 就整表重排，加一个浮动元素就回溯整行位置，子元素对齐依赖行高和兄弟高度，渲染时必须逐个算。
常见错误现象：table 里动态插入一行后卡顿明显；span 套 float: left 后，后面文字位置反复跳动；父元素设 display: inline-block，子元素用 vertical-align: middle，滚动时偶发抖动。
- 能不用
table布局就不用，展示数据用div+ CSS Grid/Flex 替代 - 避免
inline元素直接加float，改用display: flex或display: grid -
inline-block容器内若需对齐，优先用flex-align或grid，而非vertical-align
为什么 class 切换比直接改 style 更不容易重排
element.style.color = 'red' 是立即写入 style 对象，触发样式 dirty 标记，浏览器得马上检查 cascade 规则是否被破坏；而 element.classList.add('highlight') 只是变更匹配状态，所有样式逻辑收口在 CSSOM，浏览器可批量合并、延迟计算，甚至跳过未影响布局的更新。
使用场景：频繁开关状态（如 hover、选中、加载态）、动画起停、响应式断点切换。
立即学习“前端免费学习笔记（深入）”；
- 预定义 class 里不要混用重排属性（比如同时写
width和opacity），把 layout 相关和合成相关属性拆开 - 避免在同一个帧里既
classList.add()又手动设style.transform，可能破坏图层一致性 - 旧版 IE 对
classList支持弱，可用className字符串拼接兜底，但注意空格处理
批量 DOM 插入时 DocumentFragment 不是银弹
document.createDocumentFragment() 确实能合并多次 appendChild 成一次重排，但它只解决“插入”问题——如果 fragment 里每个节点都带内联 style 或没设宽高，浏览器仍得逐个计算 layout；更糟的是，fragment 本身不参与渲染树，里面节点的 offsetWidth 读出来是 0。
性能影响：大量 fragment 创建+挂载本身有内存开销；若 fragment 节点后续还要频繁读写尺寸，不如先挂载到 display: none 的离线容器里再操作。
- 先创建空
div，设style.display = 'none'，appendChild 所有节点，再一次性移到目标位置 - 仅替换文本内容时，用
textContent，别用innerHTML——后者会触发 HTML 解析，哪怕字符串里没标签 - 现代浏览器支持
replaceChildren()，适合整块替换，但注意兼容性：Safari 17.4+、Chrome 120+ 才稳定
transform 和 opacity 为何有时还是卡
这两个属性确实走合成层，但前提是元素已提升为独立图层。没提升时，transform 只是重绘；提升失败或图层过多时，GPU 内存压力大、纹理上传耗时，反而比原生 layout 更慢。
容易踩的坑：盲目加 will-change: transform，或对静态图标也加 translateZ(0)；多个相邻动画元素各自提升图层，而不是共用一个容器提升；inline 元素直接加 transform，因 baseline 不稳定导致意外重绘。
- 移动端优先用
transform: translateZ(0)，Safari 对will-change支持弱且易误触发 - 提升图层后元素行为类似
position: absolute，若布局错位，检查是否依赖了原本的文档流位置 - 用 Chrome DevTools 的 Layers 面板验证图层是否真提升成功，别只看代码写了没
transform 就自动优化，它只认你是否给了它可预测的执行路径。 
