DOM节点泄漏表现为节点数只增不减，可通过$$('*').length初筛、Performance面板看Nodes曲线趋势、Memory面板对比堆快照找Detached DOM树定位，Fuite工具可自动化检测。
DOM节点泄漏不是“内存涨了就一定有”，而是“节点数只增不减”——$$('*').length 每次操作后都变大，基本可以确认存在泄漏。
用 $$('*').length 快速验证是否在漏节点
这是最轻量、最直接的初筛手段，适合日常巡检或开发中快速拍脑袋判断。
- 打开 Chrome DevTools（
Cmd+Option+I或Ctrl+Shift+I），切到 Console - 执行
$$('*').length记下初始值（比如1247） - 做一次典型操作：打开弹窗 → 关闭弹窗 / 切换 Tab / 加载列表页 → 返回原页
- 再执行
$$('*').length，若变成1382且反复操作后持续上涨，就是泄漏信号 - 注意别和
document.querySelectorAll('body *').length混用——前者是 DevTools 扩展 API，后者是标准 DOM 方法，结果应一致；不一致说明有 Shadow DOM 或 iframe 干扰
Performance 面板抓“Nodes 曲线”看趋势
它不告诉你哪行代码错了，但能明确告诉你“泄漏是不是真的在发生”，且能定位到具体操作环节。
- 打开 Performance 面板，勾选
Memory和Screenshots - 点击录制 ●，立即执行一组闭环操作（如：点按钮 → 渲染列表 → 点返回 → 等待 1s）
- 停止 ■ 后，在下方图表里找灰色柱状图
Nodes—— 它代表当前存活 DOM 节点数 - 重点看操作结束后的回落：如果每次操作后
Nodes峰值都比前一次高，且无法回落到基线，就是典型泄漏 - 不要只盯“内存 MB 数”，DOM 节点本身 native 内存开销小，
Nodes曲线比JS Heap更敏感
Memory 面板堆快照对比找“Detached DOM tree”
这是定位根源的必经步骤。泄漏节点往往已从 DOM 树移除，但被 JS 对象强引用着，表现为“分离却未回收”。
立即学习“前端免费学习笔记（深入）”；
- 在 Memory 面板选择
Heap snapshot，点Capture heap snapshot拍第一张（Snapshot #1） - 执行一次疑似泄漏的操作（比如打开又关闭一个富文本编辑器）
- 再拍一张快照（Snapshot #2），然后在左上角下拉菜单选
Comparison视图 - 在 Constructor 列筛选
HTMLDivElement、Text、Comment等，看 Delta 是否为正且数量异常（比如多出 200+HTMLDivElement） - 点击某行 constructor，右侧会显示保留路径（Retaining path）—— 最终指向你代码里的某个变量、闭包或事件监听器绑定对象
- 常见陷阱：全局缓存对象（
window.cacheMap）存了已移除的 DOM；setInterval回调里引用了组件实例；Vue/React 组件销毁时没解绑addEventListener
Fuite 工具自动化跑回归检测
适合集成进 CI 或定期巡检，尤其对 SPA 页面的路由跳转类泄漏很有效，但需注意它默认行为的边界。
- 安装：
npm install -g fuite，然后运行npx fuite https://your-app.com - 它默认模拟“点击内部链接 → 返回”循环 7 次，并统计每次前后
document.querySelectorAll('*').length差值 - 关键参数：
--iterations 13（提高检测灵敏度）、--setup ./loginSetup.mjs（登录态准备）、--scenario ./custom.mjs（自定义交互流） - 报告里重点关注
delta字段——总泄漏节点数；若为正且 >50，基本可判定存在泄漏 - 注意：Fuite 不分析 JS 引用链，只报现象；它也抓不到 Shadow DOM 或 iframe 内部泄漏，得配合手动快照
真正难的不是发现泄漏，而是确认“这个 Detached 节点到底被谁拿着”。堆快照里 Retaining path 往往嵌套 5–6 层，中间夹着框架内部代理、事件系统缓存、甚至第三方 SDK 的私有字段——这时候得结合 source map 和业务逻辑反推，而不是只盯着最后一行函数名。
