深拷贝是应对可变状态污染的权宜之计，核心应转向不可变数据流设计：通过字段提升、id映射、结构共享（如immer）和分层处理（跨边界真拷贝、内部浅拷贝、快照用差异树），让深拷贝仅存在于真正必需的场景。

深拷贝不是目的，而是应对“可变状态意外污染”的权宜之计。不可变数据流思想的核心是：不修改旧值，只生成新值；不依赖引用隔离，而靠结构设计和更新契约来保证逻辑独立性。

把深拷贝从“操作”变成“设计约束”

与其在每次更新前手动调用 structuredClone 或 JSON.parse(JSON.stringify())，不如倒推一步：这个对象为什么必须深拷贝？通常是因为它嵌套太深、字段可变、被多处共享。这时应重构数据模型：

• 将频繁局部更新的字段提升为顶层键，例如把 user.profile.settings.theme 拆成 userTheme 和 userSettings
• 用 ID 映射表替代嵌套对象树，如 { users: { 'u1': { name: 'A' } }, posts: { 'p1': { userId: 'u1' } } }，更新时只改 ID 关联，不动原始对象
• 对配置类、表单数据等读多写少结构，用 const 声明初始值 + useMemo 缓存派生状态，避免运行时重复构造

用结构共享替代全量深拷贝

Immer、Zustand 的 produce 或 Redux Toolkit 的 createReducer 不是“简化深拷贝”，而是放弃深拷贝范式——它们不追求内存完全隔离，而是确保语义不可变：

• 写 draft.user.profile.city = 'Shanghai' 时，仅新建 profile 对象，user 和更上层仍复用原引用
• 新旧状态之间形成差异树，90% 内存共享，但 === 判断为 false，React 能精准触发重渲染
• 调试时可清晰看到“哪些路径被修改”，比黑盒深拷贝更可控、更易追溯

区分场景，让深拷贝只出现在真正需要它的位置

不是所有副本都需要深拷贝。按数据用途分层处理：

• 跨边界传递（如 postMessage、Web Worker、localStorage）→ 必须真深拷贝，用 structuredClone 或序列化
• 组件内部临时计算（如筛选、排序、格式化）→ 浅拷贝 + 不可变更新足够，[...arr] 或 {...obj} 即可
• 状态快照或撤销栈（如编辑器历史）→ 用结构共享记录变更路径，比存全量副本省 5–10 倍内存
• 防外部篡改（如 API 返回值校验）→ 不靠深拷贝，而用 Object.freeze + 运行时类型检查

用 key 和 memoization 切断不必要的深比较

很多项目滥用深拷贝，其实是为了解决 React 因引用变化导致的无效重渲染。这可以通过更轻量的方式解决：

• 列表项用稳定 key（如 item.id），让 React 复用节点，跳过子树 diff
• 嵌套对象作为 props 传入子组件时，用 React.memo + 自定义 areEqual，只比关键字段（如 id、version）
• 避免在 render 中动态构造对象：<child data="{{" a: x b: y></child> → 改用 useMemo(() => ({ a: x, b: y }), [x, y])