在 Heroku 上运行 Puppeteer 时，运行中断往往不是代码逻辑错误，而是浏览器资源没有管好。Heroku 的 Dyno 有内存上限，Puppeteer 启动的 Chromium 很吃内存，一旦泄漏就会触发系统 OOM 杀进程。
为什么会出现内存泄漏
最常见的问题是每一次请求或任务都调用 puppeteer.launch() 然后忘记 browser.close()。下面这段伪代码就是典型的错误写法：
// 错误示例：每次都开浏览器却不关
async function scrape() {
const browser = await puppeteer.launch({ args: ['--no-sandbox'] });
const page = await browser.newPage();
await page.goto('https://ipipp.com');
const title = await page.title();
return title;
// 没有 browser.close()，内存泄漏
}
基础修复：确保关闭浏览器
使用 try-finally 保证无论成功失败都释放资源：
async function scrape() {
const browser = await puppeteer.launch({
args: ['--no-sandbox', '--disable-setuid-sandbox']
});
try {
const page = await browser.newPage();
await page.goto('https://ipipp.com');
return await page.title();
} finally {
await browser.close();
}
}
进阶方案：复用浏览器实例
在 Heroku 上更推荐常驻一个浏览器，多个任务共用。可以用一个单例管理：
let browserInstance = null;
async function getBrowser() {
if (!browserInstance) {
browserInstance = await puppeteer.launch({
args: ['--no-sandbox', '--disable-dev-shm-usage']
});
// 监听断开，自动置空
browserInstance.on('disconnected', () => {
browserInstance = null;
});
}
return browserInstance;
}
控制并发与页面池
不要无限制开页面，可用简单数组做页面池：
- 限制同时最多 5 个 page
- 任务结束调用
page.close() - 定时检查浏览器内存占用
Heroku 特有配置
| 参数 | 作用 |
|---|---|
| --no-sandbox | 容器环境必须，避免权限错误 |
| --disable-dev-shm-usage | 使用 /tmp 代替 /dev/shm，防内存不足 |
| --single-process | 极端省内存，但易崩，谨慎用 |
日志与监控建议
在代码里定期打印 process.memoryUsage()，发现堆内存持续增长就排查未关对象。Heroku 的 metrics 页也能看 Dyno 内存曲线。
资源管理核心：启动有数、关闭有责、复用有度。
小结
解决 Puppeteer 在 Heroku 中断，关键在浏览器生命周期。通过单例复用、正确关闭、限流和启动参数调整，基本可以消除大部分内存泄漏导致的崩溃。