JS内存泄漏必然发生，关键在于何时暴露；需通过Chrome堆快照对比识别增长、定位五类常见源头（如未解绑事件）、并从声明周期管理等习惯预防。
JS 内存泄漏不是“会不会发生”的问题，而是“什么时候暴露”的问题。它不报错、不中断执行，只悄悄吃掉内存，直到页面卡死、标签崩溃或服务 OOM 重启。实战中，关键不在知道概念，而在能定位、会验证、可修复。下面从三个真实作战环节展开：怎么快速识别异常、怎么精准定位源头、怎么写代码防患未然。
一、先确认是不是泄漏：用 Chrome DevTools 抓住“增长证据”
别凭感觉判断内存是否泄漏。必须通过连续堆快照对比，看对象是否持续增长且不释放。
- 打开 DevTools → Memory 面板 → 选中 “Heap snapshot”
- 点击 “Take snapshot”，记录初始状态（Snapshot 1）
- 模拟用户典型操作（如打开列表页 → 进入详情 → 返回 → 切换 Tab），重复 3–5 轮
- 再拍两次快照（Snapshot 2 和 Snapshot 3），全部加载后切换查看
- 在筛选框输入 Constructor 名称（如 Array、Object、闭包函数名），按 “Retained Size” 降序排列，重点观察同一构造器实例数和保留大小是否逐次上升
若某类对象（比如 HTMLDivElement 或你自定义的 ChartRenderer）数量/大小稳定增长，且“Distance”值很小（说明离 GC Root 很近），基本就是泄漏点。
二、常见泄漏场景与对应修复动作
90% 的泄漏来自五类固定模式，每种都有明确的代码特征和解法：
-
未解绑的事件监听器：DOM 元素被移除，但
addEventListener没配{ once: true }，也没调removeEventListener。修复：组件销毁时统一清理，或改用on+off封装，或用现代框架的生命周期钩子自动解绑 -
全局变量意外挂载：漏写
let/const，导致赋值变成window.xxx = ...。修复：全项目启用'use strict'，配合 ESLint 规则no-implicit-globals -
定时器引用外部作用域：在闭包内使用
setInterval，且未保存 timer ID 或未清除。修复：始终用变量接收返回值，并在退出逻辑中调用clearInterval；高频轮询优先改用requestIdleCallback或 WebSocket 心跳 -
闭包持有大对象且长期存活：如创建大量图片缓存到全局 Map，却无淘汰策略。修复：改用
WeakMap（键是对象引用，不阻止回收），或加 LRU 控制容量，或用URL.createObjectURL()替代直接缓存 Blob -
EventEmitter 监听器堆积（Node.js 场景）：在请求处理中反复对全局
eventBus.on('msg', handler)，却不off。修复：绑定监听器前先removeListener，或改用一次性事件，或把监听器注册移到模块初始化阶段
三、从编码习惯开始预防：让泄漏没机会发生
与其等泄漏爆发再救火，不如让代码天然具备“内存免疫力”：
- 所有对象型变量，声明即明确生命周期：用
let/const代替var，缩小作用域；函数返回前手动置null或清空引用（如obj.cache = null） - 流式处理替代全量加载：读取大文件、渲染长列表、处理大数据集时，优先用
ReadableStream、虚拟滚动、分页计算，避免一次性构建百万级数组 - 避免在循环或高频回调中创建新函数：把事件处理器、定时器回调抽成具名函数，防止每次生成新闭包实例
- 用工具提前拦截风险：在 CI 中接入
eslint-plugin-memory检查隐式全局、未清除监听器；用heapdump在 Node 服务中定期导出快照做基线比对
