PuppeteerHeroku运行中断解决方法

在使用 Puppeteer 在 Heroku 等云平台进行网页抓取时，你是否遇到过脚本频繁中断并抛出超时错误的问题？本文将深入探讨这一常见难题，揭示其背后的根本原因：未正确关闭 Puppeteer 浏览器实例导致的内存泄漏。我们将详细分析这种现象，并提供简单有效的解决方案：在每次数据抓取后，务必显式调用 `browser.close()` 方法，以释放资源、防止内存耗尽。通过本文，你将学会如何在生产环境中稳定运行 Puppeteer 脚本，避免资源瓶颈，提升自动化效率。立即阅读，解决你的 Puppeteer 云端部署难题！

本教程探讨 Puppeteer 在 Heroku 等云平台运行时，在执行少量任务后停止并抛出超时错误的问题。核心原因在于未正确关闭 Puppeteer 浏览器实例导致的内存泄漏。文章将详细解释这一现象，并提供通过在每次数据抓取后显式调用 browser.close() 来有效管理资源、防止内存耗尽的解决方案，确保 Puppeteer 脚本在生产环境中稳定运行。

问题现象：Puppeteer 在 Heroku 上的运行瓶颈

许多开发者在使用 Puppeteer 进行网页抓取或自动化时，可能会遇到一个常见且令人困惑的问题：脚本在本地开发环境中运行良好，但在部署到 Heroku 等云平台后，仅执行少量任务便会中断，并抛出 TimeoutError。

例如，一个旨在循环抓取多项数据的 Puppeteer 脚本，在本地可以顺利完成所有任务，但在 Heroku 的部署日志中，可能会在成功抓取几项数据后，出现类似以下的错误信息：

2023-05-22T17:29:18.421015+00:00 app[web.1]: == Finished grabbing CS 475
2023-05-22T17:29:19.098698+00:00 app[web.1]: == Finished grabbing CS 331
2023-05-22T17:29:19.783377+00:00 app[web.1]: == Finished grabbing CS 370

2023-05-22T17:29:49.992190+00:00 app[web.1]: /app/node_modules/puppeteer/lib/cjs/puppeteer/common/util.js:317
2023-05-22T17:29:49.992208+00:00 app[web.1]:     const timeoutError = new Errors_js_1.TimeoutError(`waiting for ${taskName} failed: timeout ${timeout}ms exceeded`);
2023-05-22T17:29:49.992209+00:00 app[web.1]:                          ^
2023-05-22T17:29:49.992210+00:00 app[web.1]: TimeoutError: waiting for target failed: timeout 30000ms exceeded

这个 TimeoutError，特别是 waiting for target failed，通常意味着 Puppeteer 尝试与浏览器实例建立连接或等待某个目标（如页面）时，浏览器本身已变得无响应或崩溃。这种现象往往指向资源耗尽，尤其是在 Heroku 这种具有严格内存限制的平台上。

深层原因：未关闭的浏览器实例导致的内存泄漏

Puppeteer 在执行 puppeteer.launch() 时，会启动一个全新的 Chromium 浏览器进程。这个浏览器进程及其打开的所有页面（page 对象）会占用相当可观的系统资源，包括内存和 CPU。如果在一个循环中反复调用 puppeteer.launch() 来执行独立的抓取任务，但每次任务完成后都没有显式地关闭浏览器实例，那么每个被启动的浏览器进程将持续占用资源而不会被释放。

在本地开发环境中，由于通常拥有更充足的系统资源，这种内存泄漏可能不会立即显现。然而，在 Heroku 的 Dyno 环境中，可用内存通常只有 512MB（对于免费或标准 Dyno），几个未关闭的浏览器实例就可能迅速耗尽所有可用内存。当内存耗尽时，操作系统可能会杀死进程，或者浏览器进程变得无响应，导致后续的 Puppeteer 操作超时失败。即使将 Puppeteer 运行在无头模式（headless mode），也仅仅是节省了图形界面的资源，并不能解决未关闭浏览器实例造成的内存泄漏问题。

解决方案：显式关闭 Puppeteer 浏览器

解决 Puppeteer 在云端部署时内存泄漏问题的关键在于，每次完成抓取任务后，必须显式地关闭浏览器实例。通过调用 await browser.close() 方法，可以确保所有相关的浏览器进程和资源被正确释放。

代码示例与改进

以下是原始的 scrapeData 函数及其改进版本，展示了如何正确地关闭浏览器：

原始 scrapeData 函数（存在内存泄漏风险）：

