JS使用JSON.parse实现对象深拷贝的局限与注意事项

图1：JSON.parse(JSON.stringify(obj)) 序列化管道与转换边界总览

一、执行机制与基础操作步骤

要理解深拷贝的局限，首先需要了解该写法的完整执行流程。通过两行原生 API 调用的背后，JavaScript 引擎经历了两组截然不同的处理阶段：

1. 序列化阶段（JSON.stringify）：引擎自顶向下深度优先遍历源对象的可枚举属性。在此过程中，引擎会检查属性是否具有 toJSON 方法，并依据 JSON 语法规范将键值对编码为一维的 UTF-16 文本字符串。任何不符合 JSON 规范的特性都将在此阶段被剥离或转义。
2. 反序列化阶段（JSON.parse）：内置的 JSON 词法与语法分析器读取生成的纯文本，在当前作用域的堆内存中分配一个全新的独立内存地址，根据语法树还原出新的键值对映射，并将生成对象的原型默认挂载到 Object.prototype。

以下是该写法的典型代码示例与验证步骤：

// 步骤 1：定义合法的纯数据源对象 (POJO)
const sourceConfig = {
  appName: "GatewayService",
  version: "1.2.0",
  retryLimit: 3,
  tags: ["network", "proxy"],
  options: {
    timeout: 5000,
    keepAlive: true
  }
};

// 步骤 2：执行序列化与反序列化两步深拷贝
const clonedConfig = JSON.parse(JSON.stringify(sourceConfig));

// 步骤 3：验证引用独立性（深拷贝结果确认）
clonedConfig.options.timeout = 8000;
clonedConfig.tags.push("secure");

// 步骤 4：对比输出
console.log(sourceConfig.options.timeout); // 5000（源对象深层属性未受影响）
console.log(clonedConfig.options.timeout); // 8000（副本属性成功独立更新）
console.log(sourceConfig.tags.length);      // 2
console.log(clonedConfig.tags.length);      // 3
console.log(sourceConfig !== clonedConfig); // true（堆内存地址完全不同）

当数据结构仅由纯粹的 String、Number、Boolean、null、普通纯对象（Plain Object）和数组组成时，这种两阶段转换能够完整切断引用，达到深拷贝的目的。

图2：深拷贝执行的四个关键操作阶段与内存流转时序

二、核心局限：六类数据的静默丢失与变异

一旦对象结构脱离了纯数据传输对象（DTO）的范畴，进入真实的业务逻辑或富状态管理场景，JSON.stringify 的规范过滤机制就会导致严重的静默缺陷。所谓“静默”，是指代码运行时不会抛出任何告警或报错，但产出的对象数据已在无形中残缺不全。

1. 函数（Function）、undefined 与 Symbol 的丢弃

JSON 规范中没有定义函数、未定义类型以及符号类型。当源对象包含这些类型的键值时：

• 作为普通对象的属性值时，该属性会被直接静默删除，新对象中完全不存在对应的键名；
• 作为数组的元素时，为了保持数组索引下标的连续性，它们会被强制转换为 null；
• 如果以 Symbol 作为对象的键名（即 [Symbol('id')]: 'val'），无论对应何种值，该属性都会被完全忽略。

const targetObj = {
  id: 101,
  calculate: function() { return this.id * 2; },
  extra: undefined,
  sym: Symbol("flag"),
  list: [1, function() {}, undefined, "item"]
};

const result = JSON.parse(JSON.stringify(targetObj));

console.log(result.calculate); // undefined（方法丢失，后续如果执行 result.calculate() 将直接报错）
console.log("extra" in result); // false（键名被直接移除）
console.log("sym" in result);   // false（Symbol属性被过滤）
console.log(result.list);       // [1, null, null, "item"]（数组内部元素被篡改为 null）

2. Date 日期对象退化为纯文本字符串

