别让几行代码卡死页面：JS 数组操作性能避坑指南

你有没有过这种经历？前端页面数据量一旦过千，滚动条一拉，CPU 直接飙红，用户体验瞬间掉线。很多时候，罪魁祸首不是框架，而是我们习以为常的数组操作。今天不聊虚的，直接聊聊怎么把那些藏在代码里的性能“刺客”揪出来。

很多人为了代码简洁，习惯了用 forEach 或 map 处理逻辑。但在高频触发场景下，比如大数据列表计算或实时渲染，传统的 for 循环依然拥有统治力。这是因为匿名回调函数每次调用都会产生额外的栈帧开销，而现代浏览器对标准 for 循环做了极致的内联优化。如果必须遍历长数组，哪怕少封装一层函数，性能差异都可能达到数量级。哪怕只是简单的累加计数，老派写法往往比现代语法快上几倍。

说到修改原数组，splice 堪称重灾区。它不仅是 O(n) 的时间复杂度，还会强制移动后续所有元素的索引位置。如果你频繁在头部插入或移除元素，页面必然卡顿。尝试过先将数组反转，利用尾部操作的 push/pop 完成逻辑，最后再反转回来吗？这样能把昂贵的索引移位成本降到最低。更重要的是，在处理超长列表时，尽量避免在循环体内动态改变数组长度。V8 引擎会对连续增长的数组建立隐藏类，一旦类型不稳定或长度剧烈波动，优化策略就会失效，代码被迫回退到慢速的解释执行模式。

另一个隐蔽的坑在于链式调用。特别是在做搜索过滤时，滥用 filter、map、reduce 组合会导致多次中间数组生成。想象一下 list.filter().map().filter() 这样的链式写法，每经过一步，浏览器就要开辟一块新内存来存临时结果。能合并逻辑的就别拆分，直接在单个循环里完成筛选和映射，既复用了变量，又大幅减少了 GC（垃圾回收）的负担。对于已知大小的数据，使用 new Array(len).fill(0) 初始化比循环 push 更高效，因为预分配内存避免了运行时的动态扩容重排。

排序操作也藏着玄机。array.sort() 默认会将元素转为字符串比较，这在数字排序时会闹出 10 < 2 的笑话。更致命的是，自定义排序函数的返回值如果不规范（非稳定返回 -1、0、1），排序算法内部逻辑会紊乱，消耗大量 CPU 周期去猜测意图。务必保证比较函数的一致性，否则复杂度的提升可能让你的页面陷入假死状态。

当然，优化永远要有度。没有数据的支撑就盲目重构，往往是另一种形式的浪费。在真正感觉卡顿之前，先用 Chrome DevTools 的 Performance 面板抓一下火焰图。很多时候，瓶颈不在算法本身，而在重复渲染或不必要的内存泄漏。记住，性能是测出来的，不是猜出来的。只有当问题真实存在时，这些技巧才能转化为实实在在的流畅体验，让代码既优雅又轻盈。