JS内存泄漏排查需建立“原理—场景—工具—习惯”四层闭环：先掌握标记-清除机制与内存生命周期，再识别五类高频场景（隐式全局变量、未清理定时器、DOM引用残留、事件监听器未解绑、闭包意外持有），接着用Chrome DevTools抓快照对比定位，最后通过声明规范、生命周期清理、WeakMap缓存和压力测试形成预防习惯。
JS 内存泄漏排查不是靠零散技巧堆出来的，而是需要建立“原理—场景—工具—习惯”四层认知闭环。入门快，但真正熟练得踩过几次线上卡顿、反复看内存快照、亲手修复几个顽固泄漏点才行。下面按学习路径分阶段说明。
理解 GC 机制与内存生命周期
不搞懂“为什么回收不了”，就永远在猜。重点掌握两件事：
- 标记-清除（Mark-and-Sweep）是现代浏览器（V8）的主流算法：从 window、document、调用栈等根对象出发，能被访问到的对象标记为“存活”，其余全部回收；
- 内存生命周期只有三步：分配 → 使用 → 释放。JS 的“自动”只管前两步，释放是否及时，取决于你写的代码是否让对象变成“不可达”。
特别注意：闭包本身不是泄漏，但闭包长期持有大对象（比如缓存了整个用户数据或 DOM 节点），而这个闭包又被全局变量、事件监听器或定时器意外保留，问题就来了。
盯住五类高频泄漏场景
90% 的真实泄漏都落在这些模式里，每个都要能一眼识别、手动复现、快速修复：
-
隐式全局变量：未用 let/const/var 声明的变量（如
a = {}）会挂到 window 上，永远可达；加'use strict'可直接拦截； -
未清理的定时器/动画：setInterval 回调里引用了组件实例或大数组，组件卸载后定时器还在跑；修复方式是统一提供
clearInterval或使用 AbortController； -
DOM 引用残留：用
let el = document.getElementById('x')拿到节点，之后 DOM 被移除，但 JS 还握着引用；优先用 WeakMap 缓存关联数据，或改用数据驱动 UI（如 Virtual List）； -
事件监听器未解绑：尤其绑定在 window/document 上的全局监听，或监听了 focus/blur 却没配对 remove；建议绑定到具体容器，并在销毁时显式调用
removeEventListener； - 闭包意外持有了不该持有的东西：比如一个函数返回闭包，内部却缓存了整个表格数据（而非仅 ID），且该闭包被长期保存在全局 Map 中；修复关键是“按需持有”，只留关键标识，数据走异步加载。
用 Chrome DevTools 实操定位
光看代码猜不出泄漏，必须动手抓证据。核心流程固定：
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 开隐身窗口，禁用插件，加载无混淆的开发版页面；
- 打开 Memory 面板 → 选 Heap snapshot → 点录制，做一次操作（如打开弹窗 → 关闭）→ 再拍一张快照；
- 对比两次快照，筛选 “Detached HTMLDivElement”、“(closure)”、“Array” 等关键词，看哪些对象数量/大小持续增长；
- 点开可疑对象，看它的 Retained Size（被它间接持有的总内存）和 References（谁还引用着它），顺藤摸瓜找到泄漏源头。
小技巧：用 console.memory 打印当前 JS 堆大小，配合定时器观察趋势；多次强制 GC（点击垃圾箱图标）后仍不降的，基本就是泄漏。
形成可落地的预防习惯
排查是救火，预防才是常态。日常写代码时养成几个动作：
- 所有模块级变量声明必带 let/const，ESLint 开启
no-implicit-globals； - 组件生命周期中，onMount 做注册，onUnmount 必须做清理（定时器、事件、Observer、IntersectionObserver）；
- 缓存 DOM 相关状态时，优先用 WeakMap（key 是 DOM 元素，值是任意数据），避免强引用拖住整个节点树；
- 复杂单页应用上线前，跑一次 5 分钟交互压力测试 + 内存快照比对，确认无明显增长趋势。
不复杂但容易忽略。
