splice()性能瓶颈在于每次调用需平移后续元素（o(k)）并可能重分配内存，高频批量删除时时间复杂度近o(n²)；推荐filter()+set或for…of+push替代，仅少量按索引删除时方可安全使用。
Array.splice() 会直接修改原数组，删除操作触发元素位移和内部索引重排，对大规模数组（如万级及以上）会造成明显性能开销——尤其在高频调用或循环中逐个删除时，时间复杂度接近 O(n²)，内存上还会引发多次连续的底层数据拷贝。
splice() 的性能瓶颈在哪
每次调用 splice(start, deleteCount) 时，JavaScript 引擎需执行以下动作：
- 定位起始位置并检查边界（O(1)）
- 将 start + deleteCount 后的所有元素向前平移 deleteCount 位（O(k)，k 是后段长度）
- 收缩数组 length 属性，并可能触发内部存储结构重分配
- 若在 for 循环中正向使用 indexOf() + splice() 删除多个值，索引错位会导致漏删或重复删，常需反向遍历补救，逻辑更重
大批量删除的高效替代方案
不修改原数组、避免位移、一次遍历完成过滤，是优化核心。推荐以下方式：
-
filter() + Set 查找（最优通用解）：把待删项转为 Set，再用 filter 保留“不在集合中”的元素。时间复杂度 O(n + m)，空间换时间，语义清晰且无副作用
例：const filtered = arr.filter(item => !deleteSet.has(item)); - for…of + push 到新数组（低内存波动）：手动遍历 + 条件写入，避免高阶函数闭包开销，适合超大数组且对 GC 敏感场景
- TypedArray（仅限数值）：若数组全是数字，改用 Int32Array 等类型化数组，splice 不可用，但 filter 可配合 map/reduce 或自定义循环，内存布局更紧凑，访问更快
什么情况仍可安全用 splice()
适用于明确知道索引、仅删少量元素（≤ 10 个）、且业务逻辑依赖原数组引用变更的场景，例如：
- 待办列表点击删除单个任务（传 index 而非 value）
- 实现 undo 栈时按位置回滚某次插入/删除
- 动画帧内微调小数组（如 UI 控件坐标组），延迟敏感但数据量极小
真正影响性能的不是 splice 本身，而是它被误用于“按值批量删”或“嵌套循环删”。换思路比调优更重要。