async function scrapeData(code) {
    const browser = await puppeteer.launch({
      args: [
        '--no-sandbox',
        '--disable-setuid-sandbox'
      ]
    })
    const page = await browser.newPage()

    await page.goto("website url") // 替换为实际网址
    await page.type('#crit-keyword', code)
    await page.click('#search-button')

    await page.waitForSelector(".result__headline")
    await page.click(".result__headline")
    await page.waitForSelector("div.text:nth-child(2)")

    let data = await page.evaluate(() => {
        let classTitle = document.querySelector("div.text:nth-child(2)").textContent
            .toLowerCase().split(' ')
            .map((s) => s.charAt(0).toUpperCase() + s.substring(1)).join(' ').replace('Ii', "II")
        let classDesc =  document.querySelector(".section--description > div:nth-child(2)").textContent.replace('Lec/lab/rec.', '').trim()

        return {
            title: classTitle,
            desc: classDesc
        }
    })

    console.log(`== Finished grabbing ${code}`)

    return data // 浏览器实例在此处未被关闭
}

改进后的 scrapeData 函数（加入 browser.close() 和 try...finally）：

async function scrapeData(code) {
    let browser; // 将 browser 声明在 try 块外部，以便 finally 块访问
    try {
        browser = await puppeteer.launch({
            args: [
                '--no-sandbox',
                '--disable-setuid-sandbox'
            ]
            // 默认的超时时间可能需要调整，但这里的TimeoutError主要由内存引起
        });
        const page = await browser.newPage();

        await page.goto("your_website_url", { timeout: 30000 }); // 增加页面导航超时时间
        await page.type('#crit-keyword', code);
        await page.click('#search-button');

        await page.waitForSelector(".result__headline", { timeout: 15000 }); // 增加等待选择器超时时间
        await page.click(".result__headline");
        await page.waitForSelector("div.text:nth-child(2)", { timeout: 15000 }); // 增加等待选择器超时时间

        let data = await page.evaluate(() => {
            let classTitle = document.querySelector("div.text:nth-child(2)").textContent
                .toLowerCase().split(' ')
                .map((s) => s.charAt(0).toUpperCase() + s.substring(1)).join(' ').replace('Ii', "II");
            let classDesc = document.querySelector(".section--description > div:nth-child(2)").textContent.replace('Lec/lab/rec.', '').trim();

            return {
                title: classTitle,
                desc: classDesc
            };
        });

        console.log(`== Finished grabbing ${code}`);
        return data;
    } catch (error) {
        console.error(`Error scraping data for ${code}:`, error);
        throw error; // 重新抛出错误，以便上层调用者可以处理
    } finally {
        if (browser) {
            await browser.close(); // 确保浏览器在任何情况下都被关闭
        }
    }
}

通过在 scrapeData 函数的 finally 块中添加 await browser.close()，我们保证了无论数据抓取成功与否，浏览器实例及其占用的资源都会被妥善释放。这有效地解决了内存泄漏问题，使脚本能够在 Heroku 上稳定地处理所有预期的任务。

注意事项与最佳实践

1. 资源管理是核心： 始终将 browser.close() 视为与 puppeteer.launch() 配对使用的关键操作。忘记关闭浏览器是 Puppeteer 内存泄漏最常见的原因。
2. try...finally 块： 使用 try...catch...finally 结构是最佳实践。finally 块中的代码无论 try 块中是否发生错误都会执行，从而确保浏览器实例在任何情况下都能被关闭，避免因程序异常导致资源无法释放。
3. Heroku Dyno 内存限制： 了解 Heroku Dyno 的资源限制至关重要。即使正确关闭了浏览器，如果单个抓取任务本身就需要大量内存，或者在短时间内并发启动了过多的浏览器实例，仍然可能遇到内存问题。对于大量任务，考虑使用队列机制或批处理，错峰执行，避免瞬间的资源高峰。
4. 超时设置： 原始日志中的 TimeoutError 也可能与网络延迟或页面加载缓慢有关。虽然内存泄漏是主要原因，但适当调整 page.goto()、page.waitForSelector() 等操作的超时时间（例如，从默认的 30 秒调整为更符合实际情况的值），可以提高脚本的鲁棒性。
5. 无头模式 (Headless Mode)： 尽管无头模式能减少一些资源消耗，但它并不能替代显式关闭浏览器实例。在 Heroku 等服务器环境中，通常都应使用无头模式运行 Puppeteer。
6. 错误处理： 在 catch 块中捕获并记录错误，可以帮助调试和理解脚本失败的原因。根据应用需求，可以选择重新抛出错误、返回默认值或执行其他恢复操作。

总结

Puppeteer 在 Heroku 等云平台部署时遇到的运行中断问题，其核心往往是由于未正确关闭浏览器实例导致的内存泄漏。通过在每次抓取任务完成后，使用 await browser.close() 显式释放资源，并结合 try...finally 块确保资源在任何情况下都能被释放，可以有效解决这一问题。良好的资源管理是构建稳定、高效且可扩展的网页抓取或自动化脚本的关键。

终于介绍完啦！小伙伴们，这篇关于《PuppeteerHeroku运行中断解决方法》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！