“改了副本，原对象也变了”是因浅拷贝未处理嵌套引用，仅复制第一层；访问多层属性（如copy.a.b.c）或修改对象/数组内部值会污染原数据，需用structuredClone等真深拷贝或防御性检查。
遇到“改了副本，原对象也变了”的情况，大概率是浅拷贝没处理好嵌套对象。问题不在代码写错，而在拷贝层级没覆盖到——第一层看着独立，第二层却还共用同一块内存。
看修改是否触及嵌套引用值
关键不是“改了哪个变量”，而是“改的是什么类型、在哪一层”。只要操作路径中出现对象或数组，就得警惕：
-
安全操作：直接赋值基本类型，比如
copy.name = 'Lucy'、copy.count = 10 -
危险操作：访问点号后还有点号或方括号，比如
copy.profile.avatar.url = 'new.jpg'、copy.items[0].done = true - 哪怕只写
copy.config.enabled = false，只要config是对象，就可能污染原数据
用 Object.is 快速验证引用关系
在怀疑的位置加一行检查，能立刻确认是不是浅拷贝导致的共享：
console.log(Object.is(copy.info, original.info)); // true → 共享引用，改它就会污染console.log(typeof copy.info); // 'object' 且不为 null，说明 info 是引用类型- 对数组也一样：
Object.is(copy.list, original.list)
检查拷贝方式是否真能覆盖嵌套层
常见“以为深了，其实还是浅”的写法：
-
{...obj}、Object.assign({}, obj)、[...arr]—— 全是浅拷贝，只管第一层 -
JSON.parse(JSON.stringify(obj))看似深，但会丢掉Date、undefined、function、Symbol，遇到循环引用直接报错 -
structuredClone(obj)是目前最靠谱的原生深拷贝，支持Map、Set、Blob、循环引用等，但注意浏览器兼容性（Chrome 98+、Firefox 94+）
在关键节点加防御性日志
编辑类组件、表单初始化、状态派发前，快速定位污染源头：
- 打印原始对象和副本的某个嵌套路径：
console.log('original.address', original.address); console.log('copy.address', copy.address); - 对比内存地址：
console.log(original.address === copy.address); // true 就是浅拷贝没生效 - 如果用的是框架（如 React），检查
useState初始化或useMemo依赖项里有没有无意传入未拷贝的对象
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
