深拷贝从JSON.parse到structuredClone：全类型方案与循环引用实战

上个月排查一个数据同步任务时，我发现线上某个对象的 createdAt 字段莫名其妙从时间对象变成了一串字符串，旁边的正则表达式直接变成了 {}。查了半天，组里的同事一脸无辜：“我用 JSON.parse(JSON.stringify(obj)) 做的深拷贝啊，这么写不是天经地义吗？”我当场就告诉他：从今天起，这个写法在我们项目里正式下岗了。

深拷贝这个需求太常见了，常见到很多人习惯性就用 JSON.stringify 来“偷懒”。但它是序列化工具，不是深拷贝工具，两者在语义上根本不是一回事。这篇文章不打算单纯批判 JSON.stringify，而是给出一套可以真正落地到业务里的深拷贝方案：从手写递归讲起，到处理各种特殊类型，再到循环引用、WeakMap 缓存，最后聊聊 ES6 时代之后出现的原生 structuredClone。你可以根据自己的项目环境选方案，而不是背一段代码就完事。

这篇文章适合三类人：被“深拷贝”面试题整懵的求职者、被线上数据怪相坑过的开发，以及想彻底搞明白“深拷贝到底在拷贝什么”的进阶者。后面写的都是我在真实项目里踩过的坑和验证过的方案，大家可以按需取用。

1. 深拷贝到底解决什么问题，JSON.stringify又错在哪里

1.1 先从引用赋值与浅拷贝说起

JavaScript 里对象是引用类型，这意味着把一个对象赋值给另一个变量时，其实只是复制了一个引用，两个变量指向同一块内存。很多人一开始都栽在过这里：

javascript复制const origin = { name: 'Tom', info: { age: 18 } };
const copied = origin;
copied.info.age = 20;
console.log(origin.info.age); // 20

我只是想复制一份对象，结果改 copied 的时候把 origin 也改了。这就是引用赋值的问题：它根本没复制数据，只是多了一个指向同一数据的“遥控器”。

浅拷贝（比如 Object.assign 或者展开运算符）比引用赋值前进了一步，它能把第一层属性复制出来，但第二层及更深层的嵌套对象仍然是共享引用：

javascript复制const shallow = { ...origin };
shallow.info.age = 20;
console.log(origin.info.age); // 20，还是被改了

到这里，核心需求就出来了：我们需要一个深拷贝函数，它要递归地复制对象里的每一层，直到最底层的原始值，而且任意一层都不能互相影响。生活里有个很贴切的类比：浅拷贝是拿了一张通讯录封面，深拷贝是把整本通讯录从头到尾复印一遍，复印稿上怎么涂改都不影响原件。

1.2 JSON.stringify的真实崩溃现场

JSON.parse(JSON.stringify(obj)) 之所以流行，是因为它看起来就像一个优雅的深拷贝：先把对象转成字符串，再把这个字符串解析成一个全新的对象。但问题恰恰出在这个“中间表示”上，JSON 是文本格式，它天生无法表达 JavaScript 对象里的很多类型。

我整理了一份在我实际测试中稳定复现的对照表：

举一个更容易理解的例子。假设后端接口返回了一个对象，里面有 Date、RegExp、Map，还有一些 undefined 字段：

javascript复制const data = {
  id: 1,
  createdAt: new Date('2024-05-01T08:00:00Z'),
  pattern: /ab+c/gi,
  tags: new Map([['level', 'high']]),
  callback: function () { console.log('hello'); },
  empty: undefined
};

const copied = JSON.parse(JSON.stringify(data));
console.log(copied);
// {
//   id: 1,
//   createdAt: '2024-05-01T08:00:00.000Z',
//   pattern: {},
//   tags: {},
// }
// callback 和 empty 直接消失

看起来只是“丢了一些字段”，但在真实业务里这一点都不好笑。用户信息里的 updatedAt 从时间对象变成字符串，前端组件可能直接调用 getTime() 然后报错；正则表达式变成 {}，校验逻辑彻底失效；Map 变空，状态管理直接错乱。你根本来不及等待用户发现，线上告警就已经响了。

1.3 为什么“序列化”不能替代“克隆”

有人可能会说：“我的业务数据很简单，没有这些奇奇怪怪的类型，JSON 方案够用了。”我对这种说法持保留意见。项目的复杂度是会演进的，今天你只觉得对象里有数字和字符串，下个月就可能加入 Date 字段、Map 配置、Set 去重集合。到那时候，当初图省事埋下的坑会一次性爆发。

