table布局、display:inline-block+vertical-align、浮动混用内联内容会直接触发高成本重排，因浏览器必须反复回溯计算：table单元格变长致全表重排；vertical-align依赖行高和基线，子元素高度变化即重算；float元素高度不一引发后续流式内容连锁重排。
哪些 HTML 结构会直接触发高成本重排
table 布局、display: inline-block + vertical-align、浮动元素混用内联内容——这三类结构不是“可能慢”，而是浏览器解析时必须反复回溯计算，一改就全量重排。比如一个 <table> 里某单元格内容变长，整行甚至整表都要重新测量宽度；<code>vertical-align: middle 的子元素高度稍有变化，父容器就得重算行高和基线位置。
真实场景中容易踩的坑：
- 把图标按钮写成 <span class="icon"></span><span>提交</span>，再加 vertical-align: top —— 文字换行或字号微调都可能引发局部重排
- 用 float: left 排多个卡片，卡片高度不一致时，后续流式内容定位依赖浮动清除逻辑，每次插入新卡片都可能连锁重排
- 在响应式布局中嵌套多层 <div> 且未设明确宽高，浏览器无法提前确定尺寸边界，导致 layout 阶段无法跳过计算<h3>DOM 插入/删除时怎么避免批量重排</h3>
<p>直接对 <code>document.body 连续 appendChild() 100 次，等于主动申请 100 次 layout；但用 DocumentFragment 收集后再挂载，只触发一次。这不是“建议”，而是现代浏览器渲染队列的实际行为边界。
实操要点：
- 新增节点：先 const frag = document.createDocumentFragment()，循环中 frag.appendChild(item)，最后 parent.appendChild(frag)
- 替换整块内容：优先用 el.replaceChildren(...nodes)（Chrome 120+ / Safari 17.4+），比先 el.innerHTML = '' 再拼字符串更安全、更可控
- 纯文本更新：一律用 el.textContent = str，innerHTML 会走 HTML 解析流程，哪怕 str 是纯文字
- 避免操作实时集合：document.getElementsByTagName('li') 每次访问都可能触发重排，应转成数组 [...document.getElementsByTagName('li')] 再遍历
为什么 class 切换比直接改 style 更轻量
el.style.left = '10px' 不是简单赋值，它绕过 CSSOM cascade 规则，强制标记样式树为 dirty，并在下一帧 flush 时参与 layout 计算；而 el.classList.add('is-moving') 只是切换一个匹配开关，所有样式由预编译好的 CSS 规则统一处理，浏览器能合并、延迟甚至跳过中间状态。
关键差异点：
- 内联 style 修改无法复用浏览器的 CSS 缓存，每次 setter 调用都触发 style 对象内部 dirty flag
- class 切换不改变 DOM 结构，只影响选择器匹配结果，渲染树更新粒度更小
- 动画中混用两者（比如先加 class 控制 transform，又手动设 el.style.opacity）容易破坏合成层一致性，导致本该走 GPU 合成的动画退回到主线程 paint
- 注意：class 必须提前在 CSS 中定义好全部状态，运行时不要靠 JS 动态插入 <style></style> 标签，那会触发全局样式重计算
哪些属性改起来根本不用重排，但常被误用
真正能避开 layout 阶段的只有 transform 和 opacity，前提是元素已提升为独立合成层。但很多人以为加了 transform: translateX(10px) 就万事大吉，忽略了图层前提。
容易忽略的细节：
- transform: translateX(10px) 和 transform: translateY(5px) 分两次设，第二次会覆盖第一次，还可能触发额外样式计算；应合并为 transform: translate(10px, 5px)
- 对未设宽高的 display: inline 元素直接加 transform，可能因 baseline 计算不稳定而意外重绘
- will-change: transform 是预告，不是开关；移动端建议用 transform: translateZ(0) 更稳妥，Safari 对 will-change 支持弱且易误触发
- 多个相邻动画元素，包裹进同一个容器并只对该容器提升图层，比每个子项都加 translateZ(0) 更省 GPU 内存
真正卡顿往往不出现在“做了什么”，而出现在“什么时候读、什么时候写”——比如在 requestAnimationFrame 回调开头读 getBoundingClientRect()，结尾才设 transform，这种读-写分离才是让合成层持续运转的底层约束。
