17370845950

push、pop、shift、unshift、splice、sort、reverse 会直接修改原数组；它们原地操作，破坏不可变性，易导致响应式框架更新异常。

哪些 JavaScript 数组方法会直接修改原数组？

不是所有数组方法都“安全”。push、pop、shift、unshift、splice、sort、reverse 这些方法会**原地修改**数组，返回值可能还是该数组（比如 push 返回新长度，splice 返回被删元素），但原数组已变。

容易踩的坑：在 React 或 Vue 的响应式逻辑里直接调用 arr.push(item)，看似只是“加一个”，实则破坏了不可变性，可能导致视图不更新或状态错乱。

• splice 是最危险的之一：它既能删又能插还能替，且不生成新数组
• sort 默认按字符串排序，且永远改原数组——哪怕你只想要排个副本
• reverse 看似无害，但对引用类型数组（如 [{id:1}, {id:2}]）调用后，原数组顺序就变了，后续遍历全乱

如何用「不修改原数组」的方式实现相同操作？

核心思路是：**先拷贝，再操作**。但拷贝方式有讲究，浅拷贝就够用的场景别上深拷贝，否则性能白丢。

推荐优先使用：[...arr]（展开语法）、arr.slice()、arr.concat() —— 它们都返回新数组，且只做浅拷贝，速度快、语义清。

const original = [1, 2, 3];
const copy = [...original]; // ✅ 安全
copy.push(4); // original 不变
console.log(original); // [1, 2, 3]

• 想“添加”：用 [...arr, newItem] 或 arr.concat(newItem)，别用 push
• 想“删除末尾”：用 arr.slice(0, -1)，别用 pop
• 想“插入/删除任意位置”：用 arr.toSpliced(start, deleteCount, ...items)（ES2025 新增，返回新数组）
• 想“排序”：用 [...arr].sort((a,b) => a - b)，别直接 arr.sort(...)

遇到对象数组时，浅拷贝还够用吗？

不够。因为 [...arr] 只复制了对象的引用，不是对象本身。改新数组里的某个对象属性，原数组里对应对象也会变。

const users = [{name: 'Alice'}, {name: 'Bob'}];
const copy = [...users];
copy[0].name = 'Alicia'; // ⚠️ original[0].name 也变成 'Alicia'
console.log(users[0].name); // 'Alicia'

这时候要分情况处理：

• 只读操作或仅替换整个对象项 → 浅拷贝 + 替换（如 copy.map(u => u.id === id ? {...u, name} : u)）
• 需要深层结构隔离 → 用 structuredClone(arr)（现代浏览器支持），或 JSON.parse(JSON.stringify(arr))（仅限纯数据，无函数/undefined/Date 等）
• 在 Redux 或 Zustand 等状态管理中 → 直接用 Immer 的 produce，写法像改原数组，实际自动产出新引用

为什么有些库（如 Lodash）的 _.remove 仍会改原数组？

因为 Lodash 明确区分了 “mutating” 和 “non-mutating” 方法：_.remove 属于前者，设计目标就是原地过滤并返回被删元素；而 _.filter 才是安全的、返回新数组的版本。

常见混淆点：

• _.pull(arr, 2) → 修改 arr，删掉所有 2
• _.without(arr, 2) → 返回新数组，原 arr 不动 ✅
• _.sortBy(arr, 'age') → 不改原数组 ✅，但很多人误以为它和原生 sort 行为一致（其实相反）

查文档时盯紧方法名后缀：带 Mutate 或没标注 immutable 的，大概率改原数组；Lodash 中以 map、filter、reduce 命名的，基本都是安全的。

真正难防的不是记不住哪些方法会改，而是忘记自己写了个 for 循环直接改 arr[i].done = true —— 那种时候，连“方法”都算不上，纯靠意识和代码审查。