JavaScript 结构化克隆 vs. JSON：为什么前者是真正的深拷贝方案

JSON 方法之所以流行，是因为它足够简单，而且几乎所有环境都支持。但它的本质是文本序列化与反序列化，而不是对象复制。这决定了它在面对 JavaScript 丰富的内置类型时，会有一系列天然的缺陷。

JSON 序列化到底丢失了什么

当你调用 JSON.stringify() 时，它只关心如何把数据转换成有效的 JSON 字符串。这意味着许多 JavaScript 特有的值会被直接忽略或转换。

• 函数、undefined、Symbol：在序列化过程中被静默丢弃。
• Date 对象：被转换成 ISO 格式的字符串，反序列化后是一个字符串，不再是 Date 实例，丢失了所有原型方法。
• Map 和 Set：被序列化为空对象 {}，其内部的键值对全部丢失。
• RegExp 对象：同样变成空对象。
• ArrayBuffer、TypedArray、Blob：这类二进制数据要么导致序列化失败，要么被转换成低效的 base64 字符串。
• 循环引用：对象图中如果存在 A 引用 B，B 又引用 A 的情况，JSON.stringify 会直接抛出错误。

这些限制让 JSON 方案只适合“纯数据对象”（POJO）。一旦你的数据结构稍微复杂一点，用它做深拷贝就相当于在埋雷。

structuredClone：为复制对象图而生的原生 API

structuredClone() 是浏览器和现代 Node.js 运行时提供的全局方法，它专门为实现深拷贝设计。它的核心优势在于，它不是在玩“文本转换”的把戏，而是按照结构化克隆算法直接复制内存中的对象图。

这意味着它能保留更多类型的语义：

const original = {
  createdAt: new Date('2023-01-01'),
  uniqueIds: new Set([1, 2, 3]),
  settings: new Map([['theme', 'dark'], ['notifications', true]]),
  buffer: new Uint8Array([1, 2, 3, 4])
};

const clone = structuredClone(original);

console.log(clone.createdAt instanceof Date); // true，仍然是Date实例
console.log(clone.uniqueIds instanceof Set);  // true
console.log(clone.settings.get('theme'));     // 'dark'，Map内容被保留
console.log(clone.buffer instanceof Uint8Array); // true，二进制数据被复制

更重要的是，它能正确处理循环引用，这是很多自定义深拷贝函数都容易出错的地方。

const node = { value: 'root' };
node.self = node; // 循环引用

const clonedNode = structuredClone(node);
console.log(clonedNode.self === clonedNode); // true，克隆体内部保持了正确的引用关系
console.log(JSON.parse(JSON.stringify(node))); // 直接抛出 TypeError

对于包含大量二进制数据的场景（比如处理 Canvas 图像帧或 WebSocket 消息），structuredClone 还可以通过 transfer 选项移交所有权，避免昂贵的字节复制，这对性能敏感的应用至关重要。

性能对比：并非总是越快越好

普遍认为，structuredClone 在拷贝常规对象时，因为避免了字符串的编解码开销，通常比 JSON 方案快 2 到 3 倍。但这有一个重要前提：数据规模适中。

所以，性能选择不是绝对的。如果你明确知道自己在拷贝一个巨大的二进制缓冲区，可能需要评估是使用 transfer 转移所有权，还是采用其他流式处理方案。

它也不是万能钥匙：明确它的边界

尽管 structuredClone 更强大，但把它当成“终极深拷贝方案”也是一种误解。它有几个明确的限制：

1. 不拷贝函数：和 JSON 一样，函数属性会被丢弃。这是算法设计决定的，因为函数可能包含闭包和执行上下文。
2. 不保留原型链：一个类实例被克隆后，会变成一个普通对象，其 constructor 指向 Object。如果你的业务逻辑依赖原型方法，需要额外处理。
3. 不拷贝 DOM 元素：试图克隆一个 DOM 节点会抛出错误。
4. 存在兼容性窗口：它需要较新的运行时环境（Chrome 98+、Firefox 94+、Safari 15.4+、Node.js 18.13+）。在需要支持旧版浏览器或特定 Electron 版本的项目中，这可能是个问题。

因此，如果你的对象是自定义类的实例，且带有方法，structuredClone 并不能替代你在类内部实现的 clone() 方法。它解决的是“数据结构的克隆”，而非“对象行为的克隆”。

工程实践：如何做选择

在实际项目中，如何在这两种方案间做取舍？可以遵循一个简单的决策流：

首先，检查数据特征。 如果对象包含 Date、Map、Set、ArrayBuffer 或可能存在循环引用，应优先考虑 structuredClone。

其次，确认运行环境。 如果你的项目需要兼容旧版 Safari（15.3 及以下）或特定的嵌入式环境，structuredClone 可能不可用。这时，要么引入 polyfill 来模拟算法，要么退回到 JSON 方案并接受其类型丢失的限制（前提是业务允许）。

最后，考虑错误处理。 JSON.stringify 在遇到不可序列化内容时会抛出错误，你可以用 try...catch 包裹并执行降级逻辑。而 structuredClone 会抛出更具体的 DataCloneError，但错误后的兜底策略需要更仔细的设计。

一个实用的封装示例

在不确定环境或需要降级的场景下，可以做一个简单的工具函数：

function deepClone(obj) {
  // 优先使用原生 structuredClone
  if (typeof structuredClone === 'function') {
    try {
      return structuredClone(obj);
    } catch (e) {
      console.warn('structuredClone failed, fallback to JSON:', e);
    }
  }
  // 降级方案：仅适用于纯数据对象
  try {
    return JSON.parse(JSON.stringify(obj));
  } catch (e) {
    console.error('Both clone methods failed:', e);
    // 根据业务需求，这里可以选择返回空对象、抛出错误或尝试浅拷贝
    return {};
  }
}

这个封装体现了基本的渐进增强思路，但请注意，降级到 JSON 方案可能意味着数据丢失，这需要在业务层面评估是否可接受。

总结：理解本质差异

说到底，JSON.parse(JSON.stringify()) 和 structuredClone() 的强弱之分，源于它们根本目的的不同。

前者是为了跨语言数据交换，它必须遵循 JSON 文本格式的约束，因此会牺牲 JavaScript 的特定类型语义。

后者是为了在同一运行时内复制对象，它利用了环境对自身类型系统的理解，从而能实现语义更准确的克隆。

对于现代前端和 Node.js 应用，只要目标运行环境支持，structuredClone 都应该是深拷贝的首选。它更健壮、性能更好，并且能避免许多由类型转换引发的隐蔽 Bug。当然，在引入前，务必在团队的兼容性清单上再核对一遍，并清楚它的能力边界——没有哪个工具能解决所有问题，但选对了工具，能让你少解决很多不必要的问题。