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

问题现象

在使用 Puppeteer-Sharp (12.0.0) 与 ASP.NET Core 3.1 结合开发 Web 应用时，开发者发现每次生成 PDF 文档后，服务器上都会残留"Google Chrome for Testing"进程。随着应用持续运行，这些未被关闭的 Chrome 进程会不断累积，有时甚至达到20多个实例，导致服务器内存资源被大量占用，进而影响 SQL 查询等关键操作。

问题根源分析

经过多位开发者的实践验证，发现这个问题主要由以下几个因素导致：

1. 浏览器实例未正确释放：虽然代码中使用了 using 语句，但 Chrome 进程仍然未被完全关闭
2. 隐式创建的页面未被处理：Chrome 浏览器在启动时会自动创建空白标签页
3. 异步关闭顺序不当：页面和浏览器的关闭顺序可能影响进程的完全终止

解决方案

1. 完整资源释放模式

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

using (var browser = await Puppeteer.LaunchAsync(new LaunchOptions
{
    ExecutablePath = exePath,
    Timeout = requestTimeout,
    Headless = true,
    IgnoreHTTPSErrors = 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();
}

2. 关键点说明

1. 显式关闭所有页面：通过 browser.PagesAsync() 获取所有页面实例并逐一关闭
2. 状态检查：在关闭前检查页面和浏览器是否已关闭，避免重复操作
3. 关闭顺序：先关闭所有页面，再关闭浏览器实例

3. 额外建议

1. 异常处理：在实际应用中应添加 try-catch 块处理可能的异常
2. 超时设置：为 CloseAsync 操作设置合理的超时时间
3. 进程监控：在应用启动时检查并终止可能存在的残留 Chrome 进程

技术原理

Puppeteer-Sharp 通过 Chrome DevTools Protocol 与 Chrome 浏览器通信，每个浏览器实例实际上是一个独立的 Chrome 进程。当使用 Headless 模式时，虽然看不到界面，但进程依然存在。浏览器启动时会默认创建一个空白页面，如果这个页面未被正确处理，即使主页面已关闭，浏览器进程仍可能保持运行状态。

总结

正确处理 Puppeteer-Sharp 中的浏览器和页面资源释放对于长期运行的服务器应用至关重要。通过遵循上述解决方案，开发者可以有效避免 Chrome 进程泄漏问题，确保服务器资源的合理利用。这一问题的解决不仅适用于 PDF 生成场景，也同样适用于其他使用 Puppeteer-Sharp 进行网页截图、自动化测试等功能的场景。