回答

fuite可以。

调试web应用程序中的内存泄漏非常困难。这个工具是存在的，但它复杂、麻烦，并且常常不能回答一个简单的问题：为什么我的应用程序会泄漏内存？

正因为如此，我敢打赌大多数web开发人员都没有积极监控内存泄漏。当然，如果你没有测试某些东西，很容易让bug漏掉。

当我第一次开始调查内存泄漏时，我认为这是一件罕见的事情。JavaScript——一种带有自动垃圾收集器的语言——怎么会成为内存泄漏的一大源头？但我了解的越多，我就越怀疑内存泄漏在单页应用程序（SPA）中其实很常见——只是没有人在测试它！

由于大多数web开发人员不是为了好玩而摆弄Chrome内存工具，他们可能不会注意到漏洞，直到浏览器选项卡因内存不足错误而崩溃，或者页面速度变慢，或者有人打开任务管理器并注意到某个网站正在使用许多兆字节（甚至千兆字节！）记忆。但在这一点上，它已经变得足够糟糕，可能有多个泄漏在同一页面上。

我以前写过关于内存泄漏的文章，但我的建议基本上可以归结为：“使用Chrome开发工具，遵循这十几个繁琐的步骤，然后也许你可以找出页面泄漏的原因。”这不是一个很好的开发者体验，我相信很多读者只是在绝望中摇摇头，然后继续前进。如果工具能够自动发现内存泄漏，那就更好了。

这就是为什么我写了fuite（法语中“泄漏”的意思）。fuite是一个CLI工具，您可以指向任何URL，它将分析页面是否存在内存泄漏：

npx fuite 

就这样！默认情况下，它假定该站点是客户端呈现的SPA，并且它将在页面中爬行内部链接（例如/about或/contact）。然后，对于每个链接，它运行以下步骤：

Click the link
Press the browser back button
Repeat to see if memory grows
如果fuite发现任何泄漏，它将显示哪些情况可能导致泄漏：

Test : Go to /foo and back
Memory change: +10 MB
Leak detected: Yes

Leaking objects:

| Object | # added | Retained size increase |
| ----------------- | ------- | ---------------------- |
| HTMLIFrameElement | 1 | +10 MB |

Leaking event listeners:

| Event | # added | Nodes |
| ------------ | ------- | ------ |
| beforeunload | 2 | Window |

Leaking DOM nodes:

DOM size grew by 6 node(s)
为了做到这一点，fuite使用了我博客文章中概述的基本策略。它将启动Chrome，运行一些场景n次（默认情况下为7次），并查看是否有任何对象泄漏n次（7、14、21等）。

fuite还将分析任何数组、对象、映射、集合、事件侦听器和整个DOM，以查看是否有泄漏。例如，如果一个数组在7次迭代后恰好增长了7次，那么它很可能正在泄漏。

来源 https://www.xianyuew.com/kxjs/3813160.html