更本质的原因在于：JSON.stringify 是序列化工具，它的职责是把内存中的对象转换成可以传输或存储的文本格式；JSON.parse 是反序列化工具，它的职责是把文本恢复成对象。从语义上看，这套流程根本不关心“对象的内存结构如何保持”，它只关心“能否变成 JSON 文本，再变回来”。把这种工具当成深拷贝用，是把“能跑”当成了“正确”，属于典型的语义错位。

我在项目里遇到过最离谱的一次，是某个用户配置对象里有一个 undefined 字段，经过 JSON 深拷贝之后整个字段消失了。后续代码判断 if ('someField' in obj)，结果走了完全错误的分支，导致数据提交失败。排查半天才发现是深拷贝的锅。从那以后我就定了一条规矩：生产代码里禁止用 JSON.parse(JSON.stringify(obj)) 做通用深拷贝。

2. 第一版手写深拷贝：递归遍历的基本盘

2.1 从浅拷贝到深拷贝

抛弃 JSON 方案之后，最自然的思路就是手写递归。如果你去面试，让面试官现场写一个深拷贝，大部分人一开始都会写类似这样的版本：

javascript复制function deepClone(obj) {
  if (typeof obj !== 'object' || obj === null) {
    return obj;
  }
  const result = Array.isArray(obj) ? [] : {};
  for (const key in obj) {
    result[key] = deepClone(obj[key]);
  }
  return result;
}

逻辑很直白：遇到原始值直接返回，遇到对象就创建一个新的容器，然后遍历原对象的每一个属性，对每个属性值做递归拷贝。对于普通的嵌套对象和数组，这个版本是能工作的：

javascript复制const original = { a: 1, b: { c: [1, 2, 3], d: 'hello' } };
const cloned = deepClone(original);
cloned.b.c.push(4);
console.log(original.b.c); // [1, 2, 3]，不受影响

我最初也是这么写的，当时觉得深拷贝不过如此。但很快，我就被现实教育了。

2.2 隐藏的无底洞：特殊对象、原型与循环引用

把这个第一版深拷贝拿到真实的业务数据上跑，问题一个接一个地蹦。

Date 对象被拷贝成了空对象。因为 for...in 遍历对象属性时，Date 的数值时间戳是内部插槽，不是可枚举属性，所以遍历不到任何东西，返回一个 {}。RegExp 也一样，内部 source 和 flags 不是普通属性，for...in 拿不到。Map 和 Set 的条目存在内部插槽里，遍历出来也是空对象。如果遇到循环引用，比如：

javascript复制const obj = {};
obj.self = obj;
deepClone(obj); // 栈溢出：Maximum call stack size exceeded

因为递归没有出口，会无限往下钻，直到把调用栈撑爆。

再看原型链的问题。这个版本用了字面量 {} 创建结果对象，它会带上 Object.prototype。但如果被克隆对象是一个自定义 class 的实例，比如：

javascript复制class User {
  constructor(name) {
    this.name = name;
  }
  greet() {
    console.log(`hi, ${this.name}`);
  }
}

const user = new User('Tom');
const cloned = deepClone(user);
console.log(cloned instanceof User); // false

原型链丢了。拷贝出来的对象只剩下一堆普通属性，任何挂在 prototype 上的方法都没了。这已经不能算“深拷贝”了，更像是“剥皮拷贝”。

2.3 深拷贝的核心是“按类型复制”，不是“按对象抄写”

经历了这一轮翻车之后，我意识到一个关键问题：深拷贝不能一刀切地用“遍历属性”来解决，它必须针对不同类型采用不同的复制策略。JavaScript 的对象世界远不止普通对象和数组，它还有 Date、RegExp、Map、Set、ArrayBuffer、TypedArray、DataView 等等。

真正的深拷贝应该理解为：你拿到一个值，先判断它是什么类型，然后根据类型选择对应的复制方式。原始值直接返回；普通对象和数组递归复制属性；Date 新建一个同时间戳的实例；RegExp 新建一个同正则文本和 flags 的实例；Map 递归复制键值对；Set 递归复制元素……

这是一套“按类型分发”的思路。从这一刻开始，我们的深拷贝实现就不再是“遍历对象的属性”，而是一个“类型工厂”：我负责造出和原始值等价的、内存独立的新值。

