深拷贝在undo stack中需权衡数据隔离性与内存开销，否则易因线性/指数级副本膨胀引发oom；应采用差分快照、引用+patch、步数限制、惰性反序列化等策略，并避免json深拷贝陷阱，优先选用不可变数据+结构共享方案。

深拷贝在撤销历史（Undo Stack）中不是“复制得越全越好”，而是要在数据隔离性与内存开销之间做精确权衡。核心矛盾在于：每次记录状态都需要一份独立副本，若不做约束，Undo Stack 会随操作次数线性甚至指数级膨胀，最终触发 OutOfMemory（OOM）。

为什么 Undo Stack 容易引发 OOM？

撤销功能本质是保存历史快照。如果每次操作都对整个编辑对象（如富文本内容、画布图层、表单数据）执行完整深拷贝：

• 嵌套越深、结构越复杂，单次拷贝占用堆内存越多；
• 用户连续输入 100 次，就可能生成 100 份几乎相同的大型对象副本；
• JavaScript 垃圾回收器无法及时回收——只要 Undo Stack 中还持有引用，这些副本就始终存活。

关键优化策略：按需深拷贝 + 状态压缩

不复制全部，只保留“变化差异”或“可重建的最小单元”：

• 差分快照（Delta Snapshot）：不存完整对象，只记录本次操作前后的变更点（如“第3行插入字符‘a’”、“节点id=5 的 color 从 red → blue”），回退时逆向应用差分；
• 引用快照（Reference + Patch）：Undo Stack 仅保存对某个稳定基态（baseline）的引用，再附带轻量 patch 数据；基态本身由共享缓存统一管理；
• 限制深度与频率：设置最大历史步数（如最多保留 50 步），并合并连续小操作（如连打 5 个字母视为一次输入事件，而非 5 次）；
• 惰性反序列化：快照以序列化形式（如精简 JSON 或自定义二进制格式）暂存，真正回退时才做深解析与重建，避免长期驻留解构后的大对象。

避免常见陷阱：深拷贝 ≠ 安全，更不等于高效

直接用 JSON.parse(JSON.stringify(obj)) 或第三方 deep clone 库接入 Undo Stack，往往埋下隐患：

• 无法处理函数、undefined、Date、RegExp、Map/Set 等原生类型，导致还原失败；
• 忽略循环引用，直接抛错或无限递归；
• 对大数组或深层嵌套对象，拷贝耗时长、GC 压力陡增，卡顿明显；
• 未清理无用快照，Undo Stack 成为内存泄漏温床。

生产级建议：结合不可变数据 + 结构共享

比“每次都深拷贝”更优的路径是设计阶段就采用不可变更新模式：

• 使用 Immutable.js、Immer 或原生 Proxy + 冻结策略，让每次变更返回新引用，旧状态天然可复用；
• 底层数据结构支持结构共享（structural sharing），例如修改列表某一项，仅新建路径上的节点，其余子树复用原引用；
• Undo Stack 存储的是这些不可变版本的引用，内存增长趋近于对数级而非线性。