Date 实例的原型上内置了 toJSON 方法，在执行 JSON.stringify 时会被自动调用，将其转换为标准的 ISO 8601 时间格式字符串（例如 "2026-11-01T02:25:00.000Z"）。随后在反序列化阶段，JSON.parse 仅将其识别为普通的 String 字符串，而不会重新构造为 Date 实例。

这会导致新对象丢失 getTime()、getFullYear() 等所有日期原型方法，若后续代码未经校验直接调用日期 API，将引发运行时 TypeError: ... is not a function 异常。

3. 正则表达式（RegExp）与 Error 实例变为空对象

正则表达式字面量或 RegExp 实例在执行序列化时，无法映射为合法 JSON 数据，引擎会将其直接序列化为 "{}"。Error 实例同理，其内部的 message 与 stack 属于不可枚举或特殊属性，最终同样退化为 "{}"。拷贝后得到的仅是一个毫无作用的空对象。

4. Map、Set 等 ES6 集合类型内容全部清空

现代前端状态或数据缓存中常用的 Map 与 Set，其内部存储的键值对并不属于对象本身的可枚举字符串键属性。因此，JSON.stringify(new Map([['a', 1]])) 输出的结果直接就是 "{}"，反序列化后不仅失去了集合原型的 get()、set()、has() 方法，内部存放的数据也已全部消失。

5. 特殊浮点数值（NaN、Infinity）被篡改为 null

JSON 语法规定数值必须是标准的十进制实数，不支持浮点数计算中的特殊状态值。如果对象的数值属性中出现了 NaN、Infinity 或 -Infinity，JSON.stringify 会将它们全部转换为 null，从而在反序列化后破坏原有的数学计算上下文与类型约束。

6. 原型链与自定义类实例的类型丢失

无论源对象是通过自定义构造函数（例如 new OrderModel()）、ES6 的 class，还是利用 Object.create() 构建的具有特定原型链的对象，反序列化重建出的新对象其原型链顶端永远只指向 Object.prototype。所有的类方法、继承属性以及通过 instanceof OrderModel 进行的类型判断将全部失效。

图3：常用 JavaScript 数据类型在 JSON 序列化中的蜕变对照矩阵

三、致命陷阱：导致程序崩溃的运行时错误

上述六类问题属于静默丢失与变异，而在以下两类场景中，代码甚至无法完成序列化过程，而是会直接抛出不可恢复的运行时错误，中断整个执行调用栈。

1. 循环引用引发的堆栈溢出与 TypeError 崩溃

当对象结构中存在环形链路（例如父节点属性引用了子节点，而子节点的某属性又反向引用了父节点或自身）时，JSON.stringify 内部的递归遍历器将无法找到收敛边界。为了防止浏览器或 Node.js 进程发生严重的 C++ 调用栈溢出崩溃，引擎内置了循环检测。一旦检测到某个内存指针在遍历链条的祖先节点中重复出现，便会立即中断执行并抛出错误：

const user = { name: "Alice" };
const group = { title: "Engineering", leader: user };
user.memberOf = group; // 构成循环引用：user -> group -> user

// 尝试执行深拷贝
try {
  const cloned = JSON.parse(JSON.stringify(user));
} catch (err) {
  console.error(err.name);    // TypeError
  console.error(err.message); // Converting circular structure to JSON
}

2. BigInt 大整数类型缺乏序列化支持

随着前端与后端处理超大精度整数（如分布式雪花 ID、加密算法 Hash 等）越来越频繁，ES2020 引入的 BigInt 已经广泛普及。但 JSON 官方标准至今未纳入 BigInt 的表示语法（直接输出数字会丢失精度，加引号又破坏数字语义）。因此，只要对象中包含任意一个 BigInt 属性，执行 JSON.stringify 就会直接抛错：

const transaction = {
  id: 18446744073709551615n, // BigInt 类型
  amount: 200
};

