强制同步重排的HTML结构包括table布局、inline-block混用vertical-align、内联元素与float混用；应优先用transform: translate替代top/left、scale替代width/height、opacity: 0替代visibility/display隐藏，但需配合图层提升和pointer-events: none。
哪些 HTML 结构会强制同步触发重排
浏览器对某些结构“没法提前算尺寸”，一动就全盘重排，不是你 JS 写得慢，是结构本身逼它算。最典型的是：table 布局——改一个 td 的 border，整张表可能重排；inline-block 父容器里混用 vertical-align，对齐依赖兄弟元素高度和行高，每次读写都可能打断渲染队列；还有内联元素 + float 混用，浮动脱离流后，后续元素定位必须反复回溯。
这些结构没报错、能跑通，但只要你在 JS 里读 offsetWidth 或 getBoundingClientRect()，再顺手改个样式，浏览器就只能当场 layout —— 不是优化失败，是结构没给它留缓存机会。
用 transform 和 opacity 替代哪些属性更安全
这两个属性能走合成层（compositor），跳过 layout 和 paint 阶段，但前提是元素已提升为独立图层（比如加了 transform: translateZ(0) 或 will-change: transform）。实际替换时注意边界：
-
left/top→ 改用transform: translateX()/translateY() -
width/height→ 改用transform: scale()（注意：不占文档流空间） -
visibility: hidden或display: none→ 改用opacity: 0（但需配pointer-events: none才真正禁交互）
别硬套：transform 不能替代 margin 的占位作用；opacity: 0 不等于移出布局，该占的空间还在。
立即学习“前端免费学习笔记（深入）”；
批量 DOM 操作时怎么避免多次重排
向 document.body 连续 appendChild() 100 次，大概率触发 100 次重排。关键不是“少操作”，而是“让浏览器一次性处理”：
- 新增多个节点：用
document.createDocumentFragment()收集，最后只调一次appendChild() - 清空再重写区域：直接
el.innerHTML = ''，再一次性赋新 HTML 字符串，比循环removeChild()+appendChild()快得多 - 遍历实时集合（如
document.getElementsByTagName('div')）前，先转成数组：[...document.getElementsByTagName('div')]或Array.from()，否则每次访问都可能触发重排
仅改纯文本？用 textContent，别用 innerHTML —— 后者哪怕内容里没标签，也会触发 HTML 解析流程。
为什么改 className 比逐个设 style 更高效
浏览器有渲染队列机制：把一批样式变更暂存，等 JS 执行完再批量 flush。但只要你中间插一句读布局的代码（比如 el.offsetHeight），队列立刻清空、强制 layout —— 接着后面再改样式，又得重新排队、再 flush。
错误示范：el.style.width = '200px'; el.style.height = '100px'; console.log(el.offsetHeight); el.style.background = 'red'; → 至少两次重排。
正确做法是读写分离：
– 先读完所有需要的值（offsetHeight、getBoundingClientRect() 等）
– 再集中改样式，要么切 className，要么用 Object.assign(el.style, {...})
真正容易被忽略的点：display: none 是性能开关——元素彻底脱离渲染树，此时增删子节点、改 class、设 style 都不会触发重排；操作完再切回 display: block，比反复 layout 省得多。
