JavaScript深浅拷贝实现全解析

JavaScript中的深拷贝与浅拷贝看似基础，实则暗藏陷阱：浅拷贝仅隔离顶层属性，嵌套修改仍会污染原数据；而深拷贝虽追求彻底独立，却面临类型支持、循环引用、环境兼容等多重挑战——从JSON序列化的静默丢弃，到structuredClone()的现代推荐但能力受限，再到手写递归中WeakMap缓存循环引用的精妙设计，每种方案都在性能、安全与工程现实间艰难权衡；真正关键的不是“如何拷”，而是“为何要拷”——当你的配置对象带着函数或Symbol键时，或许该反思的不是拷贝实现，而是数据结构本身的设计哲学。

浅拷贝只复制第一层引用，修改嵌套对象仍会影响原数据

JavaScript 中的浅拷贝（shallow copy）仅复制对象或数组的顶层属性，对嵌套的引用类型（如对象、数组）只是复制了指针，新旧对象共享同一块内存。常见错误是以为 Object.assign() 或展开运算符 [...arr] 能完全隔离数据，结果在修改深层属性时意外改动了原始数据。

适用场景：只需隔离顶层字段，且确定内部结构不会被后续修改；或作为性能敏感场景下的临时方案。

• Object.assign({}, obj) 对对象有效，但不处理 null、undefined 或原型链
• [...arr] 或 Array.from(arr) 适合一维数组，对含对象的数组无效
• structuredClone() 是现代浏览器推荐方式，但目前不支持函数、undefined、Symbol 和循环引用

深拷贝必须递归或序列化处理嵌套结构

真正意义上的深拷贝需确保所有层级的引用类型都生成独立副本。没有银弹方案，选择取决于环境限制和数据特征。

最稳妥的手写递归实现要处理：null、日期、正则、数组、普通对象、Map/Set 等类型，还要避免循环引用导致栈溢出。但多数项目中，更倾向用成熟方案降低维护成本。

• JSON 序列化（JSON.parse(JSON.stringify(obj))）最常用，但会丢弃 function、undefined、Symbol、Date、RegExp、NaN，且无法处理循环引用
• structuredClone() 是浏览器原生 API，支持 Date、Map、Set、ArrayBuffer 等，但 Node.js 17+ 才支持，且仍不支持函数
• Lodash 的 _.cloneDeep() 兼容性最好，能处理函数（作为空对象）、循环引用、稀疏数组等边界情况，但引入依赖需权衡

遇到循环引用时，JSON 和 structuredClone 都会报错

当对象存在自引用（比如 a.b = a）或相互引用（a.b = b; b.a = a），JSON.stringify() 抛出 TypeError: Converting circular structure to JSON，structuredClone() 则抛出 DATA_CLONE_ERR。

此时必须用带缓存的递归方案：用 WeakMap 记录已拷贝的对象，遇到重复引用直接返回已有副本。

function deepClone(obj, map = new WeakMap()) {
  if (obj === null || typeof obj !== 'object') return obj;
  if (map.has(obj)) return map.get(obj);
  
  const cloned = Array.isArray(obj) ? [] : {};
  map.set(obj, cloned);
  
  for (const key in obj) {
    if (Object.prototype.hasOwnProperty.call(obj, key)) {
      cloned[key] = deepClone(obj[key], map);
    }
  }
  return cloned;
}

Node.js 环境下注意 structuredClone 的可用性与替代方案

Node.js 17.0+ 默认启用 structuredClone()，但低于该版本需降级处理。不能简单 fallback 到 JSON 方法——它会静默丢失数据，而应明确判断不可序列化字段并报错，或引入 node:util 的 inspect() + 自定义解析逻辑。

如果项目已使用 fast-copy 或 klona 这类轻量库，要注意它们对 Map/Set 的支持程度，以及是否默认处理 prototype 属性。

• klona 极快且无依赖，但不处理 Map、Set、Date
• fast-copy 支持更多类型，但比 structuredClone() 慢约 2–3 倍
• 自己实现时，别忘了检查 obj.constructor === Object，否则 new obj.constructor() 可能误调用自定义类构造器

实际项目里，90% 的深拷贝需求用 structuredClone() 就够了；剩下那 10%，往往是因为你正在操作一个带方法或 Symbol 键的配置对象——这时候就得承认：拷贝不是目的，设计才是。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~