验证深浅拷贝关键看修改副本嵌套引用是否影响原对象:需断言original.b.c===2且copy.b !== original.b、copy.d !== original.d,并覆盖date、regexp、map、set、循环引用等边界场景。

验证浅拷贝与深拷贝是否真正实现内存隔离,关键不是看结构一不一样,而是看改副本会不会动原对象——尤其得动嵌套的引用类型。
用嵌套对象做核心测试用例
只改顶层属性(比如 copy.name = 'xxx')无法区分深浅拷贝,因为所有方式都不会影响原对象。真正能暴露问题的是修改嵌套结构:
- 构造含引用属性的对象:
const original = { a: 1, b: { c: 2 }, d: [3, 4] }; - 对副本执行:
copy.b.c = 88或copy.d.push(5) - 断言:
expect(original.b.c).toBe(2)(深拷贝才应通过) - 同时检查:
expect(copy.b).not.toBe(original.b)和expect(copy.d).not.toBe(original.d)
必须验证引用地址是否不同
仅用 toEqual 判断结构一致是远远不够的。内存隔离的本质是地址隔离:
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式,或要求按照代码注释规范处理 Java 文件时,使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则,并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括:补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
copy !== original是基础前提 - 对每个嵌套对象、数组、Date、RegExp 等,都要单独做
toBe断言 - 例如:
expect(copy.date).not.toBe(original.date),且copy.date instanceof Date - 若发现
copy.b === original.b,说明仍是浅拷贝或拷贝不彻底
覆盖特殊类型和边界场景
很多深拷贝实现会在这些地方悄悄失效,必须显式构造并验证:
-
Date:拷贝后仍是
Date实例,getTime()值相等,但地址不同 -
RegExp:保留
flags和lastIndex,且copy.test('abc') === original.test('abc') -
Map / Set:元素数量、内容一致,且
copy !== original -
循环引用:如
const obj = {}; obj.self = obj;,深拷贝后应不报错、不卡死,且copy.self === copy -
null / undefined / NaN / Infinity:类型和值都保持原样(注意
typeof NaN === 'number')
避免常见误测陷阱
有些写法看似在测,其实没打中要害:
- 不用
JSON.parse(JSON.stringify())的结果当“正确答案”来比对,它本身就不支持函数、undefined、Date 等 - 不只测“复制后结构相同”,更要测“改了副本,原对象是否纹丝不动”
- 不跳过不可枚举属性和 Symbol 键的测试(如果设计目标包含它们)
- 不忽略超大嵌套或深层递归场景下的性能与稳定性(如 1000 层对象)
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










