JS内存泄漏本质是“本该释放的对象仍可达”，四大高发场景为：未解绑的事件监听器、未清除的定时器、残留DOM引用、闭包意外延长外部变量生命周期；需通过Chrome Memory面板实测验证并养成主动清理习惯。
掌握 JS 内存泄漏，关键不是背概念，而是建立“引用是否可被回收”的直觉。核心就一条：只要某个对象还被活着的变量、闭包、事件监听器、定时器或 DOM 节点间接引用着，它就不会被垃圾回收器释放——哪怕你主观上认为“它已经没用了”。
盯住四大泄漏高发场景
不用全记，但必须能一眼识别这四类代码模式：
- 事件监听器没解绑：比如给 window 或 document 绑了 resize 监听，组件卸载后没调用 removeEventListener；或者元素从 DOM 中移除了，但它的监听函数仍通过闭包持有着对父作用域的引用。
- 定时器没清除：setInterval / setTimeout 的回调函数会形成闭包，若回调里引用了外部大对象（如整个组件实例），而 timer ID 没被 clear，这个对象就一直活在内存里。
- DOM 引用残留：缓存了某个 DOM 元素（如 const $el = document.getElementById('xxx')），又在后续逻辑中把它从页面移除了，但 $el 变量还在作用域里，且没置为 null —— 这个 DOM 节点及其子树就无法被回收。
- 闭包意外延长生命周期：比如一个内部函数长期存在（被挂到全局、存进数组、传给第三方库），它又捕获了外层函数的大对象（如一个包含大量数据的 config 对象），那么这个 config 就一直不释放。
用 Chrome DevTools 实战验证
光看代码容易误判，动手测才可靠：
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
- 打开 Memory 面板 → 点击 “Record heap allocation” 开始录制，执行一次可能泄漏的操作（如打开/关闭弹窗、切换路由）→ 停止录制，观察是否有大量对象持续增长且不回落。
- 使用 Heap Snapshot：操作前拍一张快照，操作后再拍一张，用“Comparison”模式对比，重点看新增的 Detached DOM tree、Closure、Array 或 Object 类型是否异常增多。
- 检查 Event Listeners 标签页：选中某个 DOM 节点，看右侧是否挂着本不该存在的监听器（尤其注意源码位置是否指向已销毁组件的文件）。
写代码时养成防御习惯
预防比修复成本低得多，日常编码中主动做这几件事：
- 所有 addEventListener 都配对 removeEventListener，React/Vue 中统一在卸载钩子里清理；
- 所有 setInterval / setTimeout 都保存 ID，并在不需要时显式 clear；
- 手动管理 DOM 引用时，移除节点后立刻将对应变量设为 null；
- 避免把大对象直接塞进闭包，必要时用 WeakMap 存储弱引用关系；
- 启用 ESLint 插件（如 eslint-plugin-react-perf）自动提示潜在泄漏风险点。
理解 GC 原理才能举一反三
不必深究 V8 源码，但要清楚两个基础逻辑：
- 标记-清除是主流机制：GC 从全局对象（window）、当前执行栈等“根”出发，能到达的对象标记为存活，其余全部回收；
- 引用链决定生死：哪怕只有一条微弱的引用路径（比如一个未清除的 timer → 回调函数 → 外部变量 → 整个数据对象），整条链上的对象都活下来。
