首先明确常见内存泄漏场景：全局变量未声明导致挂载window、闭包引用未清理、事件监听未解绑、定时器依赖外部变量、DOM引用滞留。接着使用Chrome DevTools的Memory面板拍摄堆快照，对比操作前后的对象变化，重点关注Detached DOM trees和异常增长的构造函数。通过retaining tree分析引用链，确认谁持有对象引用。最后代码层面检查事件监听配对、定时器清除、避免闭包长期持有大数据，优先使用WeakMap/WeakSet存储关联数据，确保对象可被回收。
JavaScript内存泄漏虽然不易察觉，但会导致页面卡顿、响应变慢甚至崩溃。排查这类问题需要理解常见泄漏模式，并借助开发者工具定位根源。重点在于识别未释放的引用和意外持有的对象。
常见的内存泄漏场景
了解哪些写法容易导致泄漏，是预防和排查的第一步。
- 全局变量意外增长：未用var/let/const声明的变量会挂到window上，长期驻留
- 闭包引用未清理：内部函数持有外部变量，若外部函数执行后未释放，可能造成泄漏
- 事件监听未解绑：DOM元素被移除，但事件监听仍存在，尤其在频繁增删节点时
- 定时器依赖外部变量：setInterval或setTimeout回调引用了大对象，且未clear，对象无法回收
- DOM引用滞留：JavaScript保留了已从文档移除的DOM节点引用，如缓存了$el.data
使用Chrome DevTools分析
Chrome的Memory面板是排查内存问题的核心工具。
- 打开DevTools → Memory标签 → 选择“Heap snapshot”
- 在操作页面前后各拍一次快照，对比对象数量变化
- 关注“Detached DOM trees”，这是典型的泄漏信号
- 查看Constructor列表，筛选出异常增长的构造函数实例
- 点击具体对象，查看右侧retaining tree，找到是谁在引用它
代码层面的检查建议
结合工具和代码审查，能更快定位问题。
- 检查所有addEventListener是否配对removeE
ventListener - 确认setInterval有对应的clearInterval调用
- 避免在闭包中长期持有大型数据结构
- 模块返回前清理私有变量和事件
- 使用WeakMap/WeakSet存储关联数据，允许对象被回收
ventListener基本上就这些。发现内存持续上涨时，及时拍快照对比，重点关注DOM和事件相关引用链。问题通常出在“以为释放了，其实还被谁拿着”的地方。不复杂但容易忽略。
