深拷贝不是不可变更新的常规手段，它全量复制整棵树、性能差、丢类型；不可变更新靠结构共享，仅新建变更路径及其父级，如React展开运算符或Immer produce。
深拷贝不是维护不可变数据状态的常规手段，它和不可变数据更新是两类不同目标的技术路径。真正高效的状态更新，靠的是结构化、局部化的新对象生成，而不是全量复制。
不可变更新 ≠ 深拷贝
不可变数据强调“每次变更返回新引用”，但实现上只复制被改路径及其父级，其余保持原引用——这叫结构共享。而深拷贝（如 _.cloneDeep 或 JSON.parse(JSON.stringify())）会递归复制整棵树，性能差、丢类型、不支持循环引用，仅适合极少数隔离原始缓存的场景。
- React 中更新一个字段：
{ ...state, user: { ...state.user, name: 'Alice' } }—— 只新建两层对象，深层未动部分复用 - Redux Toolkit 的
createReducer或 Immer 的produce：写法像直接修改，底层自动产出最小差异新对象 - 用
Array.map替代arr.push()，用filter替代splice，天然符合不可变语义
什么情况下才考虑深拷贝？
只有当原始数据会被多处反复读写、且你无法控制所有调用方行为时，才需要一次深拷贝做“安全隔离”：
- 从后端接口拿到
res.data，后续要在表单编辑、校验、提交等多个逻辑中各自增删改，又不想污染原始响应缓存 - 第三方库强制要求传入可变对象，而你必须保留原始数据用于比对或回滚
- 调试阶段临时快照：在关键节点打日志前做一次轻量深拷贝，避免日志输出时对象已被改
注意：JSON.parse(JSON.stringify()) 不适用于生产环境——它会丢掉 Date、RegExp、function、undefined 和循环引用；lodash.cloneDeep 能处理更多类型，但对万级嵌套结构易卡顿，慎用于高频操作。
更可持续的维护方式
与其依赖深拷贝兜底，不如从源头收敛变异点：
- 把高频变动的数据（如表格行、配置项列表）封装成纯函数模块，导出
addItem(list, item)、updateById(list, id, updater)等接口，内部统一用展开运算符或map实现 - 在函数入口加守卫：检查参数是否已标记为不可变（如
obj.$$immutable === true），误传可变对象则抛警告，推动上游修正 - 关键副作用节点（如 API 请求前、localStorage 写入前）插入快照日志：
console.log('before submit:', JSON.stringify(obj))，快速定位谁在悄悄改数据
小结：状态更新该怎么做
优先用结构化更新替代深拷贝；能局部替换就不全量重建；能用 Immer / Redux Toolkit 就别手写 clone；真要深拷贝，也只在明确需要“完全隔离”的少数节点按需使用，并避开常见陷阱。不可变性的价值不在“拷得有多深”，而在“改得有多准”。
