先记住这个答案
shift、unshift 在语义上需要让后续位置向前或向后调整，而 push、pop 主要处理尾部和 length，所以常见密集数组模型中，头部操作更容易随元素数量增长，尾部追加通常按摊还常数成本理解。但 JavaScript 不规定所有引擎固定采用一种数组存储，扩容、稀疏结构、访问器和代理都会影响实际成本，不能承诺任何一次 push 都是严格 O(1)。大量队列出队可以考虑头游标或环形缓冲，同时清理已消费引用并控制底层容量；小数组则应优先保持逻辑清楚。
- 头部操作会改变剩余元素的索引关系
- 尾部追加的扩容成本需要用摊还视角理解
- 队列游标减少移动但仍需管理已消费引用
先确认四个方法的返回值不同
push 和 unshift 返回修改后的长度，pop 和 shift 返回被移除的元素。示例分别操作独立数组并打印结果，避免把返回值当作新数组，再误用后续链式数组方法。
这些操作都会修改原容器，头尾差异不代表其中某组是不可变方法。状态共享或框架更新场景要先确认是否允许原地修改，再讨论哪种操作的运行成本更合适。
const head = ['B', 'C'];
console.log(head.unshift('A'));
console.log(head.shift());
console.log(JSON.stringify(head));
const tail = ['A', 'B'];
console.log(tail.push('C'));
console.log(tail.pop());
console.log(JSON.stringify(tail));查看输出与解释
3
A
["B","C"]
3
C
["A","B"]新增操作返回长度三，移除操作返回对应端点元素，两组原数组都被改变。输出验证语义，不能据此推断具体引擎内部移动了多少字节或分配了几次。
批量出队时可用游标避免重复头部调整
队列若每次 shift 都要处理很长的剩余序列，总成本可能累积得很高。可以保存 head 索引，出队时读取当前位置并推进，而不是立刻移动所有剩余元素，适合高频消息处理等场景。
游标方案不能只增长不清理，已经消费的对象若仍留在数组槽位里，就可能继续占用内存。应清除相应引用，并在合适阈值压缩或使用环形结构，权衡清理开销、容量和访问模式。
复杂度结论需要说明数据模型
普通密集数组的常见模型有助于解释为什么尾部适合栈，但引擎可能优化某些头部操作，稀疏数组和通用类数组又可能走不同路径。访问器或代理还可能让索引操作具有用户可见副作用。
因此基准应覆盖真实长度、对象类型和操作分布，比较总吞吐、峰值延迟与内存，而不是只重复一个空数组 push。只有确认热点后，才值得引入更复杂的队列实现和容量策略。
容易答错的地方
- 声称每次 push 都绝对只做一次写入
- 扩容或实现策略可能带来额外工作，常见分析需要区分单次最坏与摊还成本。应说明使用的数组模型，避免把工程经验写成语言规范对内部存储的强制保证。
- 换成 head 游标后忘记清理旧引用
- 索引推进只表示业务不再读取，底层数组仍可能强引用已消费对象。长期队列应清除这些位置并控制容量，否则减少移动成本的同时可能引入持续内存保留。
面试官还会怎么问？
小数组也需要自写环形队列吗？
通常应先看是否存在实际热点和容量需求，小数组的直接方法更容易维护。专用队列增加边界、扩容和清理逻辑，只有真实负载收益足以覆盖复杂度时才值得引入。
空数组 pop 或 shift 返回什么？
通常返回 undefined，长度保持零。若队列允许元素本身为 undefined，不能只凭返回值区分空队列，应同时维护存在性或长度条件，避免把合法元素当作结束信号。
unshift 一次多个元素与反复单个插入一样吗？
最终顺序可能不同，一次传入的参数按给定顺序放到头部，连续单项调用则每次把新项放到最前。替换性能写法前应先验证业务顺序，再比较实际成本。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。