3. 类型识别与特殊对象的复制策略

3.1 typeof和constructor都不可靠，Object.prototype.toString才靠谱

要做到按类型分发，第一步是准确地识别类型。很多人第一反应是用 typeof，但它的能力非常有限：typeof null 是 'object'，typeof [] 也是 'object'，typeof new Date() 还是 'object'。它只能区分原始值和对象，没法在对象类型内部做进一步细分。

有人会改用 constructor，比如 obj.constructor === Date，但这个方案同样不靠谱。constructor 属性可以被改写，而且在跨 iframe 的场景下，不同全局对象里的构造函数并不相等，判断会失效。

我常用的方案是 Object.prototype.toString.call(obj)。它返回的字符串形如 '[object Type]'，Type 就是具体的内置类型标签：

javascript复制Object.prototype.toString.call(null);       // '[object Null]'
Object.prototype.toString.call([]);         // '[object Array]'
Object.prototype.toString.call(new Date()); // '[object Date]'
Object.prototype.toString.call(/ab+c/gi);   // '[object RegExp]'
Object.prototype.toString.call(new Map());  // '[object Map]'
Object.prototype.toString.call(new Set());  // '[object Set]'

取一下中间的类型名，就能得到准确的类型标识。唯一需要注意的是 Symbol.toStringTag 可以自定义对象标签，但这主要影响用户自定义类，对内置类型判断影响不大。

在实际代码里，我习惯先把对象类型取出来，再做一个 switch 分发：

javascript复制function getType(obj) {
  return Object.prototype.toString.call(obj).slice(8, -1);
}

3.2 Date、RegExp、Map、Set、ArrayBuffer逐个击破

接下来，就是为每一种特殊类型写复制逻辑。

Date 的复制

javascript复制function cloneDate(obj) {
  return new Date(obj.getTime());
}

为什么要用 getTime()？因为 Date 内部的时间值是一个数字，用这个数字新建实例，可以保证拷贝出的 Date 和原 Date 代表同一个时间点。直接把 obj 传进去也是可以的，但用 getTime() 更明确。

RegExp 的复制

javascript复制function cloneRegExp(obj) {
  const reg = new RegExp(obj.source, obj.flags);
  reg.lastIndex = obj.lastIndex;
  return reg;
}

source 是正则的文本内容，flags 是修饰符，比如 gi。这里还有个容易被忽略的细节：lastIndex。如果一个正则是带 g 或 y 修饰符的，它的 lastIndex 可能记录了上次匹配的位置。拷贝时如果不带上，复制出的正则可能从 0 开始匹配，行为就和原来不一样了。

Map 的复制

javascript复制function cloneMap(obj, map) {
  const result = new Map();
  map.set(obj, result); // 先登记，避免循环引用
  obj.forEach((value, key) => {
    result.set(deepClone(key, map), deepClone(value, map));
  });
  return result;
}

Map 的 key 和 value 都可能是对象，所以都要递归深拷贝。注意，新建 result 之后要立刻把“原始 Map -> 克隆 Map”的映射登记到缓存里（这里用了 map 参数，稍后会讲），否则 Map 内部如果引用自身，会陷入循环。

Set 的复制

javascript复制function cloneSet(obj, map) {
  const result = new Set();
  map.set(obj, result);
  obj.forEach(value => {
    result.add(deepClone(value, map));
  });
  return result;
}

和 Map 类似，Set 的每个元素都可能是对象，需要递归拷贝。

ArrayBuffer 的复制

javascript复制function cloneArrayBuffer(obj) {
  return obj.slice(0);
}

ArrayBuffer 的 slice 方法会返回一个新的独立 buffer。TypedArray 和 DataView 更复杂一些，因为它们需要基于新的 buffer 重新构建，我在生产代码里也会处理，但为了控制复杂度，可以先用 slice 覆盖 ArrayBuffer 的常见场景。

3.3 递归会爆栈，迭代法来接盘

递归方案虽然直观，但有个先天的风险：如果嵌套层级非常深，会触发调用栈溢出。比如说一个对象被嵌套了 2 万层，递归下去 JavaScript 引擎就会报 Maximum call stack size exceeded。

我遇到过一个极端案例，某个配置对象是从 XML 转 JSON 生成的，嵌套层级深得离谱，用递归深拷贝直接在测试环境崩了。后来我改成迭代法：

