Chrome预分配大长度JS数组赋值时报Uncaught RangeError错误问题

这个报错并不是真的数组长度超出JS规范限制，本质是Chrome V8引擎的数组类型优化机制 + 主线程超时检测误报共同导致的，具体如下：

• V8数组元素类型的动态优化机制差异
  V8会根据数组存储的内容自动给数组标记不同的元素类型，不同类型的内存占用、执行效率差异极大：
  1. 当你给yValues赋值整数i时，1亿的数值落在V8小整数（SMI）的范围内，数组会被标记为PACKED_SMI_ELEMENTS类型，每个元素仅占4字节，两个1亿长度的数组总占用仅800MB左右，且不需要做任何类型转换，循环执行速度极快，短时间就能跑完不会触发超时。
  2. 当你给yValues赋值Math.sin结果、随机浮点计算结果时，数组会被自动降级为PACKED_DOUBLE_ELEMENTS类型，每个元素占8字节，触发全量数组的内存重分配+原有元素类型转换复制，再加上Math.sin、随机数计算本身比直接赋值整数慢数倍，整体执行时间会指数级上升。
• Chrome主线程超时检测的错误上报
  Chrome渲染主线程默认会将阻塞超过阈值的JS任务直接终止，避免页面完全卡死。你的大数组+浮点计算的循环执行时间超过阈值后被强制中断，但V8在终止这种大内存操作场景时，错误栈没有被正确映射，把超时终止的异常误报成了Uncaught RangeError: Invalid Array Length。Firefox没有直接终止超时长任务，只是弹出等待提示让用户选择是否继续，所以不会出现这个报错。

你提到的测试场景完全符合上述逻辑：

仅当yValues[i]赋值为i时可正常运行
赋值整数不需要做数组类型转换，执行速度快到不会触发超时；其余浮点赋值场景都要触发类型重分配+慢计算，触发超时被误杀。

• 优先使用TypedArray替代普通数组存储大数量的数值，比如const yValues = new Float64Array(COUNT)，初始化时就固定元素类型，完全避免后续的动态类型转换和内存重分配开销，执行速度会提升数倍，大概率不会触发超时。
• 把这类超长循环逻辑放到Web Worker中执行，Worker线程不会触发页面主线程的超时检测，不会被强制终止。

内容的提问来源于stack exchange，提问作者Dr. Andrew Burnett-Thompson