第三方统计 SDK 是内存泄漏高发区，因其长期驻留、自动监听、缓存数据且源码不可控；排查需聚焦其行为痕迹与引用残留，通过对比测试、禁用验证、全局对象检查、堆快照分析及销毁机制验证五步定位并解决。
第三方统计 SDK 是内存泄漏的高发区，它们通常在页面生命周期内长期驻留、自动监听页面事件、缓存数据、维持定时上报逻辑，且源码不可控——这使得泄漏不易察觉，但影响显著。排查时不能只看自己写的代码，要聚焦 SDK 的“行为痕迹”和“引用残留”。
先确认是否真由 SDK 引起
避免误判，优先做三件事：
- 在无 SDK 的干净环境（如新建空白页 + 简单埋点调用）下复现相同操作，对比内存增长曲线；
- 禁用 SDK 脚本（通过 DevTools 的 Network 面板右键 Block request URL，或注释 script 标签），再执行相同交互，观察内存是否不再阶梯式上涨；
- 打开浏览器任务管理器（Shift+Esc），单独查看目标页面的“JavaScript memory”列：若禁用 SDK 后该值明显回落或稳定，基本可锁定问题来源。
查 SDK 挂载的全局对象和监听器
多数统计 SDK 会向 window 注入命名空间（如 window._ga、window.sensorsDataAnalytic、window.TD-SDK），并绑定大量事件监听器：
- 在控制台执行 Object.keys(window).filter(k => /sdk|analytics|stat|track/i.test(k))，快速找出可疑全局变量；
- 对疑似 SDK 对象，用 getEventListeners(window) 或 getEventListeners(document) 查看其是否注册了未清理的 scroll、click、visibilitychange 等高频监听；
- 特别注意 SDK 是否监听了 beforeunload 或 pagehide 却未做资源清理——这类监听常伴随闭包持有 DOM 或大数组。
抓堆快照，定位 SDK 相关的保留路径
使用 Chrome DevTools Memory 面板拍 3 个堆快照：
立即学习“Java免费学习笔记（深入）”；
- 快照 1：刚加载完 SDK，尚未触发任何业务操作；
- 快照 2：完成一次完整埋点流程（如进页面 → 触发曝光 → 点击按钮 → 上报成功）；
- 快照 3：退出该模块（如路由跳转、弹窗关闭）后，等待 10 秒再拍。
切换到 Comparison 视图，筛选 “Objects allocated between Snapshot 2 and Snapshot 3”，重点关注：
- 构造函数名含 SDK 命名（如 SensorsData、GaTracker、TdTracker）的对象持续新增；
- 大量 (closure) 对象，Retaining Path 中出现 SDK 全局变量或其内部模块；
- HTMLDivElement / TextNode 等 DOM 类型对象被 SDK 的某个 handler 闭包强引用（典型 Detached DOM 泄漏）。
检查 SDK 的销毁机制是否被正确调用
不是所有 SDK 都提供 destroy 方法，但主流 SDK（如神策、GrowingIO、腾讯 GA、友盟 UTDID）一般支持手动卸载：
- 查阅 SDK 官方文档，确认是否存在类似 sdkInstance.destroy()、analytics.reset() 或 window._hmt && _hmt.push(['_setAutoPageview', false]) 的清理接口；
- 在组件卸载（React useEffect cleanup / Vue beforeUnmount）、单页路由离开时，显式调用；
- 注意：部分 SDK 的 destroy 只清状态不释放监听器，需配合 removeEventListener 手动解绑（比如它内部用 window.addEventListener 绑的 resize，就得你自己 remove）。
验证清理是否真正生效
调用 destroy 后不能只信文档，要实测：
- 再次运行 getEventListeners(window)，确认相关监听已消失；
- 检查对应全局变量是否被置为 null 或 delete（如 window._sensors = null）；
- 拍新堆快照，对比前序快照，确认 SDK 相关构造函数实例数归零或不再增长；
- 最后用 performance.memory 查看 heapUsed 是否回落——这是最直接的证据。
