内存泄漏是指本该被垃圾回收器释放的内存因被活跃引用意外持有而长期滞留堆中。它由开发者逻辑疏忽导致，常见于未清理闭包、事件监听、定时器、DOM引用等场景，引发JS Heap阶梯式上涨、交互延迟加剧及标签页提前崩溃。
内存泄漏是指本该被垃圾回收器（GC）释放的内存，因仍被代码中的某个活跃引用意外持有，而长期滞留在堆中无法回收。它不是浏览器或引擎的故障，而是开发者逻辑疏忽导致的“内存钉子户”——对象明明已无用，却因闭包、事件监听、定时器、DOM 引用等未清理，持续占用资源。
直接拖垮标签页性能的三大致命表现
内存泄漏对浏览器标签页的影响不是渐进式变慢，而是结构性恶化：
- JS Heap 持续阶梯式上涨：在 Chrome Performance 面板勾选 Memory 录制操作，若每次 GC 后 JS Heap 回落幅度极小（如仅下降 1–2MB），且随重复操作不断抬高基线，说明泄漏正在累积；
- 页面交互响应延迟加剧：滚动卡顿、输入滞后、按钮点击反馈变慢，不是 CPU 占用高，而是 GC 频次被迫增加、单次耗时拉长，主线程频繁被阻塞；
- 标签页崩溃阈值提前触达：Chrome 对单个标签页的 JS 堆内存有软限制（通常约 1.4GB 老生代上限），泄漏持续积累会快速逼近该阈值，触发强制终止进程，表现为白屏、"Aw, Snap!" 或直接关闭标签页。
为什么 SPA 场景下泄漏更危险
传统多页应用中，用户刷新即重置内存；而单页应用（Vue/React）常驻运行数小时，路由切换、组件挂载/卸载、WebSocket 心跳、图表重绘等操作反复创建对象，若未同步清理，泄漏会像滚雪球一样放大。一个未清除的 setInterval 回调引用了 10MB 数据，每秒执行一次，10 分钟就额外锁死 6GB 内存引用链——即使数据本身未复制，GC 也无法标记其为“不可达”。
泄漏源头往往藏在“看似无害”的代码里
比如：
- 给
window绑定resize监听器，组件卸载后忘记removeEventListener； - 闭包中捕获了大型数组或接口原始响应体，返回的回调函数长期存活；
-
document.getElementById获取节点后调用.remove()，但变量仍持有对该 DOM 的引用； - 第三方库（如 ECharts、Map 实例）未调用
.dispose()或.destroy()方法释放内部资源。
这些代码运行时不会报错，控制台也无异常，但内存曲线早已悄然失控。
