稀疏数组是索引不连续、部分位置无属性（空位）的数组，空位既非undefined也不可枚举；由arr[10]='x'、array(3)、delete arr[i]等操作产生；forin跳过空位，forof返回undefined，map/filter/foreach等忽略空位。
JavaScript 中没有“稀疏矩阵”这一原生类型，你提到的其实是稀疏数组（Sparse Array）——它和线性代数里的稀疏矩阵（Sparse Matrix）概念不同，但名字容易混淆。JS 引擎对稀疏数组的处理会触发内部存储降级，进而让迭代性能从 O(n) 退化为接近 O(n²)，尤其在高密度空位场景下表现明显。
什么是 JS 中的“稀疏数组”？
稀疏数组指索引不连续、部分位置根本没有属性（empty slot）的数组对象。它不是存了 undefined，而是该索引根本不存在于对象内部属性表中。例如：
-
const a = []; a[1000] = 'x';→ 索引 0–999 全是空位 -
const b = new Array(10000);→ 长度为 10000，但所有索引都为空位 -
delete arr[5];→ 移除属性，制造空位（注意：arr.splice(5,1)不会）
引擎如何“降级”稀疏数组的存储？
V8、SpiderMonkey 等主流引擎会根据数组的“密度”自动切换底层表示：
- 稠密模式（Fast Elements）：使用连续内存块（类似 C 数组），支持 O(1) 索引访问、O(n) 迭代
-
稀疏模式（Dictionary Mode）：当空位过多或索引跨度极大时，引擎放弃连续内存，转为哈希表（key-value map）存储，每个有效索引作为字符串 key 存入。此时：
– 属性访问从 O(1) 变为平均 O(1)，但有哈希开销
–length仍正确，但遍历需枚举全部可能索引（0 到 length−1）再查哈希表
一旦进入字典模式，就无法自动切回快速模式——这是不可逆的“降级”。
迭代性能为何指数级恶化？
问题不出在单次访问，而出在迭代逻辑与底层结构的错配：
for (let i = 0; i ：引擎必须对每个 <code>i执行一次哈希查找。若arr.length === 1e6但只有 3 个有效元素，就要做 100 万次哈希探查-
arr.forEach()、arr.map()等方法：它们内部仍按索引 0→length−1 扫描，对每个空位跳过回调，但扫描本身无法跳过——仍要检查每个索引是否存在 -
for...of：虽返回undefined而非报错，但它依赖迭代器协议，而稀疏数组的迭代器仍需模拟“从 0 到 length−1”的序列，底层仍是逐索引探测
实测：一个 new Array(1e6) 的数组，用 forEach 耗时约 80ms；同样长度但填满数据的数组，耗时仅约 3ms——相差超 25 倍，且随 length 增长呈近似线性放大，而非严格指数，但用户感知就是“越长越慢得离谱”。
如何避免？三个关键动作
不用等出问题再优化，初始化和更新阶段就能切断降级路径：
-
别用
new Array(n)初始化：改用Array(n).fill(null)或Array.from({length: n})，二者生成的是稠密数组 -
避免远距离赋值：如需动态扩容，优先用
push()、concat()或扩展运算符；若必须设高位索引，先用fill()占位 -
检测并修复已有稀疏数组：用
Array.from(arr)或[...arr]可将空位转为undefined并重建为稠密数组（注意：这会改变undefined和空位的语义差异）
