Playwright-dotnet 内存泄漏问题分析与解决方案

问题背景

在使用 Playwright-dotnet 进行网页自动化测试时，开发者遇到了一个典型的内存泄漏问题。当持续从直播平台的弹幕区域获取数据时，程序的内存使用量会不断增长，最终导致页面卡顿甚至超时异常。这个问题在真实的直播网站（如B站）上表现得尤为明显，而在本地测试页面中虽然也存在但增长速度较慢。

问题现象

开发者最初通过 ElementHandle 方式获取弹幕数据，观察到以下现象：

1. Firefox 和 Node.js 进程内存持续增长
2. 约7分钟后出现超时异常
3. 异常信息显示等待元素查询超时

技术分析

原始方案的问题

最初的实现使用了 ElementHandle 方式获取元素属性：

var chatItemsContainer = await playPage.QuerySelectorAsync("#chat-items");
var chatItems = await chatItemsContainer.QuerySelectorAllAsync(".chat-item");

这种方式存在两个关键问题：

1. 创建的 ElementHandle 对象未及时释放
2. 频繁的 DOM 查询操作导致内存累积

Playwright 官方建议

Playwright 官方文档明确指出：

1. 推荐使用 Locator 替代 ElementHandle
2. Locator 采用懒加载机制，只在需要时才执行查询
3. 自动管理内存，减少手动释放的负担

内存泄漏根源

经过深入分析，发现问题的本质在于：

1. 高频的 DOM 查询操作积累了大量临时对象
2. 直播网站的复杂DOM结构加剧了内存压力
3. 传统的元素获取方式未能有效释放资源

解决方案演进

方案一：手动释放资源

首先尝试按照官方建议添加资源释放代码：

await Task.WhenAll(chatItems.Select(item => item.DisposeAsync().AsTask()));
await chatItemsContainer.DisposeAsync();

在本地测试页面中效果良好，但在真实网站中仍有内存增长。

方案二：改用 Locator 模式

完全重构为 Locator 方式：

var chatItemsContainer = playPage.Locator("#chat-items");
var chatItems = await chatItemsContainer.Locator(".chat-item").AllAsync();

虽然改善了内存管理，但在复杂页面上仍会出现超时问题。

最终方案：EvaluateAsync 方案

采用 JavaScript 直接执行DOM查询的方案：

var danmakuJson = await playPage.EvaluateAsync(@"
    [...document.querySelectorAll('.chat-item')].map(x=>({
        'username': x.getAttribute('data-uname'), 
        'content': x.getAttribute('data-danmaku')
    }))");

这种方案的优势：

1. 单次JavaScript执行完成所有查询
2. 避免了多次跨进程通信
3. 返回简洁的JSON数据
4. 内存使用稳定可控

技术建议

1. 对于高频DOM操作场景，优先考虑EvaluateAsync方案
2. 复杂页面中Locator模式优于ElementHandle
3. 定期监控关键进程的内存使用情况
4. 针对不同浏览器(Chrome/Firefox)进行兼容性测试

结论

通过这个案例我们可以看到，Playwright-dotnet 虽然功能强大，但在高频DOM操作场景下需要特别注意内存管理。EvaluateAsync 方案通过减少中间环节和优化数据传递方式，有效解决了内存泄漏问题，为类似场景提供了可靠的技术方案。开发者应当根据实际场景选择最适合的DOM操作方式，并在开发过程中加入内存监控机制，确保应用的稳定性。