javascript复制function deepCloneIterative(root) {
  if (!isObject(root)) return root;

  const rootClone = createCloneTarget(root);
  const cache = new WeakMap([[root, rootClone]]);
  const stack = [{ source: root, target: rootClone }];

  while (stack.length) {
    const { source, target } = stack.pop();
    // 遍历属性，发现对象值就在 cache 里登记并创建 target，然后推入栈中
  }

  return rootClone;
}

核心思路是用一个显式的栈代替调用栈。每次从栈里取出一个待处理的节点，遍历它的属性；如果属性值是对象，就在缓存里创建对应的 clone 并登记，然后把这对父子节点重新入栈。这样无论嵌套多深，都只是一个循环的问题，不会爆栈。代价是代码比递归版复杂，需要手动维护缓存和遍历顺序。对于大多数业务场景，递归版已经足够了，但如果你处理的数据来源不可控，迭代版会更稳。

4. 循环引用、缓存机制与WeakMap

4.1 循环引用为什么会让深拷贝崩溃

循环引用指的是对象的某个属性直接或间接地指向它自身。最常见的例子：

javascript复制const obj = {};
obj.self = obj;

更复杂的还有 A 引用 B，B 引用 A。这种结构在业务里其实非常常见，尤其是 DOM 引用、事件回调、双向链表、依赖图这些场景。一旦深拷贝函数没有处理循环引用的能力，它就会在递归中无限循环，直到栈溢出。

有人可能会说：“那我用 JSON.parse(JSON.stringify(obj)) 不就抛错了吗？至少不会死循环。”但抛错本身不是解决方案，它只是把这个场景判定为“不可拷贝”。现实里的数据不会因为你的拷贝函数不支持就放弃循环引用，唯一正确的做法是让拷贝函数支持它。

4.2 WeakMap缓存：解决循环引用，也避免内存泄漏

处理循环引用的标准思路是“登记”。在递归过程中，每拷贝一个对象，就把“原始对象 -> 拷贝对象”的关系保存到一个缓存里。下次再遇到同一个原始对象时，直接从缓存里取出已经拷贝好的对象，而不再重复递归。这样循环就被切断了。

这个缓存我强烈建议用 WeakMap。代码长这样：

javascript复制function deepCloneAndCache(obj, cache = new WeakMap()) {
  if (obj === null || typeof obj !== 'object') return obj;
  if (cache.has(obj)) return cache.get(obj);

  // 创建目标对象，并按类型处理
  // 创建之后先登记到 cache，再递归拷贝子属性
}

举个例子，给带缓存但不处理特殊类型的基础版本：

javascript复制function deepClone(obj, cache = new WeakMap()) {
  if (obj === null || typeof obj !== 'object') return obj;
  if (cache.has(obj)) return cache.get(obj);

  const result = Array.isArray(obj) ? [] : {};
  cache.set(obj, result);

  Reflect.ownKeys(obj).forEach(key => {
    if (typeof key === 'symbol') {
      result[key] = deepClone(obj[key], cache);
    } else {
      result[key] = deepClone(obj[key], cache);
    }
  });

  return result;
}

注意，cache.set(obj, result) 必须在递归遍历子属性之前执行，而不是在最后执行。如果放在最后，遇到自引用的对象时，递归到 obj.self 会再次进入 deepClone(obj)，此时缓存里还没有 result，于是又创建一遍、又递归一遍，循环永远断不了。正确顺序是：先创建空壳、登记缓存、再填充内容。

4.3 为什么不用Map，一定要用WeakMap

同样可以实现“登记”功能，为什么要用 WeakMap 而不是普通 Map？这涉及垃圾回收的差异。

Map 对 key 是强引用。也就是说，只要这个 Map 还活着，它里面的 key 对象就不会被垃圾回收。假设你拷贝一个很大的临时对象，拷贝完成后原对象早就该被回收了，但由于它作为 Map 的 key 还存在于缓存里，它和它的整个引用树都占着内存不放，这就造成了内存泄漏。在低端移动设备上，这种泄漏很快就能把页面拖垮。

WeakMap 对 key 是弱引用，它不会阻止垃圾回收机制回收 key 对象。如果没有其他地方引用这个原始对象了，垃圾回收器就可以把它收走，WeakMap 里的对应条目也会自动失效。

