别再把 forEach 当 map 用了：数组遍历到底该选谁？

刚接手老项目维护的开发者，十有八九都踩过同一个坑：在数组方法里加了点业务逻辑，跑起来却报 undefined 或者数据结构多套了一层。仔细一查，通常是对 forEach 和 map 的用途产生了错位理解。这对长得极像的双胞胎方法，底层设计哲学早已分道扬镳。理清它们的边界，能直接砍掉日常开发中近半数的隐式类型错误。

最直观的分水岭，在于返回值机制。forEach 是个只负责执行、不打算交差的“分发员”。它的核心职责是完成遍历并允许产生外部副作用（例如修改全局状态、操作 DOM 或执行异步请求）。无论回调函数内部写了什么，它永远默认吐出 undefined。而 map 天生是个“转换器”，它会严格遵循你的处理逻辑，等长返回一个全新的数组对象。很多同学在回调里顺手 return 了映射结果，却误以为拿到了旧数组的引用，结果后续操作全部扑空。牢记这条底层规则：要派生新数据流，用 map；只想对当前集合施加影响，用 forEach。

使用场景的差异，直接决定了代码的可维护性。面对数据清洗任务，比如将后端返回的扁平列表抽取指定字段重组，或给金额追加固定后缀，map 能让意图在视觉上保持声明式整洁。链式组合也是它的主场特性，可以无缝衔接 filter、sort 甚至 reduce 构建处理管道。如果强行把 forEach 扔进链式调用，整个数据流会在此处彻底断裂。现代前端框架普遍推崇不可变数据理念，此时 map 不仅能避免意外污染原始状态，还能让 Diff 算法精准识别变更范围；反之，若仅用于批量触发网络请求或逐条落盘缓存，硬上 map 反而会无谓地分配一块闲置内存，徒增垃圾回收开销。

落地到实际编码，怎样快速决策？抓住两个判断锚点即可。第一，下游是否依赖新生成的数组结构。涉及 UI 组件渲染源数据准备、状态库（Vuex/Pinia/Redux）的纯函数 reducer，优先锁定 map。第二，核心诉求是否仅为遍历执行本身。像按序上报埋点事件、逐个初始化插件实例这类任务，forEach 的代码动线更直白，阅读阻力更低。值得补充的细节是，两者默认都会跳过稀疏数组的空缺位置，若业务强依赖严格索引对齐，改用带索引参数的原生循环或 for...of 会更可控。

数组遍历从来不是纠结语法的单选题，而是意图传递的判断题。把 map 安放在数据流转的节点上，把 forEach 留给动作执行的出口，代码的演进路径会清晰许多。下次在方法调用前稍微停顿半秒，自问一句“我此刻需要的是产出的结果，还是完成的动作”，选型障碍自然消散。