DOM查询本身不触发重排，但读写混用会引发强制同步重排；优化需分离读写、缓存节点、批量更新、用CSS类替代内联样式。
在大型页面中，DOM 查询本身不会直接触发重排或重绘，但**紧随其后的写操作或不当的读写混用会立刻引发强制同步重排**。关键不是“查得多”，而是“查完马上改、改完又查、边查边改”。优化核心是：分离读写、缓存结果、批量变更、避免布局抖动。
缓存高频查询结果，杜绝重复查找
每次调用 document.getElementById、querySelector 或 getElementsByClassName 都需遍历 DOM 树，开销虽小，但在循环、事件回调或动画帧中反复执行，会叠加成显著延迟。更重要的是，若后续立即修改该元素样式或结构，就为重排埋下伏笔。
- 把复用的节点提前存为常量，例如：
const header = document.querySelector('.page-header'); - 对动态生成的列表容器、表单区域等，统一在初始化阶段获取并挂载到模块作用域，不放在函数内部反复查
- 避免在
for循环里写document.getElementById('item-' + i)—— 改为先查父容器，再用children或querySelectorAll一次性获取全部子项
读写分离：避免强制同步重排
浏览器为了返回准确的几何值（如 offsetHeight、getBoundingClientRect()），会在你读取时“刷新渲染队列”，强制执行一次未完成的重排。如果之前刚改过样式，这个读操作就成了性能杀手。
- 不要这样写：
el.style.width = '200px'; console.log(el.offsetWidth);—— 第二行会触发同步重排 - 正确做法：所有样式修改集中进行；所有布局读取集中进行。例如先批量设
style或加 class，再统一读取所需尺寸 - 若必须在动画中读取，用
requestAnimationFrame包裹读操作，确保它发生在浏览器计算完布局之后
批量更新 DOM，用 DocumentFragment 或 innerHTML 代替逐个插入
向一个已有容器追加 100 个节点，如果用 100 次 appendChild，就会触发最多 100 次重排。本质问题是“操作太碎”，而非“查得太多”。
立即学习“Java免费学习笔记（深入）”；
- 用
document.createDocumentFragment()在内存中组装完整结构，最后只调用一次parent.appendChild(fragment) - 对纯静态内容（无事件绑定、无引用需求），拼接 HTML 字符串后赋给
innerHTML，比创建元素快得多，且仅触发一次重排 - 对已有大块内容做复杂更新，可先
element.remove()或设display: none，修改完毕再恢复 —— 让浏览器跳过中间状态的渲染
用 CSS 类控制样式，少碰内联 style
频繁设置 element.style.color、element.style.margin 等，不仅代码冗长，每次赋值都可能触发重排（尤其涉及盒模型属性）。更糟的是，多个连续赋值会让浏览器反复计算样式。
- 把样式逻辑抽象成预设类名，如
.is-loading、.has-error，用element.classList.toggle()切换 - 若需动态样式，优先通过
cssText一次性写入，或使用CSSStyleSheet.insertRule动态注入规则 - 避免在循环中读写同一元素的多个样式属性 —— 它们可能互相触发重排链
