JS数组遍历怎么选？别再用forEach硬扛所有场景了

写前端代码，数组遍历是每天都在碰的基础操作。但每次面对一堆可选方案时，很多人还是习惯性顺手敲下forEach或传统的for循环。直到某次线上接口返回几万条数据直接卡死页面，或者重构时发现逻辑臃肿难维护，才意识到选错遍历方式，代价是性能瓶颈与后期维护成本的双重上涨。遍历没有绝对的最优解，只有最匹配当下业务场景的工具。

追求极致控制力与底层性能，还得回归传统for循环与for...of。如果你需要精确干预索引、提前终止遍历（break）或跳过当前项（continue），for循环依然是底层跑赢帧率的王牌。它不创建额外闭包，内存分配稳定可控。到了ES6之后，for...of凭借原生迭代器支持与语法简洁，逐渐成为替代forEach遍历纯数组的首选。它不仅能搭配break使用，还能配合解构赋值直接拆解复杂对象。这套组合拳适合对执行流程有强掌控力的底层逻辑，属于“我要完全控制每一步”的写法。

当代码重心转向数据流清洗与状态映射时，函数式遍历法更能提升可读性。forEach只负责执行副作用，不返回有效值，适合单纯打印日志、批量挂载DOM这类不需要新数据的操作。一旦需求变成数据形态转换，比如把扁平的用户列表拍平为带前缀的键值串，果断切到map。它天然契合不可变数据理念，始终返回全新数组，配合箭头函数能把转换逻辑压进一行。如果转换前还需要筛掉脏数据，filter能精准拦截无效项，避免map内部塞满丑陋的if守卫。这三者共享相似的上下文参数，但职责边界必须划清，混合使用只会让阅读者不断猜谜。

当数据需要从一维摊平成字典、分组统计或计算累积值时，reduce才是真正的全能中枢。别看它API短，内部承载的是整个遍历过程的状态机流转。通过维护一个累加器（accumulator），你可以轻松实现数组深层合并、DOM树结构拼接，甚至将多维坐标压缩成哈希表。它的门槛在于理解“上一次回调的返回值就是下一次的第一参数”。实战中务必显式声明初始值类型，并确保每次回调返回的结构保持一致，这样后续链式调用才不会突然断链或类型飘移。

很多新手习惯把for...in当成万能钥匙，这往往是埋雷的开始。它的设计初衷是遍历对象的可枚举属性，放到数组上会按字符编码顺序提取键名，还可能意外捞到原型链上继承的属性。日常处理数组请彻底弃用它。此外，面对超大规模数据集时，频繁让map或filter创建新数组会导致内存碎片化，触发频繁的垃圾回收（GC）。此时应优先考虑原地修改（如直接赋索引值）或使用生成器（Generator）分块yield数据，而不是盲目依赖高级API堆砌代码。

遍历方法的本质，是开发意图的翻译器。读数据保控制权选for...of，改数据求纯净用map/filter，聚合归并向量推给reduce，要打断点控流程就回到基础循环。把工具放回合适的场景，代码自然清爽。下次面对空数组发呆时，不妨先问自己：这次遍历到底想交付什么结果？答案往往已经藏在对应的API设计哲学里了。