JavaScript 深度拷贝：序列化方案的真实边界

作者：Nicky2026.11.06 22:52浏览量：0

简介：解析 JSON 序列化实现深拷贝的适用场景与六大失效边界，涵盖函数、循环引用、特殊数值、原型链断裂等典型陷阱，并给出结构化克隆、自定义递归等替代方案，帮助开发者在数据持久化与状态管理场景中做出正确的技术选型。

JavaScript 深度拷贝：序列化方案的真实边界

一、从一个常见写法说起

在 JavaScript 日常开发中，深拷贝是一个绕不开的话题。只要涉及对象状态的隔离、缓存快照、撤销重做或跨模块数据传递，开发者都需要确保副本与原对象之间不存在任何引用共享。此时，一种极为常见的写法是：

  1. const cloned = JSON.parse(JSON.stringify(source));

这行代码简洁、直观，且在许多场景下确实能工作。它利用了 JSON 序列化与反序列化的往返过程，将原对象“拍平”为字符串，再从字符串重建一个全新的对象树。由于重建过程不保留任何原有引用，因此天然实现了引用隔离。

但这种方案是否足够可靠？它能否作为通用的深拷贝手段？答案并不乐观。JSON 序列化本质上是一种数据交换格式的转换，而非对象图的复制机制。它的设计目标、能力边界与深拷贝的实际需求之间存在系统性错位。理解这些错位，比记住“能不能用”更重要。

二、序列化方案的适用前提

在讨论失效场景之前，先明确它为什么在多数情况下有效。JSON 序列化能够完成深拷贝，依赖以下隐含前提：

  • 数据结构是纯 JSON 兼容的：仅包含对象、数组、字符串、数字、布尔值和 null；
  • 不存在循环引用；
  • 不依赖原型链上的方法或 getter/setter；
  • 对特殊数值（如 NaN、Infinity）、日期、正则等没有精确保留需求。

只要对象满足上述条件，JSON.parse(JSON.stringify(obj)) 确实能得到一个结构等价、引用独立的副本。这也是它在配置对象、接口响应数据、简单状态快照等场景中流行的重要原因。

然而，一旦对象超出这个“纯数据”范畴，问题便会集中暴露。

三、六大典型失效边界

1. 函数与 undefined 会被直接丢弃

JSON 规范不支持函数类型。在序列化过程中，对象属性值为函数时会被静默忽略；若函数出现在数组中，则会被转换为 null。undefined 同样会被忽略或转为 null。

  1. const source = {
  2.   name: 'demo',
  3.   handler: () => {},
  4.   extra: undefined,
  5. };
  6. const cloned = JSON.parse(JSON.stringify(source));
  7. // cloned: { name: 'demo' }

这意味着任何携带行为逻辑的对象，在拷贝后都会“失去动作能力”。如果该对象需要在拷贝后继续参与交互或执行逻辑，序列化方案会直接破坏其语义。

2. 特殊数值被强制归一

NaN、Infinity、-Infinity 在 JSON 中没有对应表示。序列化时，它们会被统一转换为 null：

  1. JSON.parse(JSON.stringify({ v: NaN }));      // { v: null }
  2. JSON.parse(JSON.stringify({ v: Infinity })); // { v: null }

对于科学计算、统计指标或状态标记类数据，这种静默转换可能引入难以排查的逻辑错误——原本用于表示“无效”或“无穷”的语义被抹平为 null，后续判断将完全失真。

3. 日期对象退化为字符串

Date 实例在序列化时会调用其 toJSON 方法，输出 ISO 格式字符串。反序列化后得到的是 string，而非 Date 对象：

  1. const cloned = JSON.parse(JSON.stringify({ d: new Date() }));
  2. typeof cloned.d; // 'string'

如果后续代码调用 cloned.d.getTime()，将直接抛出异常。类型信息的丢失是序列化方案最隐蔽的风险之一。

4. 循环引用直接抛错

当对象存在自引用或相互引用时，JSON.stringify 会抛出 TypeError：

  1. const a = {};
  2. a.self = a;
  3. JSON.stringify(a); // TypeError: Converting circular structure to JSON

而深拷贝的典型应用场景之一——图结构、双向链表、父子互引的树节点——恰恰经常包含循环引用。此时序列化方案不仅结果不正确，而是根本无法执行。

5. 原型链与类实例信息丢失

序列化只保留自有可枚举属性，对象的原型、类标识、不可枚举属性全部丢失。即便原对象是某个类的实例，拷贝结果也只是一个普通对象：

  1. class User {
  2.   constructor(name) { this.name = name; }
  3.   greet() { return `hi ${this.name}`; }
  4. }
  5. const cloned = JSON.parse(JSON.stringify(new User('A')));
  6. cloned instanceof User; // false
  7. cloned.greet;           // undefined

对于依赖类型判断或方法调用的业务逻辑，这等同于对象“降级”。

6. Map、Set、RegExp、ArrayBuffer 等类型无法保留

这些类型在 JSON 中没有原生表示：Map 和 Set 会被序列化为空对象 {}，RegExp 变为空对象，类型化数组则可能变为普通对象或索引键对象。拷贝结果与原始数据在结构与行为上都不一致。

四、性能与可读性的权衡

除了正确性，性能也值得关注。序列化方案需要经历“对象 → 字符串 → 对象”两次转换，中间还会产生较大的字符串临时值。对于大对象或高频调用场景（如每次状态更新都做快照），其开销明显高于直接递归拷贝或结构化克隆。

不过，在对象规模小、调用频率低、且数据确定是纯 JSON 的场景下，这种开销通常可以接受。技术选型不应脱离具体上下文。

五、替代方案与选型建议

针对不同需求，可以考虑以下路径：

结构化克隆（Structured Clone）

现代运行环境提供的 structuredClone() 原生支持循环引用、Date、Map、Set、ArrayBuffer 等类型，是当前较通用的深拷贝首选。但它同样不支持函数，且无法拷贝原型链上的方法。

自定义递归拷贝

当需要保留类实例、函数引用或特定原型时，可以编写递归函数，按类型分支处理：对普通对象和数组递归，对 Date、RegExp 等做专门构造，对函数直接保留引用。实现成本较高，但可控性最强。

序列化 + 反序列化

仅建议用于：数据结构确定、纯 JSON 兼容、无循环引用、无类型保真要求的场合。可作为轻量方案使用，但应明确其边界，避免在通用工具函数中默认采用。

数据持久化场景的特殊处理

如果目标是将对象保存到存储或跨端传输，序列化本身是合理选择。但若对象包含函数等不可序列化成员，需要先做“数据与行为分离”：将函数抽象为可标识的事件类型或脚本字符串，存储时只保留标识，渲染或执行时再根据标识还原行为。这正是许多可视化搭建、低代码配置场景中常用的思路。

六、结论

JSON.parse(JSON.stringify(obj)) 不是深拷贝的通用解法，而是一种受限于 JSON 数据模型的浅层复制手段。它在纯数据场景下简单有效，但在函数、特殊数值、日期、循环引用、原型链和复杂内建类型面前会系统性失效。

判断是否使用它，只需问三个问题：

  1. 数据是否严格为 JSON 兼容类型？
  2. 是否存在循环引用或类型保真需求？
  3. 拷贝后是否需要保留行为或原型？

只要任一答案为“否”，就应转向结构化克隆或自定义递归方案。把序列化当作深拷贝的默认实现，是一种看似省事、实则埋雷的做法。理解边界，才能做出可靠的技术选择。

最热文章