为何JS中数组字面量与ArrayBuffer的创建性能差距如此悬殊？

我来帮你拆解下这个性能差异的核心原因，你的测试结果其实完全符合JS引擎的内存模型逻辑，之前的认知偏差主要是没分清两者的设计定位和开销点：

1. 内存分配的本质天差地别 #

你测试里的new Array()创建的是一个动态稀疏数组容器——初始状态下它几乎没分配实际内存，JS引擎只会给它一个极小的初始容量，等后续添加元素时再按需扩容。而new ArrayBuffer(LIMIT * 4)是直接向系统申请了一块固定大小的连续二进制内存块（这里是40KB），每次循环都要完成实打实的内存申请、初始化操作，这本身就是开销更大的系统级调用，自然比空数组创建慢很多。

2. TypedArray多了一层封装开销 #

你的测试中还额外实例化了Int32Array(buffer)——这个TypedArray对象需要维护对底层ArrayBuffer的引用、字节偏移、长度等元数据，相当于在原始内存块上套了一层类型化的访问接口，这也会增加每次创建的成本，而普通数组的创建逻辑要简单直接得多。

3. 测试场景不对等，放大了差异 #

你的测试其实存在场景不对等的问题：普通数组是创建空容器，而TypedArray那边是创建了带40KB内存的缓冲区，两者的“工作量”根本不在一个量级。如果把普通数组改成创建同样大小的数组（比如new Array(LIMIT).fill(0)），你会发现差距会缩小，但TypedArray还是会慢一点——因为内存模型的差异依然存在。

4. TypedArray的优势在数据操作阶段 #

你之前觉得TypedArray更快，其实是在数据读写、计算的阶段：当你需要处理大量数值型数据时，TypedArray直接操作二进制内存，不需要像普通数组那样做隐式类型转换、动态扩容，这时候它的性能优势才会凸显出来。比如循环填充数据、数学运算等场景，TypedArray会比普通数组快很多。

给你一个修正后的测试例子，可以更直观看到差异：

var LIMIT = 10000;

// 测试空数组创建
console.time("Empty Array");
for (var i = 0; i < LIMIT; i++) {
    var arr = new Array();
}
console.timeEnd("Empty Array");

// 测试同大小TypedArray创建
console.time("TypedArray");
for (var i = 0; i < LIMIT; i++) {
    var arr = new Int32Array(LIMIT);
}
console.timeEnd("TypedArray");

// 测试数据填充性能
console.time("Array fill");
var arr = new Array(LIMIT);
for (var i = 0; i < LIMIT; i++) {
    arr[i] = i;
}
console.timeEnd("Array fill");

console.time("TypedArray fill");
var arr = new Int32Array(LIMIT);
for (var i = 0; i < LIMIT; i++) {
    arr[i] = i;
}
console.timeEnd("TypedArray fill");

运行后你会发现，填充数据阶段TypedArray的速度会反超普通数组，这才是它被设计出来的核心场景——比如WebGL渲染、Worker线程高效传数据、二进制文件处理等。

简单总结：创建阶段的慢是因为内存分配和封装的额外开销，而TypedArray的真正优势在于大量数值数据的操作效率，这也是它作为可转移类型在Worker间传递的价值所在——内存直接转移，不需要复制，大幅提升跨线程数据传递的性能。

内容的提问来源于stack exchange，提问作者user6465431354