深拷贝工程实践关键在于按场景精准选型：JSON方案适用于纯数据，structuredClone为现代标准解法，兼容需求则用lodash.cloneDeep；须规避Object.assign等伪深拷贝，并通过统一入口、日志辅助和性能监控实现可维护性。
深拷贝在工程中不是“要不要用”的问题，而是“怎么用得稳、用得准、用得省心”的问题。它常出现在状态快照、表单草稿保存、配置隔离、API响应缓存等关键环节，一旦出错，轻则数据污染，重则引发难以复现的偶发性 bug。
明确场景再选方案
不同场景对深拷贝的要求差异很大，不能一招鲜吃遍天：
- 纯 JSON 数据（如 API 响应体、配置项）：优先用 JSON.parse(JSON.stringify())，简单、快、无依赖，但需提前校验不含函数、Date、undefined、Symbol、循环引用等
- 现代浏览器/新项目（Chrome 98+、Firefox 94+、Edge 98+）：直接上 structuredClone()，原生支持 Map、Set、Date、RegExp、ArrayBuffer、Error、Blob，还能安全处理循环引用
- 需要兼容 IE 或旧 Node.js（v17 以下）：选成熟第三方库，lodash.cloneDeep 最稳妥，覆盖类型全、边界处理完善、社区验证充分；fast-copy 更轻量且性能突出，适合高频拷贝场景
- 有定制需求（如忽略某些字段、保留不可枚举属性、控制递归深度）：手写递归 + WeakMap 防循环引用是基础，但建议封装为可配置函数，避免每个项目重复造轮子
警惕常见“伪深拷贝”陷阱
很多看似复制了对象的操作，实际仍是浅层引用：
- Object.assign({}, obj) 和 {...obj} 只拷贝第一层，嵌套对象仍共享引用
- Array.from(arr)、arr.slice()、[...arr] 对数组元素是浅拷贝，若元素是对象，修改其属性仍会影响原数组
- new Date(obj) 或 new RegExp(str) 不是拷贝，只是新建实例，和原对象无关，但也不等于“深拷贝原对象”
- 使用 structuredClone 时，若传入包含 function、undefined、Symbol 或自定义类实例的对象，会直接抛错，需提前过滤或降级处理
工程落地中的实用习惯
把深拷贝从“临时补丁”变成可维护的工程能力：
立即学习“Java免费学习笔记（深入）”；
- 统一入口：项目中只保留一个
deepClone工具函数，内部根据环境自动 fallback（如先试 structuredClone，失败再用 lodash，最后兜底 JSON 方法） - 日志辅助：在开发环境对深拷贝前后做
Object.is()或浅层结构比对，快速发现意外的引用残留 - 避免过度拷贝：不是所有地方都需要深拷贝。例如 React 中的 state 更新，用 immer 或不可变更新模式更高效；后端返回的数据若已知结构简单，可跳过深拷贝
- 性能敏感场景加标记：对大对象拷贝前加
console.time，上线后通过监控埋点统计耗时，必要时引入分片拷贝或懒拷贝策略
不推荐手写但值得理解的底层逻辑
虽然生产环境不建议裸写深拷贝，但掌握原理能帮你快速定位问题：
- 核心难点不在“递归”，而在“识别类型”和“打破循环”——用 WeakMap 缓存已处理对象是最常用解法
- Date、RegExp、Map、Set 等特殊对象不能用
new obj.constructor()统一构造，必须单独判断并调用对应构造器或静态方法（如new Date(obj.getTime())） - 函数、undefined、Symbol、BigInt 在 JSON 序列化中会被静默丢弃或转换，这是设计使然，不是 bug
- 循环引用不是异常，而是合法结构（如树节点的 parent 指针），深拷贝必须显式支持，否则整个数据不可用
