深拷贝大对象会直接引发内存暴增，核心原因是递归重建整棵树：每层嵌套的引用类型（Object、Array、Map等）均在堆中新建实例，原始结构多大，新结构几乎等量再生；基础类型值拷贝不占新堆空间，但引用类型全量复制导致内存瞬时翻倍，叠加老生代分配、序列化中间态及循环引用失控，峰值内存可达原始体积2.5倍以上。
深拷贝大对象会直接引发内存暴增，核心原因在于它不是“复制数据”，而是“重建整棵树”——每一层嵌套的引用类型（Object、Array、Map、Set、Date 等）都会在堆内存中开辟全新实例，原有结构有多大，新结构就几乎等量再生一次。
每层嵌套都触发新堆分配
JavaScript 中对象存在堆内存，变量只存指向堆的引用。深拷贝不复制引用，而是递归遍历：遇到基础类型（number、string）直接值拷贝，不占新堆空间；但只要碰到一个数组或对象，就会立即 new 一个同类型实例，并把它的每个属性再递归处理。一个含 10 万条记录、每条有 3 层嵌套的对象，深拷贝后将生成约相同数量的新数组、新对象、新 Map 实例——堆内存瞬时翻倍。
- 原始对象本身已占 2MB → 拷贝后新增至少 2MB 堆空间
- 若含 Date、RegExp、TypedArray 等，还会额外创建对应原生实例，进一步推高开销
- 嵌套越深，递归调用栈越长，中间临时对象越多，峰值内存可能达原始体积的 2.5 倍以上
大对象直入老生代，GC 成本飙升
V8 引擎对超过阈值（通常 16–32MB）的对象会跳过新生代，直接分配到老生代。深拷贝产生的大副本天然落入该区域——而老生代回收采用标记-清除算法，需遍历所有存活对象。一个 500MB 的拷贝副本，其释放延迟可达 300ms 以上，期间主线程被阻塞，页面卡顿明显。
- 频繁深拷贝 = 频繁向老生代注入大对象 → GC 触发更频繁、单次耗时更长
- 若旧副本未及时释放（如被闭包、全局变量、缓存意外持有），就会形成内存泄漏
- 内存碎片随之增多，V8 后续分配效率下降，进一步加剧压力
序列化类方案带来双倍中间态
像 JSON.parse(JSON.stringify(obj)) 这类依赖字符串中转的方案，实际执行两步：先将整个结构序列化为字符串（临时占用一份完整堆内存），再解析重建（再占一份）。对 10MB 数据，中间字符串就吃掉 10MB，加上重建对象的 10MB，峰值内存瞬间冲到 20MB+，远超原始体积。
- 字符串本身是不可变大对象，也直入老生代
- 序列化过程遍历全量属性，即使字段不用，也照单全收
- 无法跳过函数、undefined、Symbol、循环引用等，常导致静默失败或崩溃
循环引用未防护 → 无限递归与内存失控
真实业务对象（如树形组件、带 parent/children 的数据节点、Vue 实例）普遍存在循环引用。普通递归深拷贝若未用 WeakMap 缓存已处理对象，就会陷入死循环：A→B→C→A→B…，持续分配新对象，直到栈溢出或内存耗尽。此时内存增长不是线性翻倍，而是指数级失控。
- 浏览器可能直接触发“Out of Memory”崩溃
- DevTools Heap Snapshot 中可见大量重复构造的 Object / Array 实例
- 即便使用 lodash.cloneDeep 等成熟库，若未开启循环检测（默认开启），仍可能因配置疏漏引发问题
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
