浅拷贝在数组过滤中用于保障原始数据不被污染——filter仅复制数组第一层引用，嵌套对象仍共享内存，因此需配合map解构或扩展运算符对每个对象浅拷贝。
浅拷贝在数组过滤中不是为了“实现过滤”，而是为保障过滤操作不污染原始数据——尤其当原始数组含嵌套对象时，必须先做浅拷贝，再对副本调用 filter（或其他方法），才能安全地进行后续修改。
为什么 filter 本身不触发浅拷贝？
filter() 方法返回一个新数组，但它只拷贝原数组第一层的元素引用。如果原数组里存的是对象或子数组，filter 返回的新数组仍指向同一堆内存中的那些对象。这意味着：
- 你不能靠
filter自身来隔离嵌套数据的修改风险 - 若过滤后还打算修改结果里的对象属性（比如打标、更新状态），必须确保这个“结果数组”本身是独立副本
典型场景：筛选后批量更新状态
比如管理商品列表，需先筛选出“待审核”商品，再统一标记为“已读”：
const allItems = [
{ id: 1, status: 'pending', title: 'iPhone' },
{ id: 2, status: 'approved', title: 'MacBook' },
{ id: 3, status: 'pending', title: 'AirPods' }
];
// ❌ 错误：直接 filter → 修改 result 会影响 allItems
const pending = allItems.filter(item => item.status === 'pending');
pending[0].status = 'read'; // 这会同步改掉 allItems[0].status
// ✅ 正确：先浅拷贝数组，再 filter（或 filter 后浅拷贝结果）
const pendingSafe = allItems
.filter(item => item.status === 'pending')
.map(item => ({ ...item })); // 对每个对象做浅拷贝
pendingSafe[0].status = 'read'; // allItems 不变
更简洁的写法：filter + 扩展运算符组合
如果只需保留筛选结果且不修改原对象属性，可跳过 map；但只要涉及写操作，就必须对筛选出的对象逐个解构或用 Object.assign：
-
[...allItems.filter(...)]—— 只拷贝数组本身，内部对象仍是引用 -
allItems.filter(...).map(x => ({...x}))—— 数组+每个对象都浅拷贝，最常用也最稳妥 - 搭配 React 使用时，这种写法天然符合不可变更新原则，避免意外 rerender 或状态错乱
注意边界：浅拷贝够用，深拷贝反而冗余
过滤场景通常只涉及一层嵌套（如数组里是普通对象），不需要递归复制深层属性。用 JSON.parse(JSON.stringify()) 或 structuredClone 属于过度设计，带来性能开销且可能抛错（比如遇到函数、Date、undefined）。
真正需要深拷贝的，是编辑表单、实现撤销/重做、保存历史快照等多层嵌套结构频繁变更的场景。
