直接改HTML结构比调优CSS或JS更快见效，关键在于避开table布局、内联元素混用float、inline-block父容器含vertical-align子元素等强制同步回流的结构，以及读取offsetWidth后立即改样式等操作。
直接改 HTML 结构比调优 CSS 或 JS 更快见效——只要避开浏览器无法提前确定尺寸的布局模式，回流频率就能掉一个数量级。
哪些 HTML 结构会强制同步触发回流
这不是你 JS 写错了，而是结构本身让浏览器没得选。浏览器在 JS 执行中读取 offsetWidth、getBoundingClientRect() 等布局属性时，必须立刻 flush 排队中的样式变更，形成“读-改-读”循环。
-
<table>布局：任意<td>内容或样式变化，都可能触发整表重排，因为单元格宽度依赖同行其他单元格 - 内联元素混用
float：浮动脱离文档流，后续元素定位需反复回溯计算位置，尤其在父容器未清除浮动时 -
display: inline-block父容器含vertical-align子元素：对齐行为依赖行高、字体大小、兄弟元素高度，渲染时无法跳过几何计算 - 读取布局属性后立即修改样式：比如先取
el.offsetHeight，紧接着设el.style.width = '200px'，必然同步回流
用 transform 和 opacity 替代哪些 CSS 属性
这两个属性能走合成层（compositor layer），跳过主渲染线程的 layout 和 paint 阶段——但前提是元素已提升为独立图层（可通过 will-change: transform 或 transform: translateZ(0) 触发）。
- 用
transform: translateX(10px)替代left: 10px或margin-left: 10px - 用
transform: scale(1.2)替代直接改width/height - 用
opacity: 0替代visibility: hidden或display: none（注意：opacity: 0仍响应事件，需配pointer-events: none）
不适用场景：transform 不提供空间占位，无法替代 margin 的布局作用；opacity 不改变文档流，不能用于“彻底移出布局”的需求（比如侧边栏收起）。
立即学习“前端免费学习笔记（深入）”；
DOM 批量插入时怎么避免多次重排
向 document.body 连续追加 100 个节点，浏览器可能重排 100 次；一次性挂载，只触发一次。
- 新增多个节点：用
document.createDocumentFragment()收集，最后一次性appendChild()到目标父节点 - 替换整个区域：先
el.innerHTML = ''清空，再一次性写入完整 HTML 字符串，比逐个removeChild()+appendChild()更轻量 - 避免在循环中操作 live collection：
document.getElementsByTagName('div')是实时集合，每次访问都可能触发重排；应先转成数组[...document.getElementsByTagName('div')]再遍历 - 仅改文本内容时，优先用
textContent而非innerHTML——后者会触发 HTML 解析，哪怕字符串里没标签
为什么 class 切换比直接改 style 更安全
直接写 el.style.color = 'red' 看似简单，但每条赋值都可能触发重绘；更糟的是，如果同时改 width 和 height，浏览器无法合并优化，大概率触发两次回流。
- 把样式逻辑收敛到 CSS 类里，比如
.is-active、.is-hidden，再用el.classList.add('is-active')控制状态 - CSS 类声明是静态的，浏览器可提前解析并复用渲染路径，JS 只负责开关，不参与样式计算
- 类名切换天然支持批量变更：一次
classList.toggle()可能对应多个属性变更，但只算一次回流/重绘
真正容易被忽略的点在于：结构重构不是“让 HTML 更语义”，而是让浏览器在 layout 阶段有确定性——比如用 flex 或 grid 替代 table，不是因为前者“更现代”，而是前者尺寸可预测、回流范围可控。
