核心是返回全新引用而非修改原state，因redux依赖不可变性触发更新和调试功能；推荐结构化更新或rtk+immer，仅在存快照等少数场景需专业深拷贝。
在 Redux 中，确保每次 dispatch 都更新不可变状态，核心不是“每次都手动深拷贝”，而是**用不可变方式产生新状态对象**。深拷贝只是其中一种手段，但直接、盲目地全量深拷贝既低效又容易出错。真正关键的是：状态更新必须返回全新引用，且不修改原始 state。
为什么不能直接修改 state？
Redux 的设计哲学基于不可变性（immutability）。reducer 必须是纯函数，若直接赋值如 state.user.name = action.payload，虽然代码能运行，但 React 可能无法检测到变化，视图不更新；更严重的是，时间旅行调试、状态快照比对等功能将完全失效。
推荐做法：优先用结构化更新，而非全量深拷贝
大多数场景下，你只需更新状态树中极小一部分。与其深拷贝整个 state，不如精准构造新对象：
- 用展开运算符（
{...state, user: {...state.user, name: action.payload}}）逐层替换需要变更的节点 - 对数组更新，用
[...state.items.slice(0, index), newItem, ...state.items.slice(index + 1)]替代原地 push/splice - 配合 Redux Toolkit（RTK），它默认集成 Immer，允许你“写起来像修改，实际是安全的不可变更新”
何时才需要真正深拷贝？
仅在以下少数情况才需显式深拷贝：
- 从外部来源（如 API 响应、localStorage 读取）获取一个复杂嵌套对象，要完整纳入 state 树时
- 实现撤销/重做功能，需保存某时刻的完整状态快照
- 对接遗留代码或第三方库，它会意外修改你传入的对象
此时建议使用专业工具如 fast-copy，它支持 Date、Map、循环引用等，比 JSON.parse(JSON.stringify()) 可靠得多。
避免常见陷阱
不要依赖看似“简单”的方案：
-
JSON.parse(JSON.stringify(state))会丢掉函数、undefined、RegExp、Date 对象、原型方法和循环引用 - 用
Object.assign({}, state)或展开运算符只做浅拷贝，嵌套对象仍共享引用 - 在 reducer 外部提前拷贝再传入——这破坏了 reducer 的可预测性，也增加冗余操作
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
