内存泄漏可快速通过任务管理器、performance面板和performance.memory三步确认；重点排查未清理事件监听器、未清除定时器、dom引用残留及闭包持有大对象；用堆快照comparison视图定位源头并针对性修复。
直接看内存曲线和操作反馈，比等用户投诉快得多。页面越用越卡、滚动变涩、输入延迟、偶尔崩溃，这些不是“体验问题”，而是内存正在被悄悄吃掉的明确信号。
三步快速确认是否真有泄漏
不用打开 DevTools 堆快照，先做这三件事：
- 按 Shift + Esc 打开浏览器任务管理器，盯住目标标签页的“内存”数值：静置 10 秒不操作，内存应基本持平；反复打开关闭同一个弹窗 5 次，每次操作后内存若都比前一次高 20MB 以上，大概率已泄漏
- 在 Performance 面板 录制 15 秒操作（含滚动、点击、切换），勾选 Memory；停止后查看“JS Heap”曲线——如果出现阶梯式上升、且每次 GC 后回落幅度极小，就是泄漏在积累
- 执行同一操作前后各运行一次
performance.memory（Chrome 中支持），对比usedJSHeapSize：增长超过初始值 30%，且多次重复后持续放大，就是泄漏在积累
重点查这四类“内存钉子户”
80% 的泄漏来自固定模式，按优先级排查：
小红书长文-谷歌浏览器
下载
在 Linux 上通过 Chrome 挂载/VNC 自动发布小红书长笔记。Agent 撰写标题和正文后执行 xhs_publish.sh --publish --submit，触发小红书发布。
-
未清理的事件监听器：尤其
scroll、resize、input这类高频事件；执行getEventListeners(document)查全局监听，切换路由后再查，新增未清除的就是嫌疑对象 -
没清空的定时器：
setInterval或setTimeout回调里用了this、props、大型数组或 DOM 节点，却没在组件卸载时clearInterval(id) -
DOM 删除后 JS 还握着引用：比如
const node = document.getElementById('chart'); node.remove();，但node变量仍活着，整个 DOM 树片段就锁死在内存里 -
闭包偷偷留住大对象：函数返回了一个长期存活的回调，而这个回调又捕获了
new Array(1e6)或接口返回的原始数据，只要回调没被释放，数据就一直占着
用堆快照精准定位泄漏源
确认泄漏存在后，进 Memory 面板拍三张快照：
- 刷新页面 → 拍第一张（基线）
- 执行疑似泄漏操作（如连续打开/关闭 3 个详情页）→ 拍第二张
- 再执行一次同样操作 → 拍第三张
- 选中第二、三张快照，切到 Comparison 视图，重点关注
Closure、Detached HTMLDivElement、Array这几类数量是否只增不减 - 点开异常增长的条目，看右侧 Retaining Path：路径顶端那个带
@符号的对象，就是强引用源头，通常就是泄漏代码所在位置
让内存波动回归健康区间
修复不是追求“零增长”，而是让内存随操作起伏、并在空闲时回落：
- 所有
addEventListener必须配对removeEventListener；推荐用{ once: true }代替手动解绑 - 组件卸载时确保
clearTimeout/clearInterval，并把定时器 ID 设为null或undefined - 避免将 DOM 节点存入全局变量、Vuex/Pinia state 或普通 Map；改用
WeakMap缓存元数据 - 对大数组、缓存对象、第三方库实例，显式提供
destroy()或dispose()方法，并在生命周期钩子中调用
