优先用 structuredclone（现代环境），它支持循环引用、date、regexp、map、set 等复杂类型，性能最优；兼容旧浏览器或需处理函数/proxy 时选 _.clonedeep；json.parse(json.stringify()) 仅适用于纯数据对象，存在类型丢失和循环引用报错等缺陷。
直接说结论：需要深拷贝时，优先用 structuredClone（现代环境）；若需兼容旧浏览器或处理复杂类型（如 Map、Set、正则、循环引用），_.cloneDeep 更稳；而 JSON.parse(JSON.stringify()) 仅适合纯数据对象，且有明显缺陷。
structuredClone 是当前最优原生方案
Chrome 98+、Firefox 94+、Safari 15.4+ 已支持 structuredClone，它由引擎底层实现，性能远超其他方法：
- 执行速度最快，实测比
_.cloneDeep快 30%–60%，尤其在中大型对象上优势明显 - 天然支持
Date、RegExp、Map、Set、ArrayBuffer、TypedArray等，语义准确 - 自动处理循环引用，无需额外逻辑
- 不丢失函数以外的属性（仍不支持函数和
Symbol，这点与_.cloneDeep一致）
用法极简：const copy = structuredClone(original);
_.cloneDeep 的不可替代性场景
当项目需支持 IE 或旧版 Node.js（_.cloneDeep 仍是首选：
- 嵌套极深的对象（如配置树、AST 节点），
structuredClone在某些旧 Chromium 版本中存在栈深度限制 - 需要保留
undefined属性值（JSON方案会丢弃，structuredClone在部分早期版本也会） - 涉及自定义类实例且重写了
toJSON，而你希望按原始结构还原（_.cloneDeep可通过自定义遍历逻辑介入） - 已使用 Lodash 全局工具链，统一用
_.前缀降低认知负担
慎用的“伪原生”方案：JSON 方法
JSON.parse(JSON.stringify(obj)) 表面简洁，但实际隐患多：
- 函数、
undefined、Symbol、BigInt全部消失 -
Date变成 ISO 字符串，RegExp变成空对象 - 原型链、getter/setter、不可枚举属性全部丢失
- 遇到循环引用直接报错：
TypeError: Converting circular structure to JSON
仅建议用于临时调试或已确认为纯 JSON 兼容结构的简单配置对象。
性能不是唯一维度：还要看维护成本
实测中，小对象（
- 出 bug 概率：
JSON方案上线后因丢失undefined导致条件判断失效，比慢 1ms 更致命 - 重构成本：某项目曾将
JSON替换为_.cloneDeep，仅改一行就修复了 3 个隐藏状态异常 - 团队一致性：如果状态管理模块统一用
_.cloneDeep，新成员不必再判断“这次能不能用structuredClone”
按需引入 lodash-es 的 cloneDeep（非全量），体积增加约 3–4KB gzip 后，换来的是稳定性和可预测性。
