JS内存泄漏思维导图聚焦三层逻辑：谁占着不放（闭包持有、全局累积、循环引用）；为什么收不回（标记清除机制局限、引用计数缺陷）；如何发现解决（堆快照对比、关键词筛选、事件/定时器清理、WeakMap应用）。
画 JS 内存泄漏的思维导图，关键不是罗列所有概念，而是抓住“谁占着内存不放、为什么收不回来、怎么发现和解决”这三层逻辑。结构清晰、重点突出，才能真正辅助理解和排查。
核心原因：三类典型泄漏源
这是导图主干的第一级，必须放在最前面——因为所有分析都从这里出发：
- 闭包持有外部引用未释放：内部函数持续引用外部大对象（如 DOM 节点、大型数组），而该函数又意外被全局变量或事件监听器长期持有
-
全局变量意外累积：本该是局部作用域的数据（如缓存、日志、定时器 ID）被挂到
window或全局对象上，随页面生命周期一直存在 - 循环引用 + 引用计数失效场景：尤其在旧版 IE 中，DOM 节点与 JS 对象互相引用，垃圾回收器无法识别可回收性；现代浏览器虽主要用标记清除，但复杂嵌套仍可能干扰回收时机
机制支撑：JS 垃圾回收如何工作
这一层解释“为什么有些东西收不走”，是理解泄漏的前提：
- 标记清除（主流机制）：从根对象（如全局对象、当前执行上下文中的变量）出发，递归标记所有可达对象；未被标记的即为垃圾，统一回收
- 引用计数（已淘汰但需知其缺陷）：每个值记录被引用次数，为 0 时立即回收；但无法处理 A↔B 循环引用，是历史漏洞来源
-
注意点：闭包、事件监听器、定时器、控制台日志（
console.log(obj)可能隐式保留引用）、WeakMap/WeakSet 的弱引用特性——这些都要标注在对应分支旁
排查手段：从现象到定位
导图要实用，就得包含可落地的诊断路径：
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 监控指标：Chrome DevTools → Memory 面板 → 拍摄堆快照（Heap Snapshot），对比操作前后，按“Constructor”或“Retained Size”排序，找异常增长的对象类型
-
常见泄漏模式关键词搜索：在快照中筛选
Closure、Detached DOM tree、EventListener、Timer，看哪些节点 Retained Size 大且未释放 -
代码自查清单：是否手动移除了事件监听器（
removeEventListener）？是否清理了定时器（clearTimeout/clearInterval）？是否避免将 DOM 节点直接赋给全局变量？是否用 WeakMap 存储私有数据？
预防策略：写代码时就卡住漏洞
导图结尾应落脚到工程实践，体现主动防御意识：
-
事件绑定配对清理：组件销毁时确保调用
removeEventListener，或使用支持自动解绑的方案（如 Vue 的@click.native、React 的 useEffect cleanup 函数） -
定时器统一管理：把所有
setTimeout/setIntervalID 存入数组，在退出时遍历清除；或封装成带自动清理能力的工具函数 -
避免意外全局：严格启用
"use strict"；不用隐式全局（如漏写let/const/var）；缓存类数据优先用模块级常量而非 window 属性 -
善用弱引用结构：需关联 DOM 但又不想阻止其回收时，用
WeakMap存储元数据；临时映射可用WeakSet
一张有效的内存泄漏导图，不需要覆盖全部 JS 知识，而要像一张故障排查地图：从症状（内存持续上涨）出发，沿着回收机制、泄漏模式、检测工具、修复动作这条主线，层层展开。画的时候用不同颜色区分“现象—原理—动作”，比堆砌术语更有价值。
