JavaScript内存泄漏指本该回收的对象因意外保留引用而无法释放，导致内存持续增长、页面变卡甚至崩溃，常见于全局变量、未清理事件监听器、闭包持有大对象、定时器残留等场景。
JavaScript 中的内存泄漏，是指本该被回收的对象因意外保留了引用，导致垃圾回收器无法释放其占用的内存。它不会报错，但会让页面内存持续增长，最终变卡、响应迟钝，甚至崩溃。
常见泄漏类型及对应解法
意外的全局变量
在非严格模式下，函数内直接给未声明变量赋值（比如 data = new Array(100000)），会自动挂到 window 上，变成永久存活的全局引用。
✅ 解决方法：启用 'use strict'；所有变量用 let 或 const 显式声明；若必须用全局缓存，用完后主动设为 null。
未清理的事件监听器
给 DOM 元素绑定事件后，若元素被移除但监听器没解绑，该监听函数及其闭包里引用的数据都会滞留内存。
✅ 解决方法：使用具名函数便于移除；组件卸载或 DOM 销毁前调用 removeEventListener；优先用事件委托减少绑定数量。
闭包持有大对象或 DOM 引用
闭包让外部变量“活”得比预期久。例如返回一个函数，内部持续引用一个 5MB 的图片数据或已移除的按钮节点。
✅ 解决方法：避免在闭包中长期持有大对象；必要时用 WeakMap 存储关联数据（键是 DOM 节点，值是元信息，节点被回收后自动清理）；函数执行完毕后手动切断引用（如置 cache = null）。
立即学习“Java免费学习笔记（深入）”；
定时器与异步回调残留setInterval 或 setTimeout 的回调若引用了外部作用域变量，且定时器未清除，这些变量就一直无法释放——尤其在单页应用切换路由后仍运行。
✅ 解决方法：保存定时器 ID，在组件销毁、页面隐藏或条件满足时调用 clearInterval / clearTimeout；用 AbortController 管理 fetch 等异步操作的生命周期。
怎么确认发生了内存泄漏？
不用等崩溃，几个低成本判断方式：
• 打开 Chrome 任务管理器（Shift+Esc），观察目标标签页的 “JavaScript 内存” 列：空闲状态下数值是否缓慢爬升；
• 在 DevTools 的 Memory 面板中录制堆快照（Heap Snapshot），反复操作相同功能（如打开/关闭弹窗），对比多次快照中相同构造函数的实例数是否只增不减；
• 使用 Allocation instrumentation on timeline 功能，查看某段时间内分配但未释放的对象类型；
• 检查 Detached DOM tree —— 已从文档移除但仍被 JS 引用的 DOM 节点，是典型泄漏信号。
预防比修复更有效
养成几个小习惯就能避开大部分坑：
• 组件级资源统一管理：把定时器 ID、事件监听函数、API 取消控制器都存在实例属性里，destroy 或 unmount 时批量清理；
• 避免裸写 addEventListener，改用封装好的事件注册/注销逻辑；
• 大对象缓存加限制：比如最多存 20 条，超出时用 FIFO 清掉最老项；
• 用 WeakRef + FinalizationRegistry（现代环境）做弱引用兜底，适合临时映射场景。
