JS内存泄漏主因是保留了不该保留的引用，需通过Chrome Memory面板识别Detached DOM、闭包、事件监听器等模式；优先用WeakMap/WeakSet替代强缓存；组件/定时器/全局事件须显式清理；闭包只捕获必要参数。
JS 中内存泄漏往往不是因为写了“错”的代码，而是保留了不该保留的引用，让垃圾回收器无法释放对象。重构重点不在重写逻辑，而在主动切断隐式强引用、及时清理副作用、合理管理生命周期。
识别常见泄漏模式再动手
别急着删代码，先确认是不是真泄漏：用 Chrome DevTools 的 Memory 面板录制堆快照（Heap Snapshot），对比操作前后的对象数量变化；重点关注 Detached DOM trees、持续增长的闭包、未清除的事件监听器、全局变量缓存。
- 定时器未清除（
setInterval持有回调闭包，闭包又引用组件实例） - 事件监听器绑定在全局或长期存活节点上，但没配对调用
removeEventListener - 闭包中意外捕获大型数据（如整个 DOM 节点、大数组、未释放的 Canvas 纹理）
- 使用 Map/Set 缓存但没做失效清理，键是对象时导致其无法被回收
用弱引用替代强缓存
当必须缓存对象又不希望阻碍回收时，优先选 WeakMap 和 WeakSet——它们的键是弱引用，不影响目标对象的垃圾回收。
例如，给 DOM 元素附加私有数据：
const elementData = new WeakMap();<br>elementData.set(myButton, { clicked: true, timestamp: Date.now() });<br>// myButton 被移除后，对应 entry 自动消失，无需手动清理
避免用普通 Object 或 Map 以元素为 key 存储状态，否则即使元素从 DOM 移除，仍被 Map 强引用而驻留内存。
组件/模块级清理要显式声明
函数式组件（React）、自定义 Hook、类实例、插件模块等，都应提供明确的销毁接口或生命周期钩子。
- React 中，在
useEffect返回清理函数：return () => { controller.abort(); clearInterval(id); } - 类中统一实现
destroy()方法，集中解绑事件、清除定时器、置空引用（如this._cache = null） - 全局事件（如
window.addEventListener('resize', handler)）务必在退出时解绑，不要依赖页面卸载
避免闭包持有过大作用域
函数内部不需要的变量，别让它留在闭包里。尤其注意异步回调中的 this、self 或父作用域的大对象。
重构示例：
// ❌ 问题：handleClick 闭包捕获了整个 hugeList 和 this.state<br>function render() {<br> const hugeList = fetchBigData();<br> return <button onClick={() => handleClick(hugeList)}>Click</button>;<br>}<br><br>// ✅ 改法：只传必要参数，或提前提取 ID 类轻量标识<br>const listId = getCurrentListId();<br>return <button onClick={() => loadById(listId)}>Click</button>;
也可用箭头函数 + 参数绑定替代闭包捕获，或用 useCallback 配合依赖数组控制重建时机。
内存泄漏重构不是一次性的代码清洗，而是建立对引用生命周期的敏感意识。每次添加监听、启动定时器、缓存数据、创建闭包时，多问一句：它什么时候该结束？谁负责结束？答案明确了，泄漏就很难发生。
