前端内存泄漏排查需按链路顺序排除：先确认真实泄漏（任务管理器观察、重复操作对比、Performance看GC），再用Heap Snapshot比对操作前后差异锁定残留对象及引用者，接着检查定时器、第三方库、全局缓存、DOM引用、连接等高频泄漏点，最后通过多轮快照验证修复效果。
前端内存持续增长不是“找一个bug”，而是按链路顺序排除每个可能卡住内存的环节。关键不在于工具多，而在于每一步都验证“这个环节是否真的在留对象”。
第一步：确认是不是真泄漏，而不是假增长
很多所谓“内存涨了”其实是浏览器正常行为。先做三件事：
- 打开 Chrome 任务管理器（Shift+Esc），选中你的页面标签，观察“内存”列：静置 30 秒后是否还在爬升？如果每 10 秒涨超 20MB 且不回落，才值得深挖；
- 反复执行同一操作（比如打开/关闭弹窗）5 次，每次操作完等 5 秒，看内存是否逐次抬高——如果是，说明有对象没被释放；
- 打开 Performance 面板录制 20 秒，关注 GC 事件：如果频繁触发 GC 但堆内存没明显下降，说明存在无法回收的引用。
第二步：用 Heap Snapshot 锁定“谁没走”
别一上来就看所有对象。聚焦在“操作前后差异”：
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
- 在 Memory 面板中，点「Heap snapshot」→ 执行一次操作前拍第一张快照（Snapshot 1）；
- 执行操作（如进组件、拉数据、渲染图表）→ 等 3 秒 → 拍第二张（Snapshot 2）；
- 再执行相同操作 → 拍第三张（Snapshot 3）；
- 对比 Snapshot 2 和 Snapshot 1 的 “Objects allocated between” 视图，筛选出新增量大、且在 Snapshot 3 中仍存活的对象类型（如 CanvasRenderingContext2D、EChartsInstance、大型数组）；
- 点开可疑对象，看右侧 “Retainers” 树：谁在强引用它？常见的是闭包、全局 Map、未解绑的事件监听器、或父级组件实例。
第三步：检查高频泄漏点模块
按风险等级逐个过，优先查这些地方：
立即学习“前端免费学习笔记（深入）”；
- 定时器与 Observer：setInterval、setTimeout、IntersectionObserver、ResizeObserver —— 组件卸载时是否调用了 clearInterval / disconnect？Vue/React 中必须写在 cleanup 函数里；
- 第三方库实例：ECharts、Mapbox、Video.js、Canvas 图形库 —— 是否调用了 dispose() / destroy() / remove()？没调就等于把整个 DOM 树和事件系统钉在内存里；
- 全局缓存结构：用 Map/Set 缓存请求结果或计算值时，是否设了最大容量或过期策略？没清理的 Map 就是内存黑洞；
- DOM 引用残留：手动获取过 document.getElementById 或 ref.current 吗？删除节点后有没有把变量设为 null？尤其注意“已从 DOM 移除但 JS 还拿着”的 detached node；
- WebSocket/SSE 连接：连接建立后，组件销毁时是否调用了 close()？是否监听了 onmessage 却没移除监听？
第四步：验证修复是否生效
改完代码不能只看一次快照。要回归到最初复现路径：
- 清空缓存，硬刷新页面；
- 重复操作 5 轮（如路由跳转 A→B→A→B）；
- 每轮结束后等 5 秒，再拍一张 Heap Snapshot；
- 对比五张快照中目标对象的数量曲线：应呈“锯齿状波动”，而非单调上升；
- 最终 Snapshot 的堆大小应接近初始值，浮动不超过 10%。
