array.prototype.shift() 通过索引重映射和length截断实现逻辑删除，而非内存前移，时间复杂度o(n)；它依赖数值索引与可写length属性，适用于类数组对象，不依赖底层内存布局。
Array.prototype.shift() 的原理直接暴露了 JS 引擎处理数组首部时的“被动重排”本质：它不移动内存块，而是通过索引重映射和 length 截断来模拟删除，底层并不做物理偏移。
shift 不是内存前移，而是逻辑丢弃 + 索引平移
JS 数组在引擎中（如 V8）通常以连续或近似连续的元素存储区实现，但 shift() 并不会把后续所有元素在内存里整体向前拷贝。真实操作是：
- 保存索引 0 位置的值（即第一个元素）作为返回值
- 从索引 1 开始，逐个把
this[i]赋给this[i-1]（即人为前移引用） - 最后执行
this.length--，让引擎认为数组“变短了”，超出新 length 的旧索引自动不可访问
这个过程没有调用底层内存移动指令（如 memmove），纯靠 JS 层循环赋值完成——所以时间复杂度为 O(n)，尤其对长数组明显拖慢。
为什么引擎不优化成真正的内存偏移？
因为 JS 数组不是 C 风格的固定缓冲区，而是动态对象，其底层可能混合使用多种存储策略（如快数组、慢数组、稀疏哈希表等）。强行做内存偏移会破坏以下关键特性：
- 引用一致性：若其他变量或闭包仍持有原数组某元素的引用，移动内存可能导致悬空或错位
- 原型链与属性访问：数组可能有自定义属性（
arr.custom = true），这些不在连续数据区，无法随“内存偏移”一并迁移 - length 的语义优先：length 是可写的数据属性，
shift()的核心契约是“改 length 并返回首项”，而非“优化底层布局”
类数组对象也能用 shift，说明它依赖的是结构约定，不是内存模型
shift 方法可通过 call 应用于任意含 length 属性的对象：
const fakeArr = { 0: 'a', 1: 'b', 2: 'c', length: 3 };
Array.prototype.shift.call(fakeArr); // 返回 'a'，fakeArr 变为 { 0: 'b', 1: 'c', length: 2 }
这证明 shift 的行为只依赖两个条件：存在数值索引 和 length 可读写，完全脱离真实数组的内存布局。JS 引擎只是按协议执行索引搬运+length 更新，不关心背后是 TypedArray、Arguments 还是普通对象。
实际性能提示：避免在大数组上高频 shift
由于每次 shift 都要遍历剩余全部元素，10 万长度的数组调用一次 shift，就要执行约 10 万次赋值。替代方案更高效：
- 用
arr = arr.slice(1)—— 创建新数组，原数组不变，V8 对 slice 有深度优化 - 用
index++模拟“游标前进”，配合固定数组+下标管理，避免修改 length - 真需要队列行为，用
push()+pop()实现栈式逆序队列，或引入Deque类库
