unshift()性能远低于push()：因unshift需整体搬移元素，push仅追加；数组越长差距越大，v8还可能降级为dictionary mode导致访问变慢；推荐改用push/pop或双端队列。

直接看执行耗时最准：对长度超 1 万的数组反复调用 unshift()，性能会明显变慢；而 push() 几乎不受影响。根本原因不在语法，而在内存操作方式——unshift() 每次都要整体搬动已有元素，push() 则只是追加。

观察数组长度变化时的耗时曲线

写一段简单测试就能暴露问题：

• 新建一个含 50000 个元素的数组：const arr = new Array(50000).fill(0);
• 用 console.time() 分别测 1000 次 unshift(1) 和 1000 次 push(1)
• 你会发现 unshift 耗时可能是 push 的几百倍，且数组越长，差距越拉大

检查 V8 引擎是否触发「慢数组」转换

当频繁在头部增删，V8 可能将数组从「Fast Elements」（连续内存）降级为「Dictionary Mode」（哈希表存储），此时所有索引访问都变慢。可通过以下方式间接判断：

• 在 Chrome DevTools 中启用 Memory Profiling，观察数组对象的内部表示
• 用 %DebugPrint(arr)（需开启 V8 内部调试）查看 elements kind，若显示 HOLEY_ELEMENTS 或 DICTIONARY_ELEMENTS，说明已降级
• 日常开发中更实用的信号是：原本流畅的列表滚动/动画突然卡顿，且堆内存持续增长

留意高频调用场景中的隐性累积开销

单次 unshift() 看似无感，但在循环或事件密集区反复执行，代价会指数级放大：

• 消息队列每秒接收 50 条新消息并 unshift() → 每条消息平均触发 5 万次内存位移（假设队列维持 5 万条）
• 滚动加载列表维护「最近 200 条」，每次新数据来就 unshift() 再 splice(200) → 实际做了两轮 O(n) 操作
• 动画帧内对数百项数组反复 shift() 做调度 → 一帧内多次触发全量位移，直接掉帧

用替代方案快速验证性能是否改善

不改业务逻辑，只换操作位置，就能大幅缓解：

• 把「最新消息放开头」改成「最新消息放末尾」，出队改用 pop()，入队用 push()
• 需要 FIFO 语义？封装一层反向读取逻辑：arr[arr.length - 1] 当作队首，arr.pop() 相当于 shift()
• 真要首尾都快？引入 @datastructures-js/deque，其 addFront() 和 removeFront() 均为 O(1)