UD5工具箱
structuredClone 和 JSON 方式哪种更好？
在大多数场景下 structuredClone 更好。它支持更多数据类型，能正确处理循环引用，且不会丢失 undefined、Date、RegExp 等类型信息。JSON 方式的唯一优势是兼容性更广，因为 structuredClone 不支持 IE 浏览器。如果你不需要支持 IE，建议优先使用 structuredClone。
展开运算符能实现深拷贝吗？
不能。展开运算符只执行浅拷贝，它只复制对象的第一层属性。如果属性值是嵌套对象或数组，复制的是引用而非值本身。例如 const obj = {a: {b: 1}}; const copy = {...obj}; copy.a.b = 2; 此时 obj.a.b 也会变成 2，因为 copy.a 和 obj.a 指向同一个对象。
structuredClone 不能克隆哪些类型？
structuredClone 无法克隆 Function、DOM 节点、Error 对象、WeakMap、WeakSet 等类型。尝试克隆这些类型会抛出 DataCloneError 异常。此外，对象的原型链、getter 和 setter 方法也不会被保留。在实际使用中，如果数据包含这些类型，需要手动处理。
为什么 JSON 方式不能处理循环引用？
JSON.stringify() 在序列化过程中没有内置循环引用检测机制。当遇到循环引用时，它会无限递归尝试序列化，最终抛出 "Converting circular structure to JSON" 异常。而 structuredClone 内部维护了一个引用表，在克隆过程中记录已处理的对象，再次遇到同一引用时直接复用已克隆的对象，从而正确处理循环引用。
structuredClone 的性能如何？
structuredClone 的性能与 JSON 方式大致相当，在某些场景下可能略快。但对于简单的小对象，JSON 方式的开销通常更低。structuredClone 的优势在于处理复杂对象时的正确性和可靠性。在性能敏感的场景中，建议根据实际数据结构进行基准测试来选择最合适的方案。
如何在生产环境中安全地使用深拷贝？
在生产环境中使用深拷贝时，建议遵循以下原则：首先，尽量避免不必要的深拷贝，优先考虑不可变数据模式。其次，使用 structuredClone 时要确保数据中不包含不支持的类型，可以先用 try-catch 包裹。最后，对于大型数据结构，考虑使用增量更新或不可变库（如 Immer）来减少深拷贝的性能开销。
深拷贝后修改属性会影响原始对象吗？
真正的深拷贝不会影响原始对象。这是深拷贝与浅拷贝的核心区别。经过正确的深拷贝后，新对象和原始对象在内存中完全独立，对任意一方的修改都不会传递到另一方。但如果使用了错误的拷贝方式（如展开运算符），修改嵌套属性时仍然会影响原始对象，这就是 Bug 的来源。
是否需要自己实现深拷贝函数？
在现代浏览器环境中，不需要。structuredClone 已经是标准 API，能够满足绝大多数深拷贝需求。只有在需要支持旧版浏览器或有特殊定制需求（如自定义类型的克隆逻辑）时，才需要考虑自己实现。自定义实现时要注意处理循环引用、特殊类型、性能优化等问题，建议使用经过社区验证的库如 lodash 的 cloneDeep。