structuredClone() 提供了原生深拷贝能力，能正确处理 Date、RegExp、Map、Set、ArrayBuffer 及循环引用，相比 JSON.parse(JSON.stringify()) 更安全高效，且支持跨上下文数据传输；但无法克隆函数、DOM 节点和 Symbol 属性，不保留原型链和不可枚举属性，适用于状态快照、Undo/Redo 和函数式编程中的不可变数据模拟。
结构化克隆（
structuredClone()）是JavaScript提供的一种原生深拷贝机制，它能够创建对象或值的深度副本，并且在处理复杂数据类型和循环引用方面，比传统的
JSON.parse(JSON.stringify())方法拥有显著的优势，但同时也有其特定的局限性，比如无法克隆函数或DOM节点。
如何利用 structuredClone()
深拷贝对象，以及它相比 JSON.parse(JSON.stringify())
的优势和限制有哪些？
利用
structuredClone()进行深拷贝非常直接，它是一个全局函数，接收一个值作为参数，并返回该值的深度副本。
const originalObject = {
name: 'Alice',
age: 30,
birthDate: new Date(),
hobbies: ['reading', 'coding'],
details: {
city: 'New York',
zip: 10001
},
// 模拟一个循环引用
selfRef: null
};
originalObject.selfRef = originalObject;
const clonedObject = structuredClone(originalObject);
console.log(clonedObject);
console.log(clonedObject === originalObject); // false
console.log(clonedObject.details === originalObject.details); // false
console.log(clonedObject.birthDate === originalObject.birthDate); // false
console.log(clonedObject.selfRef === clonedObject); // true (循环引用被正确处理)这个API的出现，让深拷贝这个曾经有点让人头疼的问题，变得异常简单且高效。它就像是浏览器内部用于
postMessage传递数据的那套机制被直接暴露了出来，可靠性自然不在话下。
structuredClone()
相较于 JSON.parse(JSON.stringify())
的核心优势体现在哪些方面？
说实话，过去我们谈到深拷贝，很多时候会不自觉地想到
JSON.parse(JSON.stringify(obj))。这个方法确实简单粗暴，在某些场景下也够用，但它存在不少“硬伤”。
structuredClone()的出现，可以说就是为了弥补这些不足。
一个显著的优势在于它能处理更多复杂的数据类型。想象一下，如果你要拷贝一个包含
Date对象、
RegExp正则表达式、
Map或
Set集合，甚至是
ArrayBuffer或
TypedArray的对象，
JSON.parse(JSON.stringify())会怎么做？
Date对象会变成ISO格式的字符串，
RegExp会变成一个空对象，
Map和
Set会直接丢失它们内部的数据，
ArrayBuffer和
TypedArray更是直接被忽略。这简直是灾难。而
structuredClone()则能正确地复制这些类型，它们在克隆后依然保持原有的类型和值，比如
Date还是
Date实例，
Map依然是
Map实例，并且包含了所有数据。
另一个非常关键的优势是对循环引用的原生支持。这是
JSON.parse(JSON.stringify())的一个死穴。一旦对象内部存在循环引用（比如对象A引用了对象B，对象B又引用了对象A），
JSON.stringify()就会抛出
TypeError: Converting circular structure to JSON错误。这在处理复杂数据结构，尤其是像树形结构或图结构时，是相当常见的场景。
structuredClone()完美地解决了这个问题，它能够识别并正确地处理循环引用，确保克隆出的对象也保持相同的引用关系，而不会陷入无限循环或报错。
性能上，对于大多数复杂对象，
structuredClone()通常也更高效。因为它是一个原生实现，直接在C++层面操作内存，避免了将对象转换为字符串再解析回对象的中间步骤，省去了大量的CPU开销和内存分配。这种原生优势在处理大型或频繁深拷贝的场景下，尤其明显。
最后，它还能保留一些特殊的内置对象实例，比如
Error对象（虽然
stack属性不被克隆，但
name、
message等会被保留）、
ImageData、
Blob、
File等。这些是
JSON.parse(JSON.stringify())完全无法触及的。
structuredClone()
在实际应用中存在哪些局限性或需要注意的地方？
尽管
structuredClone()强大，但它也不是万能的，在实际使用中还是有一些需要注意的限制：
一个主要的限制是它无法克隆函数（Function）。如果你尝试克隆一个包含函数的对象，这些函数属性会被直接忽略掉，不会出现在克隆后的对象中。这通常是因为函数往往与特定的执行上下文或闭包绑定，克隆它们可能没有太大意义，或者会引入不可预测的行为。同样，DOM节点、Error对象的stack
属性以及一些宿主对象（如
window对象）也无法被克隆。如果你需要拷贝包含这些类型的对象，就得考虑其他策略，或者手动处理这些特殊属性。
另一个细节是它不会保留原型链。
structuredClone()会创建一个全新的普通对象，而不是保持原对象的
prototype。这意味着，如果你的原始对象是某个类的实例，例如
new MyClass()，那么克隆后的对象将不再是
MyClass的实例。它会变成一个普通的
{} 对象，其 __proto__会指向
Object.prototype。这对于依赖
instanceof或原型链继承行为的代码来说，可能会导致问题。
此外，它只克隆可枚举（enumerable）的属性。通过
Object.defineProperty定义的不可枚举属性，或者某些内置对象上的不可枚举属性，都不会被复制。同样，Symbol类型的属性也不会被克隆。这在某些需要精确复制所有属性（包括元数据）的场景下，可能需要额外的处理。
虽然
structuredClone()性能通常很好，但对于极其庞大且嵌套层级非常深的对象，深度遍历和复制依然会消耗一定的计算资源。在这些极端情况下，可能需要评估是否真的需要全量深拷贝，或者能否通过其他方式（比如不可变数据结构库）来优化。
除了深拷贝，structuredClone()
在哪些场景下还能发挥其独特作用？
structuredClone()的核心能力是创建独立的数据副本，这不仅仅局限于我们通常理解的“深拷贝”场景，它在一些特定的应用场景下，能发挥出非常独特且关键的作用。
一个非常典型的应用场景是跨上下文的数据传输。在Web开发中，我们经常需要在不同的JavaScript执行上下文之间传递数据，比如在主线程和Web Worker之间，或者在父窗口和iframe之间。这些场景下，
postMessageAPI 就是用来传递数据的。而
postMessage的底层机制，正是利用了结构化克隆算法。当你通过
postMessage发送一个复杂对象时，实际上就是它的一个结构化克隆被传递到了目标上下文。这意味着你不需要手动序列化（如
JSON.stringify）和反序列化，就可以安全、高效地传递包含日期、正则、Map、Set等复杂类型的对象，并且自动处理循环引用。这极大地简化了跨上下文通信的复杂性。
再比如，在构建具有撤销/重做（Undo/Redo）功能的应用程序时，
structuredClone()简直是神器。为了实现撤销，我们需要在每次状态变更前保存当前状态的一个“快照”。如果直接保存引用，后续修改会影响到历史状态。使用
structuredClone()可以轻松地创建一个完全独立、互不影响的状态副本，将其推入历史栈，从而实现可靠的撤销功能。
在函数式编程的实践中，我们常常强调不可变性，即函数不应该修改其输入数据，而是返回一个新的修改后的数据。当一个函数需要对传入的对象进行操作时，为了避免副作用，它通常会先创建一个该对象的副本。此时，
structuredClone()提供了一个简洁高效的方式来获取一个完全独立的副本，确保原始数据不被意外修改，从而更好地遵循函数式编程范式。
此外，它还可以用于模拟不可变数据结构。虽然JavaScript本身没有像ClojureScript那样的持久化数据结构，但通过在每次修改操作前，对对象使用
structuredClone()创建一个新版本，可以模拟出某种程度上的不可变性。这有助于减少程序中的意外状态变更，提高代码的可预测性和可调试性。
