别让浏览器“喘不过气”：JS DOM 操作性能优化的实战心得

你有没有遇到过这种场景：页面上有个长列表需要批量更新，代码跑起来逻辑没错，可浏览器突然卡死几秒，甚至手机发烫？这时候，问题往往不在业务逻辑，而在我们如何与 DOM 交互。

浏览器渲染页面不是静态的画板，每次修改元素都可能触发重排（Reflow）和重绘（Repaint）。想象一下，你正在整理房间，每动一个摆件，整个房间的布局都要重新计算一次，这显然效率极低。在频繁操作的循环中，这种做法会让主线程不堪重负。

很多新手习惯在循环里直接创建节点并插入。如果循环运行一千次，就意味着浏览器要准备处理一千次潜在的布局计算。把 DOM 操作集中起来，能大幅减少这种开销。更优的方案是使用 DocumentFragment。它像是一个临时的离线工作区，你可以在里面随意组装节点，只有当最终把这个碎片挂载到真实文档时，浏览器才会一次性进行渲染。这种“先离屏构建，后统一提交”的思路，是提升列表渲染速度的经典手段。

另一个容易被忽视的细节是选择器的缓存。在一开始看到很多人喜欢写 const btn = document.getElementById('btn') 放在函数开头，但有时为了省事，会在事件回调里反复调用查询方法。哪怕 getElementById 很快，如果在高频触发的回调或循环中重复执行，依然是在做无用功。把 DOM 引用保存在变量里，后续直接使用内存中的引用，避免浏览器反复遍历 DOM 树查找目标，这是成本最低但收益明显的优化。

事件绑定也是性能杀手。如果你为一个拥有上百个项目的列表，在每个子项上单独绑定点击事件，不仅占用大量内存，清理时也容易出错。事件委托利用冒泡机制，只需在父容器上监听，就能统一管理所有子元素的操作。这不仅减少了注册次数，还能让动态添加的新元素自动继承事件，无需额外处理。

关于布局抖动，这里有个隐蔽的坑：混合读写操作。当你刚读取了一个元素的 offsetWidth，紧接着又设置它的 style.width，浏览器为了保证返回值的准确性，必须强制刷新当前的布局信息。如果在循环里交替进行读和写，就会引发连续的布局同步，导致严重卡顿。将所有的读操作集中在一段，所有的写操作集中在另一段，中间隔开，能让浏览器放心地合并多次请求，只在最后统一计算一次。

样式控制方面，尽量通过操作 CSS class 来改变外观，而不是直接读写 style 属性。维护一套预定义的类名，比手动拼接字符串修改 inline style 更高效，也便于利用浏览器的样式缓存。对于不可见的元素，使用 visibility: hidden 保留占位，而用 display: none 直接移除布局参与，根据需求选择，避免不必要的重排。

最后提醒一点，不要过度优化。工具永远是最好的老师，打开浏览器的 Performance 面板录制操作，查看具体的耗时分布。有些所谓的优化可能微乎其微，反而增加了代码复杂度。只有在瓶颈处下手，才是真正有效的性能工程。记住，流畅的用户体验才是检验优化的唯一标准，而非单纯的代码行数。