浅拷贝不避免内存共享，而是通过共享引用实现；真正需防范的是意外修改原数据。对象合并时嵌套对象被共用，数组合并时元素为引用类型也会共享，应按需切断引用链。
浅拷贝本身不“避免”内存共享，它就是靠共享引用实现的——关键在于你是否意识到并主动管理这种共享。真正要防的是意外修改原数据，而不是拷贝方式本身。
对象合并时：警惕嵌套对象被共用
用 Object.assign() 或展开运算符合并对象，只复制第一层属性。如果某个属性是对象（比如 user.profile），那这个对象的引用会被直接复制过去，新旧对象指向同一块内存。
- 修改
merged.profile.name，会同时改掉obj1.profile.name - 常见陷阱：合并后把结果传给组件或 API，组件内部一改
profile，上游数据就“悄悄变了” - 对策：对已知含嵌套结构的字段，手动深克隆后再合并，例如：
const merged = { ...obj1, profile: structuredClone(obj2.profile), ...obj2 };
数组合并时：注意元素是引用类型
数组本身是引用类型，concat()、展开运算符或 [...arr1, ...arr2] 都只复制数组元素的值。如果元素是对象，它们的引用仍被共享。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
const a = [{ id: 1 }]; const b = [{ id: 2 }]; const c = [...a, ...b];
c[0] 和 a[0] 是同一个对象，改c[0].id就等于改a[0].id - 尤其在 React/Vue 中，若把合并后的数组作为 props 传入子组件，子组件内部 mutate 其中对象，父组件状态可能意外响应
- 对策：需要隔离时，合并后映射一遍，生成新对象：
const safeMerged = [...arr1, ...arr2].map(item => ({ ...item }));
（仅一层深；深层需递归或structuredClone）
统一防御策略：按需“切断引用链”
不追求全程深拷贝，而是在数据流向易变区域前做轻量级隔离：
立即学习“Java免费学习笔记（深入）”；
- 从服务端拿到数据后立即深克隆（如
structuredClone(res.data)），后续所有合并都基于副本操作 - 对外暴露数据前检查：如果函数返回值可能被外部修改，返回前做一次浅层解构（
{...obj}）或数组展开（[...arr]） - 使用
Object.freeze()冻结原始配置对象，让意外赋值在开发期报错，而非静默污染
浅拷贝不是漏洞，是设计选择。风险来自忽略引用本质。看清哪一层该“断”，比盲目上深拷贝更高效可靠。
