JavaScript数组迭代方法性能差异关键在于避免冗余计算、副作用和内存浪费：map适用于纯转换，filter应前置以减少后续操作数据量，reduce适合累积逻辑而非简单任务，forEach适合简洁副作用遍历，for循环在性能敏感场景更优。
JavaScript 数组迭代方法的性能差异，主要不在于“谁更快”，而在于“谁做了不该做的事”。选错方法会引入冗余计算、意外副作用或内存浪费，这才是真实影响性能的关键。
map：纯转换才高效，混用逻辑反拖慢
map 的设计目标明确：对每个元素做无副作用的转换，返回等长新数组。它内部必然分配新内存，且必须遍历全部元素。
- ✅ 合理使用：
prices.map(p => p * 0.9)或users.map(u => ({ id: u.id, name: u.name })) - ❌ 低效误用：在 map 回调里写
if (u.active) return u.name，结果产生[undefined, 'Bob', undefined]——这实际需要的是filter().map()链式调用，单独用 map 不仅语义错，还白建了无效项 - ⚠️ 注意：若只需遍历并触发副作用（如发请求、改 DOM），用
forEach或for...of更轻量，避免无意义的新数组开销
filter：提前过滤能省下后续所有操作
filter 本身性能开销不大，但它的位置极大影响整体效率。它返回子集，长度 ≤ 原数组，因此越早调用，后面操作处理的数据就越少。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- ✅ 推荐顺序：
data.filter(isValid).map(transform).reduce(merge)—— 先筛掉 70% 无效数据，后面 map 和 reduce 就只跑 30% 的量 - ❌ 反模式：
data.map(enrich).filter(isReady)—— 对全部元素先执行耗时的enrich（比如查接口、解析 JSON），再丢弃其中大部分，白白浪费资源 - ⚠️ 常见陷阱：回调返回
u.status但u.status是undefined，被当falsy过滤掉；应改用u.hasOwnProperty('status') && u.status === 'active'
reduce：功能强但开销高，别为简单任务硬套
reduce 灵活性最高，但也最重：每次迭代都需维护累加器状态，且无法短路退出。它适合真正需要累积逻辑的场景，而非替代更专用的方法。
立即学习“Java免费学习笔记（深入）”；
- ✅ 合理场景：求和、分组统计
{type: [...items]}、扁平化嵌套数组、构建索引对象{id: item} - ❌ 过度使用：
arr.reduce((found, x) => found || x > 10, false)—— 完全等价于arr.some(x => x > 10)，后者可短路、语义清、性能更好 - ⚠️ 关键细节：必须传初始值（尤其空数组时），避免
TypeError；避免在回调中直接修改acc对象（如acc.push()），应返回新对象/数组以保纯度
forEach vs for 循环：简单遍历谁更优？
forEach 是语法糖，底层仍需函数调用开销；传统 for 循环控制粒度更细，无额外调用栈。
- ✅ 用 forEach：逻辑清晰、代码简洁、无需手动管理索引，适合大多数副作用遍历
- ✅ 用 for：高频小数组（如 UI 渲染列表）、性能敏感路径（如游戏循环）、需中途
break或continue - ⚠️ 注意：
for...of读取便利但比for略慢；for (let i = 0; i 比 <code>for (let i = 0; i 多一次属性访问，可缓存 <code>len = arr.length
