我一直觉得对象克隆是编程里最典型的“看起来简单做起来全是坑”的话题。你在项目里写数据、传状态、存快照几乎每周都会碰到要复制一份对象的需求。但真正动手的时候很多人发现自己只是把引用复制了一下改了一个变量原对象跟着变页面乱了半天才查出来问题。所以今天这篇就把对象克隆这件事彻底聊透从浅拷贝到深拷贝从原理到工程落地把我踩过的坑和经验一起整理出来给正在处理数据复制的朋友做个参考。1. 不从语法聊起——先想清楚你为什么要克隆对象1.1 引用拷贝、浅拷贝、深拷贝三者到底差在哪在动手写任何克隆函数之前先把最基础的概念彻底搞清楚。JavaScript 里对象变量存的是内存地址不是数据本身。你把一个对象赋值给另一个变量计算机只是多了一个指向同一块内存的“门牌号”这个叫引用拷贝。改任何一个变量其实都是改同一份数据。浅拷贝shallow copy会生成一个新的对象壳子壳子里面的属性值如果还是对象复制过来的依旧是引用。也就是说顶层对象的修改是独立的但深层嵌套的对象仍然共享。深拷贝deep copy则把整棵对象树连根拔起所有层级都生成新数据新对象和原对象完全断开连接改谁都不影响谁。用一段代码快速验证一下const original { name: coder, address: { city: Shanghai } }; const shadow { ...original }; const deep JSON.parse(JSON.stringify(original)); shadow.address.city Beijing; console.log(original.address.city); // Beijing浅拷贝被污染了 deep.address.city Guangzhou; console.log(original.address.city); // Beijing深拷贝互不影响搞清楚这个区别你才能知道你需要的到底是银拷贝还是深拷贝。很多人在第一步就选错了方向后面再怎么优化都白搭。1.2 实际业务场景里哪些地方必须做深拷贝需求不同对克隆深度的要求完全不同。我这里列几个最常见的真实业务场景帮你对照判断组件状态回退undo/redo编辑器、表单设计器这类场景必须保存历史快照回退的时候要恢复的是完整的状态树。如果只做浅拷贝状态树里嵌套的同一份引用会在多步操作中相互影响历史记录直接废掉。防脏读污染defensive copy后端接口返回的数据结构通常嵌套很深直接把这个对象丢给多个业务模块去改互相污染在大型团队项目里几乎是必然的。正确做法是在模块边界做深拷贝保证数据只在其所属作用域内被修改。跨线程或跨上下文传递Web Worker 传数据、iframe 间通讯、多媒体库的数据预处理这些场景要求数据完全序列化深拷贝是基本要求。配置对象合并与覆盖比如设计系统的主题配置、组件库的全局配置需要一套默认值加一套用户自定义值合并出最终结果。合并之前不拷贝默认对象你的全局默认值被改一次就永久损坏了。这些场景的共性就是你操作的不是一个孤立的属性而是整棵对象树。我见过很多团队出事出在第二个场景上——接口数据直接存入全局状态组件的副作用函数悄悄改了它排查问题直接通宵。这么惨的教训最好吸取一下。2. 深浅拷贝方案选型——从手写遍历到内置 API 的完整对比2.1 常用浅拷贝实现扩展符、Object.assign 与遍历手动赋值的取舍浅拷贝看似简单其实也有适合的场景区分。**展开运算符spread**是我最常用的方式{ ...obj }语法简洁可读性好对大多数仅需顶层复制的场景完全够用。它的一个限制是只拷贝自有可枚举属性不过这个特性在日常场景里问题不大Symbol 属性虽然能拷进去但展开到数组里的表现又不一样容易产生混淆。Object.assign和展开运算符的效果几乎一样它是 ES5 时代的产物兼容性更好。二者最大的区别在于展开运算符在编译阶段就确定了要拷贝哪些属性Object.assign 则是在运行时逐个赋值。速度上差别微乎其微选舒服的写法就好。手动循环赋值是最传统的方式也是唯一能精确控制“哪些属性要、哪些不要”的方式。例如你只想拷贝白名单里的字段for...in加hasOwnProperty判断反而比展开运算符更精准高效。从工程效率的角度我建议能够用展开运算符解决的浅拷贝就不要写循环。真要写循环的通常是为了做字段过滤而不是为了克隆。2.2 JSON 序列化深拷贝——上手快但四个致命短板必须知道JSON.parse(JSON.stringify(obj))应该是大家第一个接触的深拷贝方案一行代码看起来完美。这种方式的原理是先把对象序列化成字符串再解析回来等于完全重新创建了一棵数据树。在数据只包含简单类型、普通数组和普通对象的前提下它确实快速可靠。但是用多了就发现这套方案有绕不开的硬伤问题场景表现结果函数属性会被直接丢弃拷贝后对象缺失方法undefined 与 Symbol会被直接忽略属性彻底丢失Date 对象被序列化成字符串拷贝后变成 string不再是 Date循环引用直接抛异常代码崩溃NaN 与 Infinity被转成 null数据被悄悄篡改RegExp、Map、Set会被转成空对象或普通对象内部数据丢失这些短板不是边角料的边缘情况而是真实业务里每个月都会撞到的雷。我的建议是只把 JSON 序列化用在“数据纯净”的场景比如后端 API 返回的数据做前端的本地缓存深拷贝或者存储一个纯数据结构快照。只要对象里有函数、类实例、Date、Map 这些东西就老老实实上专门的深拷贝实现。顺带处理一个我不做原文提到的坑——在公司项目里有的人会把JSON.parse(JSON.stringify(x))写成JSON.parse(JSON.stringify(x, replacer))来保留 Date 或函数这个方案在浏览器和 Node 里表现各异维护成本极高可读性也差根本不值得。2.3 structuredClone 不得不提——原生方案为什么值得依赖structuredClone是 2022 年前后浏览器和 Node 17 开始全面支持的原生深拷贝函数。它的价值在于这几乎是你只用一行代码就能获得的最完整的深拷贝支持而且它走的不是先序列化再反序列化的路子而是使用结构化克隆算法直接在内核层面完成对象树的复制。从行为上看structuredClone 能正确处理绝大多数常见类型Date、RegExp、Map、Set、ArrayBuffer、TypedArray 都能被正确识别并克隆。循环引用对它来说也不是问题它会维护一个内部映射表来处理同一引用的重复出现。这一点比 JSON 方案强太多了。它也不是没有限制函数和 DOM 节点不被支持按规范会抛 DataCloneError对象的原型链会被剥离——克隆出来的纯对象constructor指向不再保留原类。这几点在很多业务场景是可接受的因为你在深拷贝一个数据快照的时候通常并不需要函数和原型。但如果你需要拷贝一个类实例且要求克隆出来的数据仍然是该类的实例这个方案就满足不了了。我的判断是工程上优先用 structuredClone性能和正确性有保证少写自研代码就少出自研 bug。只有在需要函数复制、原型链保留或特定类实例克隆时才需要自研实现或引入工具库。2.4 手写深拷贝递归函数的基本版——理解原理的必由之路自己写一个递归深拷贝不是为了在生产环境替代库而是为了彻底理解前面所有方案为何正确或为何出错。原理一句话遍历对象的每个自有属性如果属性是对象或数组就递归调用自身是基本类型就直接赋值。function deepClone(source, map new WeakMap()) { if (typeof source ! object || source null) { return source; } // 处理循环引用 if (map.has(source)) { return map.get(source); } // 处理 Date、RegExp 等特殊对象 if (source instanceof Date) { return new Date(source.getTime()); } if (source instanceof RegExp) { const clone new RegExp(source.source, source.flags); clone.lastIndex source.lastIndex; return clone; } // 数组与普通对象分开处理 const target Array.isArray(source) ? [] : {}; map.set(source, target); // Symbol 属性也要考虑 for (const key of Reflect.ownKeys(source)) { if (Object.prototype.hasOwnProperty.call(source, key)) { target[key] deepClone(source[key], map); } } return target; }这段代码在执行过程中关键的细节是WeakMap充当“已访问表”它专门用来解决循环引用的问题。如果你写递归时不维护这张表遇到obj.self obj这种结构函数会无限递归直到栈溢出。WeakMap 在这里有个天然优势它不影响被拷贝对象的回收且查找速度是常数级。还有一个容易被忽略的细节是Reflect.ownKeys它能同时枚举字符串和 Symbol 类型的属性键普通的for...in会自动跳过 Symbol。3. 深拷贝里绕不开的循环引用和原型链问题3.1 为什么循环引用是自研深拷贝的第一大敌循环引用circular reference的意思就是某个对象直接或间接地引用了自身。最典型的就是“树形结构里的父节点指向子节点、子节点又记录 parent 回指父节点”在链表、树、图结构的数据模型中非常常见。如果你不能用 JSON 方案因为它遇到循环引用直接抛TypeError。自研递归时遇到循环引用如果不做“已访问”记录就会无限递归到 JavaScript 调用栈耗尽也就是所谓的栈溢出stack overflow。我在工作里第一次碰到循环引用是处理一个埋点上报数据某个对象里挂了个ctx引用全局状态全局状态又引用了当前页面实例结果 JSON.stringify 崩了我当时还以为是数据量太大排查了一晚上才恍然大悟。处理循环引用万变不离其宗的思路就是维护一张“源对象 → 克隆对象”的映射表。当一个对象已经被处理过第二次碰到就直接返回已有克隆体而不是重新递归。具体落实到代码里就是上面深拷贝示例里的 WeakMap 一段没有它这个函数就没有生产可用性。3.2 原型链到底要不要保留、怎么保留默认的深拷贝方案比如 JSON 方案和结构化克隆算法都会把对象的原型剥离产出一个纯普通对象。这在大多数场景下是合理的因为你要的是数据不是方法。但有一个场景例外——领域模型或类实例的深拷贝。比如你有一个类class User { constructor(name) { this.name name; } greet() { return hello this.name; } }你用 structuredClone 克隆出的对象copied 出来的实例不再有greet方法因为它的[[Prototype]]被指向了Object.prototype。如果你后续代码依赖这个实例的方法调用就直接报错。如果你需要保留原型链方案是先创建一个基于原对象原型的克隆体再递归复制属性function deepClonePreservingProto(source, map new WeakMap()) { if (typeof source ! object || source null) return source; if (map.has(source)) return map.get(source); const target Object.create(Object.getPrototypeOf(source)); map.set(source, target); for (const key of Reflect.ownKeys(source)) { if (Object.prototype.hasOwnProperty.call(source, key)) { target[key] source[key] typeof source[key] object ? deepClonePreservingProto(source[key], map) : source[key]; } } return target; }这种写法的代价是克隆过程中会触发原对象的 getter/setter 逻辑在某些边角情况下可能产生副作用比如 getter 里有随机数。所以不要盲目保原型只有你明确知道后续代码要调用类方法时才这么做。3.3 Map、Set、Date、RegExp、ArrayBuffer 的克隆细节一览谈到深拷贝的正确性很多人会忽略特殊内建类型结果克隆出来的数据悄悄变了形。这里把最常见的几种类型的克隆要点列一下Date必须用new Date(source.getTime())或new Date(source.valueOf())。直接遍历属性会把 Date 当成普通对象拷出来的东西连判定instanceof Date都为 false非常难排查。RegExp用new RegExp(source.source, source.flags)重建还要记得把lastIndex复制过来。Map 和 Set不能直接展开属性要调用它们内部的迭代逻辑重建。Map 的每个 key 和 value 都可能还是对象需要继续递归克隆。ArrayBuffer 和 TypedArray直接复制引用是最省事的做法但要真正深拷贝的话需要slice()底层字节。尤其涉及共享内存或并发场景时这个细节直接决定 bug 出现的频率。Promise、WeakMap、WeakSet、函数这些类型本质上不是一个数据快照强行复制没有意义。业界主流库比如 lodash对 WeakMap 的处理就是直接返回原引用函数干脆抛错。能避则避。实用性建议如果你生产的项目需要对这些类型做非常完整的支持别急着造轮子先去用成熟库的方案比较知名的有 lodash 的cloneDeep、GitHub 上的声明式工具库读它的源码来理解边界情况比自己从零开始写更稳。4. 实操过程——从选型到落地的一个完整工作流4.1 第一步判断你的克隆深度和对象复杂度动手写代码前先说清楚你是“要浅拷贝还是深拷贝”“数据里有函数、类实例还是纯数据”。我把判断口诀写在下面遇到选择困难症的时候直接按这个走对象只有一层、属性都是基本类型少量嵌套 → 浅拷贝用{ ...obj }对象嵌套层级少、数据纯净 →structuredClone省事且原生支持对象包含 Date、Map、Set、RegExp 且需要完整复制 →structuredClone对象包含循环引用 → 自研递归 WeakMap 或者直接用成熟工具库对象包含函数、Symbol、类实例且需要保留原型链 → 自研实现或工具库只要数据不包含特殊类型、对原型无要求 → 放心用 JSON 路线这一步其实消耗了最多的时间因为一半的需求者说不清楚自己的对象里都有什么。打开浏览器控制台先console.dir打印一遍把属性类型过一眼比坐在那里猜半天高效得多。4.2 第二步按工程标准选择方案而不是凭喜好如果项目是多人协作的我强烈建议在团队里定一个“克隆方案统一规范”消灭各自为政的局面。一个很现实的例子某同事习惯用 JSON 克隆某同事喜欢 lodash两套方案产出的数据在某些边缘情况下行为不同埋下的 bug 会让你在联调时欲哭无泪。我个人现在推荐的默认组合是浅拷贝一律展开运算符深拷贝优先 structuredCloneJSON 方案只允许用于纯数据容器的序列化存储特殊需求统一封装一个工具函数走同一套实现。4.3 第三步封装团队公共的 clone 工具函数并补好测试用例不要在所有业务文件里散布各种克隆函数。我在每一个长期维护的项目里都会新建一个clone.ts或clone.js集中管理所有克隆工具。里面除了导出克隆函数还导出几个类型守卫工具用于判断数据里有没有循环引用或 Datefunction isPlainObject(value) { if (typeof value ! object || value null) return false; const proto Object.getPrototypeOf(value); return proto Object.prototype || proto null; } function hasCircularReference(source, seen new WeakSet()) { if (typeof source ! object || source null) return false; if (seen.has(source)) return true; seen.add(source); for (const key of Object.keys(source)) { if (hasCircularReference(source[key], seen)) return true; } return false; }写完工具函数后直接针对以下测试用例跑一遍测试用例期望结果普通嵌套对象各层均为新对象互不影响含 Date 的对象克隆后仍是 Date 实例时间一致含 Map/Set 的对象内部内容完整且与原对象不等引用循环引用对象不崩溃克隆后循环关系保留Symbol 键对象Symbol 属性被完整拷贝类实例保留原型链若启用该模式稀疏数组稀疏位保留len 不变RegExp 的 lastIndex复制后与源一致4.4 第四步在性能敏感的路径上做针对优化深拷贝本质上是个开销不小的操作嵌套越深、数组越大消耗的内存和时间就越明显。实际项目中最容易掉进去的性能陷阱有三个重复克隆同一个对象在短时间内被不同模块各自克隆了一遍。优化思路是加一层缓存比如用 WeakMap 记录“近期已克隆对象”避免重复劳动。递归深度过大非常深的嵌套对象会让递归压栈必要时可以改写成迭代式广度优先遍历。无意义的深拷贝例如操作一个自己刚创建、未对外的对象就直接用引用没必要克隆。强制深拷贝反而白白损耗性能。在数据量达到百万级对象的时候上述优化能从十几毫秒减少到几毫秒级别肉眼可见。但在小数据量场景谈性能就是过度优化了。判断标准很简单先用performance.now()量一下如果克隆耗时低于渲染或网络耗时基本不用动。5. 常见问题与排查技巧实录克隆相关的坑一次给你说清5.1 为什么我用展开运算符复制数组改了元素还是影响了原数组这是新人最容易误判的一个问题。展开运算符和slice()、concat()一样都是浅拷贝。它们创建的是一层新的外壳但内部元素如果是对象复制的仍然是引用。所以const list [{ count: 1 }, { count: 2 }]; const copy [...list]; copy[0].count 99; console.log(list[0].count); // 99没防住如果你要数组元素也是全新的对象必须一层层深拷贝。最简单的做法就是copy list.map(item ({ ...item }))深层嵌套还得上深拷贝。5.2 structuredClone 报 DataCloneError说明数据里有它不认识的类型DataCloneError出现的时候通常是因为数据里含有函数、DOM 节点、Symbol 或某些特定 API 创建的对象。这个错误的好处是——它明确告诉你有内容不能被克隆。排查的时候推荐逐步二分法先克隆一半数据再克隆一半的一半找出引发报错的那个字段。这个方法虽然原始但在大型对象上非常有效。5.3 深拷贝后方法丢失调用时报 xxx is not a function这个问题的根源在于你的克隆方案不支持函数复制常见于 JSON 方案或 structuredClone。解决思路有两个一是接受现实把方法和数据分离克隆时只拷贝数据属性随后重新挂载方法二是使用保留原型链的自研方案让克隆体通过原型继承到方法。没有一套标准答案主要看你的业务对“方法归属”有没有强依赖。我个人的习惯是优先分离数据和逻辑因为数据序列化、缓存持久化时原型链本来也保不住。5.4 为什么 Map 和 Set 的深拷贝不能直接展开Map 和 Set 内部的数据存储方式与外层对象的属性枚举机制完全不同。对一个 Map 做{...map}得到的是一个空对象因为 Map 本身没有可枚举的自有属性。正确重建方法是借助迭代器function cloneMap(map, cloneFn) { const result new Map(); for (const [key, value] of map) { result.set(cloneFn(key), cloneFn(value)); } return result; } function cloneSet(set, cloneFn) { const result new Set(); for (const value of set) { result.add(cloneFn(value)); } return result; }一个更隐蔽的坑是 Map 的 key 如果是对象浅拷贝后新旧 Map 的同一 key 可能指向不同对象导致get查不到数据。处理方法是把 key 也递归克隆。会注意到这个问题的人一般都是在实际业务里吃过亏的。5.5 数组的稀疏位、Symbol 属性和不可枚举属性在克隆时丢失展开运算符、JSON、structuredClone在处理稀疏数组如const arr [1, , 3]时掉坑的表现各不同。JSON 方案会把空洞变成null凭空多一个属性展开运算符则会保留空洞。Symbol 属性的情况更微妙JSON 方案完全不拷展开运算符默认也不拷。不可枚举属性连Reflect.ownKeys不额外处理也不拷贝要保留的话需要配合Object.getOwnPropertyDescriptor和Object.defineProperty逐属性复制。如果你遇到数据丢失第一步就是还原原始对象的描述符信息const descriptor Object.getOwnPropertyDescriptor(source, key); Object.defineProperty(target, key, descriptor);这能同时保留 getter/setter、可枚举性和属性值。代价是性能相对更低按需使用。5.6 深拷贝的性能优化——大对象和小对象的策略要分开小对象几 KB 以内的克隆性能差异基本上可以忽略用代码可读性和稳定性挑方案就行。大对象几 MB 甚至更大就必须注意了JSON.parse(JSON.stringify(x))虽然看起来慢但底层是 C 实现往往比手写递归在速度上有优势反过来structuredClone 性能也相当不错它的实现能直接操作内存。若对象的规模达到几百 MB就要考虑流式克隆和分批处理了不能一把梭。在处理超大对象时还有一个实用技巧克隆前先冻结源对象。Object.freeze能阻止无意的后续修改这样克隆出的结果也更容易追踪问题。5.7 不要反复发明轮子——成熟方案的参考价值网上关于深拷贝的自研实现不下几百个各种“优雅解法”也很多但我还是要说一句真正到生产环境我还是倾向选择成熟方案或者在这些方案基础上做二次封装。原因是它们处理过的边界情况比个人经验多得多比如 Symbol 键、属性描述符、稀疏数组、原型链、递归引用这些全踩过坑产出的代码才可靠。这不代表个人不应该尝试手写恰恰相反手写能帮你弄清楚原理。我的建议是学习时手写生产中默认用成熟封装对性能或包体积有硬性要求的再把已经验证过的核心逻辑并入自己的工具库并且一定配上完整的测试用例。这样既不会被轮子限制也不会被自己的轮子坑死。6. 从一个实际需求到最终交付完整复现一次克隆选型与复盘拿一个“在线表单编辑器”的需求当例子最直观。这个需求里用户动态地添加、修改字段每个步骤都要保存历史快照来实现撤销重做功能。你手里有两种形态的核心数据一是字段配置数组纯数据包含字符串、数字、布尔、嵌套结构二是字段对应的组件实例含方法、内部状态、事件绑定。第一版方案直接用 JSON 序列化快照只保存字段配置数组因为组件实例根本没法序列化。结果用户每次撤销都需要根据快照重新构建整个组件实例构建过程耗时严重同时组件内部状态比如未提交的口头修改、瞬时滚动位置全部丢失体验非常差。第二版我对组件实例做了自研深拷贝保留原型链把内部状态也搬过去。这样做的好处是撤销时不用重新初始化组件体验丝滑很多。但随之而来的是内存压力剧增——每个快照都是一棵完整的组件树占的空间大到让人肉疼。最终我采取的分层策略是组件实例保存状态变量时记录 diff差异快照里只保存差异 触发动作的操作日志纯数据结构仍用 structuredClone且只保留需要在历史记录里回滚的字段。复盘这个项目最深刻的体会是克隆方案没有一劳永逸别想着一条方案走天下。先理解数据形态再判断深浅最后选实现优先采纳原生方案特殊需求自研封装测试用例跟上性能测量前置。这一套流程下来你在日常开发里遇到的绝大多数克隆需求都能稳稳落地而且不会再出现当初令我通宵排查的那种诡异 bug。