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() —— 它们都返回新数组，且只做浅拷贝，速度快、语义清。
立即学习“Java免费学习笔记（深入）”；
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)（ES2023 新增，返回新数组） - 想“排序”：用
[...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 —— 那种时候，连“方法”都算不上，纯靠意识和代码审查。
