深拷贝会为原对象每一层嵌套的引用类型在堆内存中分配独立空间，彻底切断引用关系；基础类型值拷贝不占新堆空间，而object、array等引用类型均新建实例，嵌套越深、结构越复杂，内存开销越大。
深拷贝操作会为原对象的每一层嵌套结构在堆内存中重新开辟独立空间，从而切断与原始对象的引用关系。这带来内存开销上升，但也换来数据隔离的安全性。
深拷贝如何触发新内存分配
JavaScript 中对象实际存储在堆内存，变量在栈中仅保存指向堆的引用。深拷贝不是复制引用，而是递归遍历原对象，对每个属性值——无论基础类型还是引用类型——都创建全新副本，并将这些副本存入新的堆内存区域。
- 基础类型（如 number、string）直接值拷贝，不额外占堆空间
- 引用类型（如 Object、Array、Date、Map、Set）都会在堆中新建实例
- 嵌套越深、结构越复杂，新分配的堆内存块越多、总量越大
- 循环引用若未处理，会导致无限递归分配，最终栈溢出或内存耗尽
常见深拷贝方法的内存行为差异
不同实现方式对内存的利用效率和占用模式有明显区别：
- JSON.parse(JSON.stringify(obj))：先序列化成字符串（临时占用堆），再反序列化重建对象。无法处理函数、Symbol、undefined、循环引用，且 Date、RegExp 等会被转为字符串或丢失
- 递归手写拷贝：可控性强，但易漏特殊类型；若未用 WeakMap 缓存已处理对象，遇到循环引用会崩溃
- lodash.cloneDeep：支持多数内置类型和循环引用，但体积较大，运行时需维护内部缓存 Map，有一定内存常驻开销
- fast-copy：采用 WeakMap 缓存 + 类型分发策略，避免重复分配；对 Array、Map、Set 等使用专用构造器，减少中间对象生成，内存更紧凑
降低深拷贝内存压力的实用建议
不必每次复制都走“全量深拷贝”，应结合场景做取舍：
- 优先判断是否真需要深拷贝——简单状态更新可用不可变更新（如 immer）、结构共享（如 immutable.js）或局部浅拷贝
- 对大数组或大数据对象，考虑分页拷贝、懒拷贝（按需展开）或只拷贝用到的字段（pick 模式）
- 使用 fast-copy 或 clone-deep 等现代库时，启用 strict 模式可跳过不可枚举属性，减少冗余内存占用
- 避免在高频渲染逻辑（如 React render、Vue watch）中无节制调用深拷贝；可缓存结果或改用引用比较 + 局部更新
识别深拷贝引发的内存问题
可通过浏览器 DevTools 的 Memory 面板观察：
- 执行深拷贝前后对比堆快照（Heap Snapshot），查看新增的 Object / Array 实例数量及大小
- 频繁触发垃圾回收（GC）且存活对象持续增长，可能是深拷贝后旧对象未被及时释放（如闭包持有引用）
- 长时间运行后内存占用线性上升，需检查是否存在深拷贝结果被意外缓存而未清理
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
