优先使用structuredClone，它原生支持循环引用和主流内置类型；中大型系统选lodash.cloneDeep以兼顾定制性；极致性能场景需手写WeakMap递归拷贝。
大型 B 端系统中，表单暂存与撤销功能依赖数据副本的完全隔离性——改暂存草稿不能影响原始表单，点“撤销”要精准回退到上一状态。这本质上是深拷贝问题，但不能只看“能不能复制”，得结合性能、类型兼容性、可维护性和运行时环境综合选型。
核心约束条件必须前置判断
先确认你的表单数据结构是否满足以下任一限制，它会直接排除某些方案：
- 含函数（如校验规则、动态计算字段）、undefined 或 Symbol：JSON.stringify 方案失效
- 存在循环引用（例如：formModel.owner = formModel；或嵌套的父子关系对象）：JSON 和部分手动递归实现会崩溃或栈溢出
- 用到了 Date、RegExp、Map、Set、Blob、File、TypedArray 等非纯 JSON 类型：JSON 会丢失或转为空对象，structuredClone 是底线要求
- 需要保留原型链或自定义 getter/setter：所有序列化方案（JSON/structuredClone/MessagePack）都会丢失，只能手写或用支持原型的库（如 lodash 的 cloneDeepWith 配合自定义克隆逻辑）
- 运行环境不支持 structuredClone（如需兼容 Chrome 97-、Safari 15.4-、旧版 Node.js）：需 polyfill 或降级为第三方库
推荐的三档选型策略
按项目成熟度与控制粒度分层决策：
- 新项目 / 现代环境（Chrome 98+、Firefox 94+、Node.js 17+）→ 优先用 structuredClone：一行代码、原生支持循环引用和主流内置类型，性能由引擎保障。撤销栈只需 push(structuredClone(currentState))，暂存也同理。注意它仍不支持函数和 DOM 节点，若表单模型里混入了这类值，提前剥离（如把校验函数抽成独立 service，不塞进数据对象）
- 中大型存量系统 / 需要定制行为（如忽略某些字段、特殊处理日期格式）→ 选用 lodash.cloneDeep：稳定、文档完善、社区验证充分。它能处理函数（浅拷贝引用，适合校验函数复用）、Date、RegExp、Map/Set 等，并支持自定义克隆器（cloneDeepWith）。缺点是包体积约 20KB（gzip 后），若对首屏加载敏感，可考虑按需引入或构建时 tree-shake
- 极致性能敏感场景（如万级字段动态表单、高频实时协作编辑）→ 手写带 WeakMap 的递归深拷贝 + 惰性快照：用 WeakMap 缓存已拷贝对象解决循环引用；对大数组/大对象做浅拷贝 + 标记变更路径，撤销时只回滚差异字段（类似 Immutable.js 的结构共享思想）。这不是全量深拷贝，而是“语义深拷贝”——保证用户感知隔离，但底层复用未变数据。适合有专门基础架构团队支撑的系统
表单暂存撤销的配套实践
深拷贝只是基础，真正健壮的暂存撤销还需配合以下设计：
- 撤销栈建议用数组 + 指针方式管理（而非 splice/pop），便于“重做”和跳转到任意历史版本
- 每次深拷贝前做轻量 diff，若数据无实质变化（如仅触发了 input 事件但值未变），跳过拷贝节省内存
- 暂存草稿建议加时间戳和版本号，避免多端并发覆盖；撤销操作应附带 human-readable 描述（如“修改了客户名称”），方便审计
- 对超大表单（如含 base64 图片字段），可将二进制内容外置存储，表单对象中只保留 URL 或 ID，大幅降低深拷贝开销
不复杂但容易忽略：深拷贝不是银弹，它解决的是“副本独立性”，而表单状态管理的健壮性还取决于你如何定义“状态边界”、何时触发拷贝、以及如何清理废弃快照。选对方法只是第一步。
