从V8引擎视角看JavaScript数组性能陷阱。

JavaScript 数组看起来是最基础的数据结构，但在 V8 引擎里，它其实是一套精密而“记仇”的对象系统。你写的每一行 `push`、`delete`、`arr[10000] = x`，都可能让数组的内部表示发生一次不可逆的降级。多数时候代码还能跑，只是从“飞快”变成了“能跑”。理解这些陷阱，不是为了炫技，而是为了避免在热路径上无意间写出慢代码。

数组不是数组：先理解 Elements Kind

V8 为数组维护了所谓的 `elements kind`，常见的有：

- `PACKED_SMI_ELEMENTS`：紧凑的小整数数组
- `PACKED_DOUBLE_ELEMENTS`：紧凑的双精度浮点数数组
- `PACKED_ELEMENTS`：紧凑的通用对象数组
- `HOLEY_*`：带空洞的版本

这些类型之间是单向阀门：`SMI -> DOUBLE -> ELEMENTS`，`PACKED -> HOLEY`。你可以让数组“降级”，但很难让它“升级”回去。V8 之所以区分它们，是为了在 SMI 和 DOUBLE 场景下使用未装箱的连续内存，减少指针跳转和内存分配。

陷阱一：混合类型导致隐式降级

看一段很常见的代码：

const arr = [1, 2, 3]; // PACKED_SMI_ELEMENTS
arr.push(1.5);         // 变成 PACKED_DOUBLE_ELEMENTS
arr.push('hello');     // 变成 PACKED_ELEMENTS

从 `push('hello')` 那一刻起，这个数组的存储方式就彻底变了。后续即使你再塞入整数，它也不会回到 SMI 或 DOUBLE。V8 仍然会正确执行，但每次读写都可能涉及装箱、类型检查和更宽的对象槽。

建议：如果数组语义上就是数字集合，不要让字符串、对象、`undefined` 混进来。需要多态时，考虑用对象数组或分开存储。

陷阱二：空洞与稀疏数组

`new Array(1000)` 并不会创建一个装满 1000 个 `undefined` 的紧凑数组，而是创建一个长度为 1000 的 `HOLEY_SMI_ELEMENTS` 数组。空洞意味着 V8 在许多操作中必须额外判断“这个位置到底有没有值”。

更隐蔽的是：

const arr = [];
arr[2] = 'x'; // 前面留下空洞，变成 HOLEY_ELEMENTS
delete arr[0]; // 删除也会制造空洞

还有 `delete arr[i]`，它不仅制造空洞，在大量删除时还可能把数组推向字典模式。字典模式适合稀疏存储，但遍历和索引速度会明显下降。

如果你确实需要初始化固定长度，优先用：

const arr = Array.from({ length: 1000 }, () => 0);

或者先 `[]` 再 `push`，让 V8 保持紧凑。注意 `new Array(1000).map(() => 0)` 并不会填入 0，因为 `map` 会跳过空洞。

陷阱三：越界写入与 length 操作

在空数组上执行 `arr[100000] = 1`，V8 不会傻乎乎地分配 10 万个槽位，而是转向字典模式。之后即使你只操作前几个元素，也可能享受不到紧凑数组的快速路径。

同样，频繁修改 `length` 也要小心。`arr.length = 0` 可以清空数组，但底层容量策略和后续增长方式取决于引擎实现。若只是丢弃旧数组，直接重新赋值 `arr = []` 往往更清晰。

陷阱四：隐藏类与多态

V8 不仅看元素类型，也看数组对象的“形状”。如果不同地方创建的数组初始化顺序不一致，比如有时 `[1, 2]`，有时 `[1, 2, 3]`，有时先 `push` 字符串再 `push` 数字，调用同一个函数时就可能触发多态甚至超多态访问，内联缓存命中率下降。

保持数组创建方式一致，是团队代码里很容易被忽视的性能卫生。

小结

V8 的数组优化核心是“可预测”：类型可预测、空洞可预测、形状可预测。性能陷阱往往不是某个 API 本身慢，而是你无意中让数组从紧凑变成稀疏，从单态变成多态。写业务代码时不必事事优化，但在循环、数据处理、游戏循环、大数据渲染等热路径上，避免混合类型、避免 `delete`、避免巨大越界索引、用 `Array.from` 代替空洞初始化，通常就能拿到可观的收益。最后，任何性能结论都应以真实基准测试为准，因为 V8 本身也在不断进化。