Puppeteer中调用browser.pages()导致浏览器崩溃问题分析

问题现象

在使用Puppeteer进行自动化测试时，开发人员发现调用await utils.browser.pages()方法会导致浏览器进程崩溃。具体表现为：

1. 浏览器进程内存使用量持续增长
2. 服务器端日志中出现大量重复的WebSocket消息
3. 最终导致内存溢出(OOM)错误
4. 崩溃前会观察到WebSocket消息体呈指数级增长

技术背景

Puppeteer是一个通过DevTools协议控制Chromium/Chrome浏览器的Node库。当Puppeteer连接到浏览器时，会建立一个WebSocket连接用于通信。正常情况下，这个连接应该只传输必要的控制命令和响应数据。

问题根源

经过分析，这个问题源于Puppeteer客户端和服务器端之间的递归WebSocket消息传递。具体表现为：

1. Puppeteer客户端连接到浏览器
2. 调用browser.pages()方法
3. 浏览器通过WebSocket返回页面列表
4. 返回的消息又被当作新的WebSocket消息处理
5. 导致消息体不断嵌套和膨胀

解决方案

针对这个问题，Puppeteer核心团队建议使用以下解决方案：

1. 使用targetFilter过滤

在启动浏览器时添加targetFilter选项，避免Puppeteer处理自身的WebSocket连接：

const browser = await puppeteer.launch({
  targetFilter: target => !target.url().startsWith(document.location.href),
  // 其他配置...
});

2. 分离浏览器实例

确保自动化测试使用的浏览器实例与Puppeteer控制的浏览器实例分离，避免自引用问题。

3. 升级Puppeteer版本

使用最新版本的Puppeteer(24.4.0或更高)，以获得更稳定的WebSocket处理机制。

最佳实践建议

1. 避免在同一个浏览器实例中同时运行Puppeteer和被测试的页面
2. 对于复杂的自动化测试场景，考虑使用独立的浏览器进程
3. 监控WebSocket消息流量，及时发现异常增长
4. 合理设置内存限制和超时参数

总结

这个案例展示了在使用Puppeteer进行复杂自动化测试时可能遇到的自引用问题。通过理解Puppeteer与浏览器的通信机制，并采用适当的隔离措施，可以有效避免这类问题的发生。开发者在设计自动化测试架构时，应当特别注意通信通道的隔离和过滤。