JavaScript对象拷贝本身不直接导致内存泄漏，但错误的拷贝方式或拷贝后引用管理不当易引发泄漏；浅拷贝仅复制第一层属性，深拷贝需避开JSON陷阱并防循环引用，真正泄漏风险在于拷贝后未及时断开长期引用。
JavaScript对象拷贝本身不直接导致内存泄漏，但错误的拷贝方式或拷贝后的引用管理不当，极易埋下泄漏隐患。关键不在“要不要拷”，而在于“怎么拷”和“拷完怎么管”。
浅拷贝：看清边界，别误以为安全
Object.assign({}, obj) 和 {...obj} 都只复制第一层属性。如果 obj 里有 nested: { value: 1 }，那副本和原对象共享这个 nested 对象。改副本.nested.value，原对象也跟着变——这不是 bug，是设计如此。
- 适用场景：合并配置、覆盖单层默认值（如 {...defaults, ...overrides}）
- 不适用：含 Date、RegExp、Map、Set、函数、Symbol 或循环引用的对象
- 注意：Object.assign(null, src) 会报错；扩展运算符支持迭代器，Object.assign 不处理不可枚举属性
深拷贝：选对方法，避开 JSON 陷阱
JSON.parse(JSON.stringify(obj)) 看似简单，实则静默丢数据：undefined、function、Symbol、BigInt 全消失；Date 变字符串；RegExp、Map、Set 变空对象；遇到循环引用直接报错。
- 推荐方案：structuredClone(obj)（现代浏览器支持），能正确处理 Map/Set/Date/RegExp，但不支持 function 和循环引用
- 兼容性方案：lodash.cloneDeep 或手写带 WeakMap 缓存的递归函数（防循环引用）
- 性能提醒：高频渲染中避免在 render 周期调用深拷贝，尤其面对大数组或嵌套深的对象
拷贝不是万能解药：先问“真需要拷贝吗？”
很多所谓“必须深拷贝”的需求，本质是想规避副作用。与其无脑拷贝，不如从源头优化：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 用 Immer 实现不可变更新，代码更简洁，性能更好
- 状态归一化（如 Redux Toolkit 的 createEntityAdapter），减少冗余副本
- 大型对象优先传递 ID 或轻量标识符，而非整个数据结构
内存泄漏真正藏在哪？拷贝之后的引用没断开
深浅拷贝只是起点。泄漏往往发生在拷贝结果被意外长期持有：
- 组件卸载后，异步回调仍尝试更新已销毁组件的 state
- DOM 元素移除后，JS 仍通过变量或缓存（如 Map）强引用着它，形成 Detached DOM 树
- 闭包中保留了拷贝后的大型数据，而闭包又被全局变量、定时器或事件监听器持续引用
- 未清理的 setInterval/setTimeout 回调，内部闭包持有了拷贝对象
防护要点：谁创建，谁清理。React 用 useEffect 清理函数；原生 JS 记得 clearInterval、removeEventListener、手动置 null；缓存用 WeakMap 替代普通 Object。
