用户说页面用久了就卡死，你抓了十张堆快照还是找不到泄漏——Chrome 151 把内存调试交给 agent 接管了

用户报「页面开了十分钟就卡死」，你打开 DevTools，点了 Profile、点了 Memory，抓了张堆快照——然后盯着那几十万个对象发呆。这是前端最劝退的一类 bug：不是报错，不是白屏，是内存一点一点涨上去，涨到你复现不出来、也说不清楚哪里漏了。

问题的根子不是你不会用 DevTools，而是内存泄漏这套活，从浏览器诞生起就是「人肉盯图谱」的活。Chrome 151 把这件事的方向改了：DevTools MCP 一口气塞进了 13 个专门的内存工具，把这套「抓快照—比差异—追保留链」的流程交给你身边的 AI agent 去跑。你不用再一帧一帧看图，你只要把复现步骤说清楚。

先说最实用的那一个：get_heapsnapshot_duplicate_strings。

字符串重复是最阴的一类泄漏。日志拼接、URL 缓存、i18n key、模板里每一行重新生成的字符串——单个都不大，量一大就把堆顶起来。以前你只能靠肉眼在快照里翻「String」那一列，现在是工具直接告诉你哪些字符串被重复分配了多少份、多占了多少内存。当快照 diff 里「字符串增长占了大头」的时候，直接跑它就完事了。

再说第二个值得记住的能力：V8 的原生上下文归因（context attribution）。Chrome 151 给堆快照加了一个「Retained by Context」过滤器，能把一个对象直接对回那条把它钉住的闭包上下文。你不再是看到一堆 (closure) 就懵——工具会告诉你这个对象是被哪个 execution context 拽住不放的。

配合内置的分类过滤器，四类最常见的内存泄漏可以一键定位：

• objectsRetainedByDetachedDomNodes：已经被移出文档、但还被变量拽着的 DOM 节点
• objectsRetainedByEventHandlers：监听器没摘掉，把整个组件吊在内存里
• objectsRetainedByContexts：被闭包或执行上下文困住的对象
• objectsRetainedByConsole：console.log 出来的对象一直不释放

这四条几乎覆盖了前端 90% 的「说不清哪里漏」。你不用再猜是 detached DOM 还是闭包，工具直接把类别报给你。

真正改变工作流的，是它的「加压复现」姿势。Skill 文档里给的流程是这样的：先把页面摆到目标状态，抓一份 baseline 快照；然后把同一组用户交互重复 10 次来放大泄漏信号；抓 target 快照；再把页面还原回初始状态，抓 final 快照。三份快照落盘，用 compare_heapsnapshots 比 baseline 和 target，先看总表 diff，再对可疑的类用 classIndex 下钻到对象级 diff。

翻译成人话：以前你靠手感「点几下看看内存涨没涨」，现在是「同一个操作跑 10 遍，用数据说话」。泄漏信号被放大 10 倍，误判基本没了。

还有两个实战细节值得抄进流程。

第一，别直接读 .heapsnapshot 原始文件。这类文件动辄几百 MB，直接塞给 AI 会瞬间烧光 token 预算，还读不出重点。正确姿势是走 MCP 的内存工具：get_heapsnapshot_summary 看总量、compare_heapsnapshots 看差异、get_heapsnapshot_retaining_paths 追保留链。让工具在后台 worker 里把聚合算完，你只看结论。

第二，调查完记得一个个调 close_heapsnapshot 释放掉。快照加载后会占着 MCP 服务器自己的内存，开着一堆不关，你自己的调试进程先炸了。这是很多人第一次用会踩的坑。

一个必须钉死的边界：detached DOM 节点不一定是泄漏。有些是有意为之的缓存。工具会把这些「疑似泄漏」标出来，但你下手前先问自己（或先问写这段代码的人）一句：这是不是故意的缓存。工具负责告诉你「什么还活着、被谁拽着」，判断「该不该活」仍然是你的事。

所以这件事真正的变化不是「AI 帮你抓快照」，而是流程本身变了：

1. 复现步骤写成明确的交互序列，交给 agent 跑；
2. 同一个操作跑 10 遍，三份快照自动落盘；
3. 用分类过滤器先锁定泄漏类型，再顺着保留链找到那一行应用代码；
4. 修完重跑一遍，用 baseline 和 final 的差值量化「到底修好了多少」。

下次再遇到「用户说用久了就卡」，别再打开 Memory 面板干瞪眼。让 agent 去跑那份 10 次交互的脚本，你负责看结论和改代码——这才是 2026 年排查前端内存泄漏该有的样子。