我打过一个比方：Map 像储物柜，东西拿走了柜子还占着位置；WeakMap 像便利贴，东西被拿走了便利贴也就自然失去了意义，风一吹就没了。所以，在深拷贝这种生命周期短、临时性强的场景里，WeakMap 是唯一合理的选择。

5. ES6时代以后的原生方案：structuredClone与MessageChannel

5.1 structuredClone：浏览器和Node都内置的深拷贝神器

继续手写深拷贝的同时，我还注意到一个趋势：现代运行时开始提供原生的深拷贝能力，这个能力就是 structuredClone。

structuredClone 是基于 Web 平台的结构化克隆算法（Structured Clone Algorithm）对外开放的 JavaScript API。Chrome 98、Firefox 94、Safari 15.4 以及 Node.js 17 之后，都原生支持了这个函数。它的用法极其简单：

javascript复制const cloned = structuredClone(original);

它支持的类型非常全：Date、RegExp、Map、Set、ArrayBuffer、TypedArray、DataView、Blob、File、ImageData、Error 对象等等。更重要的是，它原生支持循环引用，不会报错，也不会死循环。

我原来看不上这个 API，觉得它出现得晚、兼容性不够。但当我真的在一个内部工具里把自研深拷贝换成 structuredClone 之后，删掉了将近 100 行代码，而且没有再为“这个类型没处理”“那个类型又丢了”的问题烦恼过。对于一个不需要兼容老环境、数据结构也符合规范的项目来说，用它就够了。

它的局限也摆在明面上：不支持函数，不支持 Symbol 作为值，不支持 DOM 节点，用户自定义 class 实例会被拷贝成普通对象，原型链上的自定义方法不会保留。这些限制和结构化克隆的定位有关：它是为了在不同上下文之间安全传输数据而设计的，不是为了让对象保持完整的“身份信息”。

5.2 MessageChannel：结构化克隆的异步往事

在 structuredClone 出现之前，前端圈有人用 MessageChannel 来“白嫖”结构化克隆算法。原理很简单：postMessage 在传递消息时会使用结构化克隆算法复制数据，那么我们把对象 post 给另一个端口，再从另一个端口接收，就能拿到一个深拷贝结果：

javascript复制function structuredCloneViaMessageChannel(obj) {
  return new Promise(resolve => {
    const { port1, port2 } = new MessageChannel();
    port2.onmessage = e => resolve(e.data);
    port1.postMessage(obj);
  });
}

// 使用示例
async function test() {
  const cloned = await structuredCloneViaMessageChannel({ name: 'Tom', date: new Date() });
  console.log(cloned);
}

这个方案在当时算是一个不错的 trick，但它有两个硬伤：第一，postMessage 是异步的，所以这个深拷贝函数也只能是异步的，你没法在一个同步函数里直接拿到拷贝结果；第二，它在某些运行时里会有限制，比如传递包含 Function 或 DOM 节点的对象时会抛异常。

现在回头看，这个方案更像是一个过渡期的 hack。它证明了结构化克隆算法的价值，但也暴露出“没有原生同步 API”的尴尬。后来规范直接开放了 structuredClone，这种 MessageChannel 的写法就慢慢退出了舞台。我在老项目里偶尔还会看到这种代码，一般都会建议换掉。

5.3 原生API和手写方案怎么选

这其实是个务实的问题。我的判断标准就一条：你能接受 structuredClone 的边界，就用它；不能接受，就用手写深拷贝。

用 structuredClone 的条件是：

• 运行环境支持（现代浏览器、Node 17 以上）
• 数据里没有函数、Symbol、DOM 节点
• 对象不需要保持自定义 class 的原型链
• 拷贝精度要求足够高，不允许出现 Date 变字符串这类问题

需要手写深拷贝的条件是：

• 要兼容老环境
• 需要定制拷贝策略，比如某些字段需要脱敏、忽略或者特殊映射
• 对象里有函数、Symbol 等 structuredClone 不支持的类型，但你仍希望保留某种行为
• 需要精确控制原型链，让自定义 class 实例拷贝后仍然是同 class 实例

在我自己的项目里，新代码优先用 structuredClone，老代码在改造时逐步替换 JSON 方案，自研的 deepClone 则作为一个独立工具函数留给特殊场景用。三者并不互斥，关键是分清边界。

