问题现象：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 上稳定地处理所有预期的任务。
注意事项与最佳实践
- 资源管理是核心： 始终将 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 块确保资源在任何情况下都能被释放，可以有效解决这一问题。良好的资源管理是构建稳定、高效且可扩展的网页抓取或自动化脚本的关键。
