你能多说一些关于你的用例吗？在释放后，网络请求不应该占用任何内存。会话确实会一直存在，所以如果你为每个请求创建一个新的会话，这可能会导致内存使用量增加。然而，对于大多数事情，都有重用会话的方法，因此你应该能够处理少量的会话。

是的，我正在使用Electron版本10.1.2。这个示例是通过同时发送600个请求来测试每个代理。
如您所见，内存从150MB增加到335MB,且从未释放。为了使内存降低，您必须重新启动Electron应用程序。这只是向主进程发出的一个IPC调用，以测试600个代理。
这是仅 600个网络请求和总共600个会话。

进程名称内存线程

你能重用会话吗？

我们将会话用作cookie容器，并在请求中使用代理。我们可能会重复使用会话，但在发出请求时会占用大量内存且不会释放。
我不知道600个会话和600个请求如何占用157MB的内存。在这个例子中，每个会话甚至没有任何cookie。

正如我之前提到的，网络请求不应该泄漏内存——如果你有一个测试用例显示在许多网络请求中存在内存泄漏，但固定数量的会话，这肯定是我们可以调查并修复的问题。
你可以使用例如ses.clearStorageData()来清除会话的cookie并重用它。代理设置也可以在请求之间更新。
我同意为每个请求创建一个新的会话是很方便的，但由于Chromium实现细节将BrowserContext与各种其他内部对象绑定在一起，因此以避免引入使用后释放或其他崩溃的方式实现会话删除功能是一项重大任务。此外，正如你已经发现的那样，会话相对较重。

好的，我刚刚通过创建600个会话进行了测试。内存现在是303MB。使用1个会话和每个代理1个请求进行606个代理的测试，增加了100MB。然后，大约15秒后，又增加了400MB,在释放之前持续了5-10秒，我们回到了大约400MB。

@1nfility,请问您能否使用Electron Fiddle编写一个简短的示例来展示这种行为？谢谢！

关于重用会话的一个注意事项是，在清除存储数据时，似乎无法清除session: true的cookies。我认为对于每个人来说，至少应该有一种方法来释放内存，以便应用程序不会随着时间的推移而积累内存。
我可以搭建一个简单的概念验证应用程序，展示如果需要的话，无法清除会话cookies的情况，但这似乎是必要的功能。如果我们被授予分配内存的能力，我们应该始终有能力释放那部分内存。
忽略。这是我在清除会话cookies时的一个小错误。然而，这个观点仍然成立：在我看来，“如果我们被授予分配内存的能力，我们应该始终有能力释放那部分内存”。

我原则上同意！在实践中，会话与Chromium中的许多不同对象密切相关，解开这个网络以便安全地进行垃圾回收是一项复杂的项目。我很乐意审查一个PR,但我个人优先考虑其他问题。