浅拷贝在react或redux中不够用，因为它只复制第一层属性，嵌套对象或数组仍共享引用，修改副本会意外改变原始状态，破坏不可变性原则，导致渲染异常；而不可变数据通过结构共享实现高效安全更新。
浅拷贝在状态管理中为什么不够用
在 React 或 Redux 这类状态驱动的框架中，组件重渲染常依赖 引用是否变化 来判断状态是否更新。浅拷贝（如 Object.assign({}, obj)、扩展运算符 {...obj}、arr.slice()）只复制第一层属性，一旦对象内部嵌套了对象或数组，这些深层引用仍被共享。这意味着：修改拷贝后的嵌套值，原始状态也会被意外改动，导致 UI 渲染异常或状态“丢失”。
不可变数据不是“多做一次深拷贝”
Immutable.js 或 Immer 等方案的目标不是把整个对象树复制一遍，而是通过 结构共享（Structural Sharing） 实现高效更新：
- 只新建被修改路径上的节点（比如修改
user.profile.name，就新建name、profile、user三层新对象） - 未修改的子树（如
user.posts、user.avatar）仍复用原引用，节省内存和时间 - 返回的新对象与旧对象引用不同，天然支持
===快速比较，适合 React 的memo或 Redux 的浅比较优化
关键差异对比表
（不是实现方式对比，而是设计目的与行为差异）
- 浅拷贝：仅用于“隔离顶层”，不保证嵌套安全；不能作为状态更新的可靠手段；无法支撑细粒度的 shouldComponentUpdate 或 selector 计算
-
不可变数据：强制所有更新都返回新引用；保证任意层级修改都不影响原始数据；配套提供
setIn、updateIn等路径操作 API；天然适配函数式状态流 - 深拷贝（如 cloneDeep）：虽能隔离，但每次更新都全量重建，性能差、内存高；无结构共享；不适合高频状态更新场景（如输入框实时响应、动画帧更新）
实际开发中怎么选
不需要引入 Immutable.js 也能实践不可变原则：
- 对象更新用
{...state, field: newValue}+{...state.nested, subField: newSubValue}手动展开 - 数组更新避免
push/splice，改用[...arr, newItem]或arr.map/arr.filter - 复杂嵌套更新可借助
immer：写法像可变，底层自动产出不可变结果 - 若项目已重度使用 Immutable.js，注意它返回的是
Map/List等封装类型，需用.toJS()或.get()访问，不能直接解构
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