6. 一个可以直接用于生产环境的deepClone实现

6.1 设计目标与取舍

如果你决定手写深拷贝，我建议你不要只写一个“能跑通简单对象”的玩具版本，至少要覆盖这些能力：

• 支持 Date、RegExp、Map、Set、ArrayBuffer
• 支持循环引用，不栈溢出
• 保留原型链，用户自定义 class 的实例拷贝后仍然是同 class
• 支持 Symbol key，以及不可枚举属性
• 支持稀疏数组
• 对外提供同步调用能力，不需要 async/await

同时也要明确一些取舍：函数直接返回引用（不深拷贝）、Symbol 值直接返回、WeakMap / WeakSet 不做深拷贝（因为弱引用不可枚举）。这些不是缺陷，而是合理的技术边界。

6.2 完整代码与逐行解析

下面这段代码是我在当前生产环境中使用的简化版 deepClone，去掉了一些和业务强相关的定制逻辑，保留了通用核心：

javascript复制function deepClone(obj, cache = new WeakMap()) {
  // 基础类型直接返回
  if (obj === null || typeof obj !== 'object') return obj;

  // 命中缓存，说明已经拷贝过，直接返回上次的拷贝结果
  if (cache.has(obj)) return cache.get(obj);

  const type = Object.prototype.toString.call(obj).slice(8, -1);

  // 逐个处理内置特殊类型
  switch (type) {
    case 'Date':
      return new Date(obj.getTime());
    case 'RegExp': {
      const reg = new RegExp(obj.source, obj.flags);
      reg.lastIndex = obj.lastIndex;
      return reg;
    }
    case 'Map': {
      const clone = new Map();
      cache.set(obj, clone); // 先登记，防止循环引用
      obj.forEach((value, key) => {
        clone.set(deepClone(key, cache), deepClone(value, cache));
      });
      return clone;
    }
    case 'Set': {
      const clone = new Set();
      cache.set(obj, clone);
      obj.forEach(value => {
        clone.add(deepClone(value, cache));
      });
      return clone;
    }
    case 'ArrayBuffer':
      return obj.slice(0);
  }

  // 处理数组与普通对象
  const clone = Array.isArray(obj)
    ? []
    : Object.create(Object.getPrototypeOf(obj));
  cache.set(obj, clone);

  // 数组处理：保留稀疏数组的空位
  if (Array.isArray(obj)) {
    for (let i = 0; i < obj.length; i++) {
      if (i in obj) {
        clone[i] = deepClone(obj[i], cache);
      }
    }
  } else {
    // 使用 Reflect.ownKeys 获取所有自身属性，包括 Symbol key 和不可枚举属性
    Reflect.ownKeys(obj).forEach(key => {
      const descriptor = Object.getOwnPropertyDescriptor(obj, key);
      if (descriptor && 'value' in descriptor) {
        // 数据属性：递归拷贝值
        Object.defineProperty(clone, key, {
          ...descriptor,
          value: deepClone(descriptor.value, cache),
        });
      } else {
        // 访问器属性：直接拷贝 getter/setter
        Object.defineProperty(clone, key, descriptor);
      }
    });
  }

  return clone;
}

这段代码看起来不短，但它把边界都兜住了。我来拆解几个关键点。

为什么用 Object.create(Object.getPrototypeOf(obj)) 创建普通对象？ 因为这样可以保留原型链。如果被拷贝对象是某个自定义 class 的实例，拷贝出来的对象实例仍然带有同一个原型，instanceof 判断是成立的。如果简单用 {}，原型链就断了。

为什么用 Reflect.ownKeys 而不是 for...in？ 因为 Reflect.ownKeys 返回的是对象自身的所有属性 key，包括字符串 key 和 Symbol key，而且能遍历到不可枚举属性。for...in 只能拿到可枚举的字符串属性，很多关键信息会丢。我们在做深拷贝时，要尽量保证信息不丢失，而不是只拷贝“看起来常见的那部分”。

为什么用 Object.getOwnPropertyDescriptor 和 Object.defineProperty？ 因为这样可以精确复制属性的描述符，包括 writable、enumerable、configurable。如果一个属性是只读的，拷贝出来的对象里它应该仍然是只读的，而不是变成可写的。用简单的属性赋值做不到这一点。

