Puppeteer并发内存暴增主因是Chromium实例内存不归Node.js管理，每个实例占200–500MB且隐藏于OS进程层；需用ps/tasklist监控RSS，而非process.memoryUsage()或DevTools。
为什么Puppeteer并发时内存暴增却查不到泄漏点
不是代码写错了，而是 Chromium 实例的内存不归 Node.js 的 process.memoryUsage() 管——你看到的只是 Node 进程本身那几十 MB，真正的内存大户（每个浏览器实例 200–500MB）藏在操作系统级进程里。VSCode 里跑 console.log(process.memoryUsage()) 完全没用，它根本反映不了真实压力。
- Chrome DevTools 的 Memory 面板只对当前页面生效，且无法跨多个
page实例聚合统计 -
puppeteer.launch()每次都拉起全新 Chromium 进程，browser.close()不等于立即释放内存，内核有延迟回收机制 - Linux/macOS 下用
ps aux --sort=-%mem | head -10才能抓到真凶；Windows 用任务管理器看 “chrome.exe” 总内存占用更直观 - 别信
browser.process()?.kill()能立刻清空——得等 OS 回收，中间可能卡住几秒
如何用 VSCode 实时监控 Puppeteer 并发内存水位
靠手动查 ps 太滞后，得把监控嵌进脚本里，并让 VSCode 终端可读。核心是两件事：暴露 Chromium 进程 PID + 定期采样 OS 内存数据。
- 启动时加
dumpio: true和env: { PUPPETEER_DEBUG: '1' }，能在终端看到 Chromium 启动日志和 PID 行（形如[PID: 12345]） - 用
child_process.execSync('ps -o pid,rss,comm= -p ' + browser.process().pid)（Linux/macOS）或tasklist /fi "pid eq ' + browser.process().pid + '"（Windows）实时抓 RSS 内存 - 把采样逻辑封装成独立函数，每开一个
browser就注册一次定时器：setInterval(() => console.log(`Browser ${i} RSS: ${rss} MB`), 3000) - VSCode 集成终端默认缓冲区小，大量日志会丢行——右键终端 → “Scrollback Buffer Size” 调到 5000 行以上
并发控制不当导致 OOM 的三个典型信号
不是等到报 FATAL ERROR: Reached heap limit 才发现问题。以下现象出现任意一条，说明并发数已超安全阈值：
- VSCode 终端输出开始明显卡顿（>1s 延迟），不是代码慢，是系统调度吃紧
-
browser.pages()返回空数组或超时，说明 Chromium 实例已僵死但未退出 -
await page.goto(url)卡在networkidle2超过 30s，大概率是内存不足触发了页面资源加载冻结 - Linux 下
dmesg | tail出现Out of memory: Kill process——这时 OS 已经干掉你的 Puppeteer 进程了
VSCode 调试时怎么避免内存监控干扰主流程
调试器本身会拖慢执行节奏，而内存监控又依赖高频采样，两者叠加容易误判。关键是要分离监控通道：
- 别把内存采集逻辑写在
page.evaluate()或page.waitForSelector()里——这些运行在浏览器上下文，和 Node 进程内存无关 - 用
worker_threads单独起一个监控线程，通过parentPort.postMessage()推送 RSS 数据，主线程只负责接收和打印 - VSCode 断点打在业务逻辑上，不要打在
execSync调用行——它会阻塞整个 Node 进程，导致采样失真 - 关掉
devtools: true再调试，DevTools UI 本身就要额外 80–120MB 内存，纯无头模式才接近生产环境压力
for (let i = 0; i ，而是每个 <code>browser 实例背后那个你不直接看见、却持续吃掉 GB 级内存的 Chromium 进程。监控必须落到 OS 层，而不是相信 Node 的数字。 
