JavaScript中的数组方法有哪些_哪些会改变原数组

“纵有疾风来，人生不言弃”，这句话送给正在学习文章的朋友们，也希望在阅读本文《JavaScript中的数组方法有哪些_哪些会改变原数组》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新文章相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！

JavaScript中有7个会改变原数组的方法：push()、pop()、shift()、unshift()、splice()、reverse()、sort()；其余如map()、filter()、slice()等均不改变原数组。

哪些数组方法会改变原数组

JavaScript 中有 7 个原生数组方法会直接修改调用它的数组（即“变异”），其余方法都返回新数组或新值，不碰原数组。这是最容易混淆的点——比如 sort() 看起来很安全，但它其实会改原数组。

• push()：末尾添加元素，返回新长度
• pop()：删除末尾元素，返回被删元素
• shift()：删除开头元素，返回被删元素
• unshift()：开头添加元素，返回新长度
• splice()：按索引增删改，返回被删元素组成的数组
• reverse()：反转顺序，返回原数组引用
• sort()：按字符串 Unicode 码点排序（默认），返回原数组引用

注意：splice() 的行为最灵活也最危险——哪怕只传一个参数（如 arr.splice(2)），它也会从索引 2 开始删到末尾，并改变原数组。

哪些不会改变原数组但常被误用

这些方法看起来像在“操作数组”，实际是创建新结构，原数组完全不受影响。新手常以为 map() 或 filter() 改了原数组，结果调试半天发现数据没变。

• map()、filter()、flatMap()、slice()、concat()、toReversed()、toSorted()、toSpliced()（ES2023 新增）
• find()、findIndex()、includes()、indexOf() 等只读查询方法当然也不改原数组

特别提醒：toSorted() 和 toReversed() 是为替代 sort() 和 reverse() 的非变异版本而生，但它们不是所有环境都支持（Node.js ≥ 20.1，Chrome ≥ 114）。旧环境仍需靠 [...arr].sort() 这类写法兜底。

容易踩坑的边界情况

有些方法看似安全，但在特定参数或类型下会意外变异，或者产生隐蔽副作用：

• fill()：会改原数组（属于变异方法），但常被忽略——arr.fill(0) 直接把整个数组变成 [0, 0, 0]
• copyWithin()：也是变异方法，内部做的是内存块复制，不创建新元素，如果目标和源区域重叠，行为类似 memmove
• sort() 传比较函数时仍改原数组，但若比较函数返回非数字（如 return 'a'），排序结果不可预测，且无法回滚
• 对象数组用 map() 不改数组结构，但若在回调里直接改了对象属性（如 item.name = 'new'），原对象仍被污染——这是浅层不变性，不是深层不变性

const arr = [{ id: 1 }, { id: 2 }];
arr.map(item => {
  item.id = 99; // ❌ 原对象被改了
  return item;
});
console.log(arr[0].id); // 99 —— 原数组没变，但里面对象变了

如何快速判断一个方法是否变异

不用死记，三步验证法：

• 查 MDN 文档，看方法签名下方是否写着 “Mutates the array”
• 执行后打印原数组，对比前后是否相同（简单粗暴但有效）
• 记住口诀：“增删改 + 反转 + 排序” 大概率变异；“映射、筛选、切片、拼接、查找” 都不碰原数组

真正麻烦的不是记哪些变异，而是意识到：JS 数组方法的设计哲学本就混杂——早期方法（push/sort）为性能默认变异，后来新增的方法（toSorted）才逐步补上不可变语义。这种历史包袱，得自己兜住。

今天关于《JavaScript中的数组方法有哪些_哪些会改变原数组》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！