本教程探讨 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 4752023-05-22T17:29:19.098698+00:00 app[web.1]: == Finished grabbing CS 3312023-05-22T17:29:19.783377+00:00 app[web.1]: == Finished grabbing CS 3702023-05-22T17:29:49.992190+00:00 app[web.1]: /app/node_modules/puppeteer/lib/cjs/puppeteer/common/util.js:3172023-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 上稳定地处理所有预期的任务。
注意事项与最佳实践
资源管理是核心： 始终将 browser.close() 视为与 puppeteer.launch() 配对使用的关键操作。忘记关闭浏览器是 Puppeteer 内存泄漏最常见的原因。try…finally 块： 使用 try…catch…finally 结构是最佳实践。finally 块中的代码无论 try 块中是否发生错误都会执行，从而确保浏览器实例在任何情况下都能被关闭，避免因程序异常导致资源无法释放。Heroku Dyno 内存限制： 了解 Heroku Dyno 的资源限制至关重要。即使正确关闭了浏览器，如果单个抓取任务本身就需要大量内存，或者在短时间内并发启动了过多的浏览器实例，仍然可能遇到内存问题。对于大量任务，考虑使用队列机制或批处理，错峰执行，避免瞬间的资源高峰。超时设置： 原始日志中的 TimeoutError 也可能与网络延迟或页面加载缓慢有关。虽然内存泄漏是主要原因，但适当调整 page.goto()、page.waitForSelector() 等操作的超时时间（例如，从默认的 30 秒调整为更符合实际情况的值），可以提高脚本的鲁棒性。无头模式 (Headless Mode)： 尽管无头模式能减少一些资源消耗，但它并不能替代显式关闭浏览器实例。在 Heroku 等服务器环境中，通常都应使用无头模式运行 Puppeteer。错误处理： 在 catch 块中捕获并记录错误，可以帮助调试和理解脚本失败的原因。根据应用需求，可以选择重新抛出错误、返回默认值或执行其他恢复操作。
总结
Puppeteer 在 Heroku 等云平台部署时遇到的运行中断问题，其核心往往是由于未正确关闭浏览器实例导致的内存泄漏。通过在每次抓取任务完成后，使用 await browser.close() 显式释放资源，并结合 try…finally 块确保资源在任何情况下都能被释放，可以有效解决这一问题。良好的资源管理是构建稳定、高效且可扩展的网页抓取或自动化脚本的关键。
以上就是解决 Puppeteer 在 Heroku 上运行中断：内存泄漏与浏览器资源管理的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1520277.html
微信扫一扫 
支付宝扫一扫 
