HTML DOM与JS性能优化实用方法

先说结论：DOM 操作本身其实并不慢，但它就像一把工具——用对了顺手，用错了就卡。真正拖垮 JavaScript 性能的不是 DOM 节点，而是代码的调用时机、执行频率和操作方式。问题的根源在于“怎么读取”和“怎么写入”。

如果你在 DOM 操作上吃过亏，下面这几个常见陷阱应该不陌生。

getElementById 反复调用，为什么越来越慢

每次调用 document.getElementById 并不是从缓存中读取数据——它需要重新遍历整棵 DOM 树，再根据 ID 进行匹配。如果把这个方法放在循环里，或者挂载在 scroll、mousemove 这类高频事件中，相当于让浏览器在成千上万个节点里反复“翻山越岭”。

• 正确做法： 只查询一次，将结果存入变量。例如 const modal = document.getElementById('modal')，后续直接使用该引用。
• 常见错误： 在 for 循环中逐次调用，特别是同时搭配 offsetTop 或 getBoundingClientRect()——这会造成“双重打击”。
• 性能影响： 在中端设备上实测，100 次重复调用比缓存慢了 3 到 8 倍。更隐蔽的影响是可能引发“布局抖动”，导致主线程陷入“就绪-卡顿-就绪-卡顿”的恶性循环。

innerHTML 与 createElement，如何选择

这个问题没有绝对答案，关键取决于场景。浏览器对两者都有深度优化，但副作用和触发时机完全不同，不能一概而论。

• innerHTML： 更适合纯展示型批量插入，例如搜索结果列表。V8/Blink 对字符串解析有专门加速，插入 1000 个
  通常能快 2–5 倍。
• 弊端： 它会清空原有事件监听器、丢失 的用户输入、甚至重置整个表单状态。这是一种“大换血”的操作。
• createElement + DocumentFragment： 更安全可控。适合包含交互逻辑的动态节点，例如带按钮、需要绑定事件的卡片。使用 DocumentFragment 一次性挂载，可以避免“逐次插入逐次重排”。
• 反面教材： 单独用 appendChild 循环插入 100 次，就会触发 100 次潜在重排——浏览器被迫在每个循环里重新计算布局。

读写布局属性，为什么拖垮主线程

像 offsetHeight、getComputedStyle()、scrollLeft 这类 API，相当于“强制同步布局”的开关。只要读取一次，浏览器就必须立即停下所有待处理的样式计算和重排（reflow），然后返回结果。

• 错误模式： 在 for (let i = 0; i < ...; i++) 中，每轮都读取 element.offsetHeight——等于每轮都强制刷新布局。
• 正确模式： 采用“读-写分离”策略。先遍历一遍，将所有 offsetHeight 缓存到数组中；再遍历一遍，一次性写入 style。这样浏览器只需一次重排。
• 小技巧： 如果临时需要读取尺寸，可以先将元素设为 display: none，读取后再恢复。这能避免连续触发重排，且读取的数据不受当前渲染时机影响。

事件委托，真的能提升性能吗

不一定。事件委托可以减少监听器数量，但使用过度反而会增加 CPU 开销。

• 合理场景： 在
  上监听 click，用 e.target.classList.contains('item-btn') 判断目标——层级清晰，匹配简单。
• 高危操作： 挂在 document 上，又在 handler 里反复调用 e.target.closest('.action') 或 e.target.parentElement.querySelector('.meta')——这相当于把 800 个节点的遍历任务塞进了高频事件中。
• 性能关键点： 委托层级越浅越好，优先选择最近的公共父级。匹配逻辑越简单越好，classList.contains 通常比 matches() 更快。
• 重要提醒： 对于高频事件（scroll、mousemove），必须添加 throttle 或 requestAnimationFrame 节流，否则 JavaScript 主线程会被直接占满。

总结来看，真正导致卡顿的从来不是 DOM 节点本身，而是不断打断浏览器渲染节奏的操作——读布局、改样式、插节点、再读布局……这种“一步一停”的模式，才是重排和重绘泛滥的根源。理顺操作节奏，性能自然就提升了。