Appearance
前端内存泄漏：引用保留、闭包、监听器与缓存失控
主题边界
- JavaScript 有垃圾回收不代表没有泄漏；只要对象仍被可达引用链持有，GC 就无法释放它。
- 前端泄漏往往来自闭包、事件监听、定时器、缓存、DOM 引用和第三方实例没有正确回收。
机制与流程
- GC 主要根据可达性判断对象是否可回收，因此泄漏的核心是“不该继续存活的对象仍然可达”。
- 常见来源包括：组件卸载后仍持有监听器、定时器未清理、Map/数组持续追加、闭包捕获大对象、KeepAlive/缓存池无限增长。
- Chrome DevTools 的 Heap Snapshot、Retainers、Allocation Timeline 能帮助定位是谁还在引用对象。
关键差异
- 内存增长不一定都是泄漏，可能是缓存策略或页面状态确实需要常驻；关键在于增长是否符合预期且可回收。
- 短时峰值和长期持续增长是两类问题，排查方法也不同。
边界条件
- 仅仅调用
removeEventListener还不够，如果回调函数引用不稳定或被别处持有，仍可能残留。 - 跨 iframe、第三方库、媒体流和 WebSocket 等对象的回收边界经常比普通组件复杂。
工程落点
- 单页应用、长时间打开的后台页、可视化大屏和富交互编辑器最容易暴露内存问题。
- 内存治理需要和组件生命周期、清理策略、缓存策略一起设计，而不是等线上崩溃后再查。