Puppeteer-Sharp 中 Chrome 进程泄漏问题分析与解决方案

问题现象

在使用 Puppeteer-Sharp (12.0.0) 与 ASP.NET Core 3.1 集成的场景中，开发者发现每次生成 PDF 文档时都会启动一个新的"Google Chrome for Testing"进程。这些进程会持续占用服务器内存资源，长时间运行后可能导致系统内存耗尽，甚至影响其他服务如 SQL 查询的性能。

问题根源分析

经过多位开发者的验证和讨论，确认问题主要来源于以下几个方面：

1. 浏览器实例未正确释放：虽然代码中使用了 using 语句或调用了 CloseAsync 方法，但 Chrome 进程仍然残留
2. 隐式子页面：Chrome 浏览器在运行过程中可能会自动创建额外的标签页
3. 异步关闭顺序：页面和浏览器的关闭顺序可能影响进程的完全终止

解决方案

完整资源释放模式

以下是经过验证的有效解决方案代码模板：

using (var browser = await Puppeteer.LaunchAsync(new LaunchOptions
{
    ExecutablePath = "chrome路径",
    Headless = true,
    Args = new[] { "--no-zygote", "--no-sandbox" }
}))
{
    using (var page = await browser.NewPageAsync())
    {
        // 执行页面操作...
        await page.CloseAsync();
    }
    
    // 关闭所有剩余页面
    foreach (var page in await browser.PagesAsync())
    {
        if (!page.IsClosed)
            await page.CloseAsync();
    }
    
    // 确保浏览器关闭
    if (!browser.IsClosed)
        await browser.CloseAsync();
}

关键点说明

1. 显式关闭所有页面：即使只创建了一个页面，Chrome 可能自动生成其他页面，需要遍历关闭
2. 状态检查：在关闭前检查页面和浏览器是否已关闭，避免重复操作
3. 关闭顺序：先关闭所有页面，再关闭浏览器实例

最佳实践建议

1. 资源监控：在服务器上实施进程监控，及时发现残留的 Chrome 进程
2. 异常处理：在 try-catch 块中包装浏览器操作，确保异常情况下也能释放资源
3. 超时设置：为浏览器操作配置合理的超时时间，防止长时间挂起
4. 进程回收：考虑实现一个定时任务，定期清理残留的浏览器进程

技术背景

Puppeteer-Sharp 是通过 Chrome DevTools Protocol 与 Chrome/Chromium 浏览器通信的.NET 库。当浏览器以 headless 模式启动时，它作为独立进程运行。正确的资源释放需要：

1. 关闭所有 DevTools 协议会话
2. 发送正确的退出信号给浏览器进程
3. 处理可能存在的子进程

通过上述方案，开发者可以有效解决 Puppeteer-Sharp 使用中的 Chrome 进程泄漏问题，确保系统资源的合理利用。