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)
