DOM操作本身不慢,慢的是触发的重排与重绘;优化关键是减少触发次数、合并操作、避开同步布局陷阱,如缓存节点、批量修改、避免读写交替、使用事件委托等。
DOM 操作本身不慢,慢的是它触发的浏览器渲染行为——每次修改都可能引发重排(reflow)和重绘(repaint),而这两者是主线程密集型任务。优化核心不是“少写 JS”,而是让浏览器更省力:减少触发次数、合并操作、避开同步布局陷阱。
DOM 查询(如 querySelector、getElementById)虽快,但反复调用仍消耗 CPU 且易引发意外性能问题。尤其在循环或高频回调中,未缓存的查询会叠加开销。
const header = document.getElementById('header');
getElementsByClassName 等返回实时集合(Live Collection)的方法——它们会在 DOM 变化时动态更新长度,导致循环跳项或死循环浏览器对连续的 DOM 写入有优化机制,但前提是“写完再读”或“集中写”。零散操作会迫使浏览器多次计算布局,而批量处理可压缩为一次重排。
document.createDocumentFragment() 在内存中构建完整结构,最后一次性挂载innerHTML(注意 XSS 风险,仅用于可信内容)style.xxx;或用 element.style.cssText = 'width:100px;height:200px;' 合并设置当 JS 读取布局信息(如 offsetHeight、getBoundingClientRect())后立刻写样式,浏览器必须立即计算当前布局——这打断了渲染流水线,造成“布局抖动”(Layout Thrashing)。
立即学习“Java免费学习笔记(深入)”;
requestAnimationFrame 包裹读写操作,确保在下一帧开始前完成el.style.display = 'none' 脱离渲染树,改完再恢复显示为大量子元素(如列表项、表格行)逐一添加事件监听器,不仅内存占用高,还增加初始化时间。利用事件冒泡,在父级统一处理更轻量、更易维护。
event.target 判断实际触发源event.target.closest('.item')