核心是建立“引用生命周期意识”，即明确对象创建、被谁持有、何时该断开及未断开原因；本质是理解V8基于“可达性”的GC机制，通过逆向追踪保留路径定位泄漏源头，并聚焦闭包异步、定时器错配、DOM引用、模块静态引用四类高危模式，结合DevTools工具闭环验证与防御性编码实践。
学 JS 内存泄漏的高级编程模式，核心不是背清单，而是建立“引用生命周期意识”——清楚每个对象从创建、被谁持有、何时该断开、为什么没断开。它本质上是训练你对 JavaScript 引擎（尤其是 V8）如何标记可达对象的直觉。
掌握底层机制：搞懂 GC 的“可达性”定义
内存泄漏的本质是：对象本该不可达，却被意外强引用着。所以必须理解 V8 的“根对象”有哪些：
- window / globalThis（浏览器）、Node.js 的 global —— 全局变量永远可达
- 当前执行栈中的局部变量（包括函数参数、let/const 声明的变量）
- 活跃的定时器回调、事件监听器、Promise 状态链、await 暂停点 —— 它们构成的闭包环境会冻结外层变量
- DOM 树中仍挂载或被 JS 显式引用的节点（哪怕已 remove()，只要 JS 还拿着引用，就不可回收）
真正高级的判断，是从任意一个疑似泄漏对象出发，逆向追踪它的“保留路径”（retaining path）：它被哪个闭包持有着？那个闭包又被哪个定时器/监听器/模块导出函数挂着？最终是否连回了 window 或长期存活的对象？
聚焦四类高危模式，逐个击破
不必泛泛而学，直接深挖最易在复杂工程中埋雷的四类场景：
- 闭包 + 异步 + 长期注册：比如事件处理器、消息订阅、状态管理中的 selector 回调。重点检查闭包是否捕获了大对象（如 config、state 快照、DOM 节点），且该闭包被全局 Map/数组/实例属性长期持有
- 定时器与组件生命周期错配：React/Vue 组件卸载后，setInterval 仍在运行；或者使用 useRef 存储 timerId 却未在 useEffect cleanup 中清除
- DOM 引用与事件委托失衡：手动缓存 DOM 节点（如 const modal = document.getElementById(...)）并用于后续逻辑，但组件销毁时未清空该引用；或在父级监听事件却未清理子组件绑定的 handler
- 模块级静态引用陷阱：ESM 模块顶层声明的 Map、Set、数组，被不断 push 对象却不清理；或导出一个“缓存服务”，内部用 WeakMap 存储但误用了强引用键
用工具驱动学习，而不是凭感觉猜
高级能力体现在能快速定位，而非靠经验盲试。必须熟练使用 Chrome DevTools 的三件套：
- Memory 面板 → 堆快照（Heap Snapshot）：对比操作前后的快照，筛选“Constructor”为 Array、Object、Detached HTMLDivElement 的对象，点击看 “Retainers” 列表，直接看到是谁在强引用它
- Performance 面板 → 录制内存曲线：勾选 Memory，执行一系列操作（如打开关闭模态框 5 次），观察 JS Heap 是否阶梯式上升，确认泄漏存在
- console.memory：在控制台实时查看 heapUsed、heapSizeLimit，辅助判断增长趋势
每次发现泄漏，都坚持走完“录制 → 快照 → 找 Retainer → 改代码 → 验证”闭环。几次下来，你对闭包捕获、事件绑定、定时器清理的敏感度会质变。
在真实约束下写防御性代码
高级模式最终要落地成编码习惯。例如：
- 所有 setTimeout/setInterval 都配对使用 clearTimeout/clearInterval，且确保在组件 unmount、页面离开、Promise resolve/reject 后必执行
- addEventListener 一律配合 removeEventListener，或改用 { once: true }、事件委托、WeakRef + deref 检查
- 闭包返回函数前，主动切断不需要的大引用：return () => { /* 只访问必要字段 */ console.log(data.id); }，而非直接 return () => console.log(data)
- 模块缓存加清理策略：Map.set(key, value) 后，考虑在 value 不再需要时 Map.delete(key)，或用 WeakMap（仅适用于对象键）
不复杂但容易忽略
