structuredClone()是目前最值得优先尝试的深拷贝方案，它原生支持且能正确处理date、Regexp、map、Set等类型及循环引用，但不支持函数、undefined、symbol；兼容性不足时可选lodash.cloneDeep()。
javaScript 没有内置可靠的通用深拷贝方法，jsON.parse(json.stringify(obj)) 看似简单，但会丢函数、undefined、Symbol、Date、regexp、Map、Set、循环引用等，实际项目中直接用它等于埋雷。
为什么 structuredClone() 是目前最值得优先尝试的方案
这是浏览器和 node.js（v17.0+）原生支持的真正深拷贝 API，能正确处理 Date、RegExp、Map、Set、ArrayBuffer、TypedArray、Error、Blob、URL 等，也支持循环引用 —— 前提是目标环境支持。
- node.js 需 v17.0+ 且启用
--experimental-structured-cloning（v18.15+ 和 v20.0+ 默认启用） - chrome 98+、firefox 94+、safari 15.4+ 已支持；edge 同 Chromium 版本
- 不支持函数、undefined、Symbol（报错），这点和
JSON.stringify一致，但至少明确抛错，而不是静默丢失
用法很简单：const clone = structuredClone(original)。遇到不支持时，它会直接抛出 TypeError: structuredClone is not defined，比静默失败更容易定位问题。
lodash.cloneDeep() 在兼容性要求高时仍是务实选择
当需要支持老旧浏览器（如 IE）、或必须保留函数/Symbol/undefined 时，lodash.cloneDeep() 仍是经过大量生产验证的稳妥方案。但它不是零成本：包体积大（约 70KB min+gzip），且对自定义类实例默认只拷贝属性，不调用构造函数或原型方法。
立即学习“Java免费学习笔记（深入）”；
- 注意它对
new Date()、/regex/g、new Map()等内置对象能正确处理 - 若对象含自定义类实例（如
class User {}），需配合cloneDeepWith手动处理构造逻辑 - 性能上比
structuredClone慢 2–5 倍（取决于嵌套深度和类型），但对多数前端场景无感
示例：const clone = _.cloneDeep({ a: 1, b: new Date(), c: /test/g })
手写简易深拷贝函数只适合学习，别进生产
网上常见递归 + typeof 判断的手写实现，看似可控，实则极易漏掉边界情况：WeakMap/WeakSet 无法遍历、arguments 对象类型特殊、promise 和 Generator 不该被“拷贝”而应被拒绝、document 节点或 window 引用一碰就崩……
- 哪怕加上循环引用检测（用 WeakMap 记录已访问对象），也难覆盖所有内置类型行为差异
- 比如
new number(42)和new Boolean(true)是对象，但JSON.stringify会转成原始值，手写逻辑稍有不慎就和 JSON 行为不一致 - 真正需要极致控制的场景（如状态序列化、跨 worker 通信），应明确约束输入类型，而非试图“通吃”
真要写，至少先加一层防御：if (obj === NULL || typeof obj !== 'Object') return obj，再分 Array/Object/Date/RegExp 等处理 —— 但这只是起点，不是终点。
深拷贝的代价常被低估：先问自己是否真的需要
很多场景下所谓“深拷贝需求”，其实是状态管理混乱或设计过早优化的结果。例如：
- react 中用
useState更新嵌套对象，用展开运算符或 Immer 更安全高效 - 配置合并（如
Object.assign或lodash.merge）不需要完整深拷贝 - 仅读取或临时计算时，用
structuredClone或cloneDeep没问题；但高频操作（如每帧深拷贝渲染数据）可能成为性能瓶颈
真正棘手的从来不是“怎么拷”，而是“哪些字段不该拷”“哪些引用该保留”“拷完后如何校验一致性”——这些没法靠一个函数解决。