JSON.parse(JSON.stringify(transaction));
// 运行时抛错：TypeError: Do not know how to serialize a BigInt

图4：树状深度优先遍历与环状依赖检测导致运行时崩溃的机理对比

四、生产环境避坑指南与现代替代方案

鉴于 JSON.parse(JSON.stringify(obj)) 存在的诸多限制，在真实业务开发中必须确立清晰的使用边界与技术选型策略。

1. 使用 JSON 深拷贝的前置检查清单

如果出于轻量化考虑仍需使用该写法，必须确保待拷贝对象严格满足以下三个条件：

• 必须是纯数据传输对象（POJO）：例如从后端 API 接口刚刚请求回来的原始 JSON 响应体，确认没有混入前端实例、方法或 DOM 对象；
• 确认无高危类型：对象中不存在 Date、RegExp、Map、Set、BigInt 和函数；若存在日期，应明确知晓拷贝后需要手动重新调用 new Date(str) 转换；
• 数据结构无环：确保对象结构为单向有向无环图，绝不存在自引用或相互嵌套引用的环路。

2. 现代浏览器与 Node.js 原生标准：structuredClone()

从 ECMAScript / HTML 标准规范演进来看，现代运行环境（Chrome 98+、Firefox 94+、Safari 15.4+ 以及 Node.js 17.0+）均已内置了官方标准的原生深拷贝 API：structuredClone()。

与基于文本序列化的 JSON 方案相比，structuredClone 采用了底层的结构化克隆算法（Structured Clone Algorithm）：

• 天然支持循环引用：内部维护了对象引用的映射表，遇到环形结构会自动复用新对象的对应指针，完全不会抛错；
• 完整保留内置类型：对 Date、RegExp、Map、Set、ArrayBuffer、TypedArray 等均能精确创建全新的深拷贝实例；
• 使用限制：由于算法要求数据必须能够跨线程（如 Web Worker）安全克隆，因此它依然不支持 Function、DOM 节点、WeakMap 以及属性的 Getter/Setter。如果克隆对象中包含函数，会抛出 DataCloneError。

// 原生 structuredClone 优雅处理循环引用与复杂内建类型
const complexData = {
  createdAt: new Date(),
  flags: new Set(["admin", "editor"]),
  regex: /^[a-z0-9_-]+$/i,
  meta: { count: 42 }
};
complexData.self = complexData; // 建立循环引用

// 执行现代原生深拷贝
const modernClone = structuredClone(complexData);

console.log(modernClone.createdAt instanceof Date); // true（依然是标准的 Date 实例）
console.log(modernClone.flags.has("admin"));         // true（Set 集合与数据完美保留）
console.log(modernClone.self === modernClone);       // true（循环引用指针正确闭环，且与原对象隔离）
console.log(modernClone !== complexData);            // true

3. 复杂复杂业务与遗留环境的稳妥方案

对于需要兼容低版本运行时，或者对象中包含方法、自定义类原型链的场景，推荐使用经过充分生产验证的深拷贝方案：

• 成熟第三方库：使用 Lodash 的 cloneDeep（import cloneDeep from 'lodash/cloneDeep'），具备最完善的类型兼容与边界处理能力；
• 核心自研深拷贝函数：必须利用 WeakMap 缓存已被拷贝的对象引用以破解循环引用，并显式判断 Date、RegExp 等类型调用对应的构造函数重建。

图5：深拷贝技术方案选型决策树与安全边界总结

五、全文核心结论速查

回顾全文，我们可以把 JSON.parse(JSON.stringify(obj)) 的适用法则归纳为两句话：“纯数据简单用，遇复杂立刻停”。

在日常开发中，不可将其视作万能的深拷贝手段。一旦涉及用户复杂输入、富交互组件数据、日期对象或集合类型，请优先采用现代标准的 structuredClone() 或成熟的 cloneDeep 方案，从根本上杜绝静默数据丢失与潜在的生产环境崩溃故障。