内存泄漏是指本该被释放的对象因被意外持有引用而无法被垃圾回收，导致内存持续增长；JS虽有自动GC，但全局变量滥用、未清理定时器、事件监听器残留、闭包持有DOM或大对象等场景仍易引发泄漏。
什么是内存泄漏，为什么 JS 也需要关心
JavaScript 有自动垃圾回收（GC），但不等于不会内存泄漏。所谓内存泄漏，是指本该被释放的对象持续被意外持有引用，导致 GC 无法回收，内存占用只增不减。长期运行的 Web 应用（如管理后台、实时看板、富编辑器）容易因此变卡、崩溃或触发浏览器内存限制。
四类高频泄漏场景与自查要点
不用等 OOM 才排查——日常开发中盯住以下模式即可快速定位：
-
全局变量滥用：显式挂到
window或globalThis，或隐式创建（如忘记var/let/const声明）。检查所有window.xxx = ...和未声明直接赋值的变量。 -
定时器未清理：
setInterval/setTimeout回调中闭包引用了外部大对象（如 DOM 节点、大型数据结构），且未在组件卸载/页面离开时clearInterval。重点查生命周期钩子（如 React 的useEffect cleanup、Vue 的beforeUnmount）是否遗漏清除。 -
事件监听器残留：用
addEventListener绑定后，没配对调用removeEventListener（尤其注意匿名函数无法移除）。建议统一用具名函数或AbortController（现代写法：el.addEventListener('click', handler, { signal })）。 -
闭包持有 DOM 或大对象：回调、配置项、缓存 Map/Set 中长期保存对已卸载节点或过期数据的引用。例如：在组件内定义一个
cache = new Map()，但 key 是 DOM 元素，元素已移除却未从 map 删除。
三步实操诊断法（无需复杂工具）
在 Chrome DevTools 中按顺序做：
-
快照比对：打开 Memory 面板 → 点击 Take heap snapshot（页面空闲时拍一张）→ 执行可疑操作（如打开关闭弹窗 5 次）→ 再拍一张 → 左侧选中第二个快照 → 右上角切换为 Comparison → 筛选 Retained Size 大幅增长的构造函数（如
Array、Object、Closure、自定义类）。 - 追踪引用链：在 Comparison 视图中点击某条高 Retained Size 行 → 右侧展开 Retainers 树 → 找到“不该存在却一直活着”的引用路径（例如：某个已销毁组件实例 → 通过闭包 → 持有 event handler → 持有 DOM 节点）。
- 重复验证：修复疑似点后，清空所有快照，重新走一遍操作流程 + 快照比对，确认对应对象数量/大小不再累积。
预防比修复更重要：几条硬性习惯
把泄漏挡在代码落地之前：
- 所有
addEventListener配套removeEventListener，优先用{ once: true }或AbortSignal； - 组件销毁时，显式清理：清除定时器、取消请求（
AbortController）、清空缓存 Map/Set、解绑事件； - 避免将 DOM 节点作为对象 key 或 Map key；改用
WeakMap关联元数据（它不阻止 GC）； - 大型数据暂存慎用全局或模块级变量；优先用局部作用域 + 明确生命周期管理；
- CI 中加入内存基线检测（如 Puppeteer + heap snapshot 自动比对），对关键流程做回归防护。
不复杂但容易忽略
内存泄漏不是玄学。抓住“谁持有、谁该释放、何时失效”三个问题，配合快照比对，90% 的泄漏当天就能定位。写完功能，顺手扫一眼定时器和事件绑定，比上线后抓耳挠腮强得多。
