map用于一对一转换元素并保持数组长度不变,filter用于按条件筛选元素且返回数组长度不大于原数组;二者设计目的不同,不可互相替代,混用易导致逻辑错误或性能浪费。
map 和 filter 都会返回新数组,但目的完全不同:一个用来「转换」每个元素,另一个用来「筛选」符合条件的元素。用错会导致逻辑错误或性能浪费。
map?当你需要把原数组的每个元素按规则变成另一个值,并保持数组长度不变时,就用 map。它不关心条件,只做一对一映射。
['1', '2', '3'] 转成 [1, 2, 3];对象数组提取某个字段生成新数组map 的回调函数必须有返回值,否则新数组里对应位置是 undefined
return,比如 arr.map(x => { x * 2 }),结果全是 undefined
const nums = ['1', '2', '3']; const parsed = nums.map(x => parseInt(x, 10)); // [1, 2, 3]
filter?当你只想留下满足某个条件

filter。它返回的数组长度 ≤ 原数组长度。
'active' 的用户true 的元素被保留,false 或假值(如 0、null)会被丢弃filter 里做数据转换——那是 map 的活,混用容易出 bugconst numbers = [5, 12, 8, 130, 44]; const bigNumbers = numbers.filter(x => x > 10); // [12, 130, 44]
因为它们的设计契约不同:map 强制产出等长新数组,filter 强制做布尔判断并可能缩容。强行用一个模拟另一个,代码会难读且易错。
map 模拟 filter:得配合 flat() 或额外过滤 undefined,多一层间接filter 模拟 map:做不到——它不提供转换能力,只能留或删arr.filter(...).map(...) 是先筛再转;反过来则可能对无用数据做无效计算两者都不修改原数组,但都依赖回调函数的纯度。如果回调里改了外部变量、发起请求或操作 DOM,行为就不可预测了。
map 和 filter 都跳过稀疏数组的空位,比如 [1, , 3] 中间那个空位不会触发回调babel 或手写兼容逻辑filter + map)比一次 reduce 稍慢,但可读性优先真正卡住人的往往不是语法,而是没想清楚:我要的是“换一批东西”,还是“挑一些东西”。选错方法,后面所有逻辑都会偏一拍。