为什么 Map 和 Set 要先 cache.set 再遍历？ 原因前面讲过：如果 Map 内部有循环引用，先登记能保证递归时能命中缓存，直接返回，避免无限递归。这是一个很容易踩的坑，顺序写反就崩。

6.3 边界场景自测清单

写完深拷贝函数，总是要验证一遍，别直接往线上塞。我每次写都会跑一遍下面这些场景，你可以直接拿去买单：

• 普通对象嵌套：{ a: { b: { c: 1 } } }
• 数组嵌套：{ list: [{ id: 1 }, { id: 2 }] }
• 稀疏数组：const arr = [1, , 3];
• Date 对象：new Date('2024-01-01')
• RegExp 对象：new RegExp('ab+c', 'gi')
• Map：new Map([['key', { value: 1 }]])
• Set：new Set([{ id: 1 }])
• Symbol key：const s = Symbol('s'); const obj = { [s]: 1 };
• 不可枚举属性：Object.defineProperty(obj, 'hidden', { value: 1, enumerable: false })
• 循环引用：obj.self = obj
• 自定义 class 实例：class Foo { constructor() { this.x = 1 } }

每个场景跑完，都要检查拷贝结果和原对象的结构一致、类型一致、内存独立。尤其是循环引用，拷贝之后要让 clone.self === clone，而不是 clone.self === obj，这才是正确的。

7. 常见问题与排查技巧实录

7.1 高频踩坑速查表

我在各种项目里看了无数深拷贝的奇怪问题，很多都是同几类原因。这里整理一个排查速查表：

这张表是针对我在实践中遇到的高频问题的总结。如果你在排查深拷贝相关的 bug，先对号入座，大概率能省下不少时间。

7.2 性能真相与优化思路

关于深拷贝的性能，我实测下来有一个大概的印象：JSON.stringify 在纯 JSON 数据上的速度是非常快的，因为它的 C++ 底层做了大量优化；手写递归深拷贝则要慢一些，因为每次递归都要走函数调用、类型判断、属性遍历；structuredClone 介于两者之间，但在支持环境里通常比手写递归更快，因为它也是原生实现。

我本地的一个粗略测试数据（对象规模大约 10 万个小嵌套对象）：

这个数据不是绝对标准，但能说明一个趋势：如果性能是你的瓶颈，优先用 structuredClone，而不是继续压榨手写实现。如果你必须手写，也可以做一些优化：数据类型判断结果先缓存、尽量避免重复的 toString 调用、能用迭代法就用迭代法、减少中间临时对象的创建。

另外一条经验是别在热路径上频繁深拷贝。深拷贝的时间复杂度是 O(n)，对象越大、嵌套越深，开销越高。如果你只是需要某些字段，就不要拷贝整棵对象树，用“字段挑选手动复制”的方式更高效。

7.3 一些过来人的经验

最后分享几个我在实际工作中摸索出来的判断，不一定适用于所有项目，但值得参考。

第一，不要迷信“万能深拷贝”。深拷贝能够处理的类型再多，也不可能覆盖所有 JavaScript 运行时的行为。函数、DOM 节点、WeakMap、WeakSet 这些天然就不适合深拷贝。与其写一个无限膨胀的深拷贝函数，不如在设计数据模型时规避这些对象。

第二，深拷贝的代码要放在工具库里统一维护，不要在业务代码里随手写一个。我见过不同的业务模块各写各的深拷贝，有的处理了 Date，有的没处理，线上行为完全不一致。统一维护一个工具函数，改成 structuredClone 或者修复某个类型 bug 时，只需要改一个地方。

第三，业务测试里要覆盖深拷贝的边界。尤其是 Date、RegExp、Map、Set、循环引用这几类，最好写进单元测试里。它们不是罕见场景，而是真实业务里一定会遇到的场景。我在项目里加过一组深拷贝的测试用例，之后至少避免了三次线上故障。

最后

就我个人的习惯而言，现在我写代码时优先用 structuredClone，老环境里降级到自研的 deepClone，JSON 方案基本只用于和后端接口的数据交互，绝不再用它做通用深拷贝。

另外再分享一个小技巧：做日志记录或者数据脱敏时，不要傻傻地深拷贝整个对象。先用 Reflect.ownKeys 挑出需要的字段，再单独处理敏感信息，性能更好，也更安全。这个思路和深拷贝的取舍是一样的：工具是为人服务的，搞清楚你到底要什么，远比背一种写法重要。