原生Array.map方法为何性能远超自定义实现？

这是个非常好的问题！你的自定义toMap实现已经相当简洁高效了，但原生方法的性能优势其实来自JS引擎底层的多重深度优化，咱们一步步拆解清楚：

核心性能差异原因 #

1. 底层实现语言的本质区别 #

原生map方法是由JS引擎（比如Chrome的V8、Firefox的SpiderMonkey）用C++这类编译型底层语言实现的，直接操作内存和CPU指令，完全跳过了JS解释/编译的额外开销。而你的toMap是用JS写的，每一行代码都要经过JS引擎的词法分析、语法解析、字节码生成/解释执行这些流程，天然就有性能差距。

2. 函数调用开销被大幅压缩 #

你的实现里，每次循环都要执行cb.call(ctx, this[i], i, this)——这在JS里是一次完整的函数调用，涉及调用栈创建、上下文切换、参数传递的额外开销。而原生map可以把回调函数的执行和数组遍历做深度整合，甚至在很多场景下会把回调逻辑直接内联到遍历流程中，彻底省去函数调用的消耗。

3. 数组操作的底层优化 #

JS里的result.push()虽然是高效方法，但本质还是JS层面的方法调用。而原生map可以直接访问数组的底层存储结构（比如V8引擎里的「快速元素」存储），直接在内存层面扩容、填充元素，不需要经过JS的方法调用链路，速度提升非常明显。

4. 类型预判与针对性优化 #

JS引擎会对原生数组方法做大量类型预判优化：比如知道你遍历的是全数字数组（像你测试里的[10,10,10]），会用专门的数字数组处理逻辑；还能提前预判回调的返回值类型，优化结果数组的内存分配。而自定义实现里，引擎无法提前预知这些信息，只能做通用化处理，效率自然打折扣。

结合你的代码与测试数据看差异 #

自定义toMap实现 #

Array.prototype.toMap = function(cb, ctx) {
  if(typeof cb != 'function') { return }
  var result = [], len = this.length
  for(var i = 0; i < len; i++) {
    result.push(cb.call(ctx, this[i], i, this))
  }
  return result
}

测试代码 #

var myArr = [10, 10, 10], myObj = { addOne: function(n) { return n + 1 } }
myArr.toMap(function(value, key, array) { return this.addOne(value) }, myObj) // [11, 11, 11]

性能测试结果 #

从数据能看到，MDN的polyfill最慢——因为它要处理大量兼容性边界（比如稀疏数组、this不是数组的情况、回调异常处理等），额外开销更大；你的实现已经做了简化，但还是比原生慢2-3倍，完全符合上面说的几个核心原因。

内容的提问来源于stack exchange，提问作者Luis Felipe Zaguini