调整max-old-space-size后Node.js仍报JavaScript堆内存溢出错误

你调大Node堆内存上限完全没用，因为问题根本不是默认内存配额不够，是代码里有多处逻辑错误导致内存持续泄漏、进程卡死，再大的内存也会被占满：

• 首先是参数传参错误直接导致进程卡死：你调用getScreenShot时传了5个参数(festival, $, page, browser, 1000)，但函数定义的形参只有4个(festival, $, page, timeout)，这就导致函数里拿到的timeout实际是browser实例，await page.waitForTimeout(timeout)相当于传入对象做超时时间，会直接卡在这里；同时函数里调用browser.close()时根本找不到browser变量，浏览器实例永远不会被关闭，每发一次请求就留一个占几百MB内存的Chromium僵尸进程，跑几次内存就被吃满，连其他Node脚本都跑不动，这就是你说进程卡在getScreenshot位置的直接原因。
• 其次是DOM遍历逻辑有严重的性能问题：你用的选择器$('section,select,div,img,span,a,i,b,li,p,h1,h2,h3,h4')会选中页面几乎所有元素，遍历过程中反复执行clone()、节点删除、$.html()操作——$.html()每次调用都会序列化整个DOM树，遍历上千个元素时相当于重复序列化整页DOM上千次，内存占用直接指数级上涨；而且你在循环里每遍历一个元素就打印一次内存占用日志，大量控制台IO也会额外拖慢速度、占用缓存内存；另外循环里定义的replaceParent变量从来没被使用，属于纯无效计算白耗资源。
• 第三是重复请求浪费资源：你已经用Puppeteer打开了目标URL，后面又用Axios请求了一次同一个地址，平白多消耗一倍带宽和内存存响应内容。
• 第四是资源复用逻辑缺失：你已经引入了puppeteer-cluster但完全没使用，现在每次爬取都启动一个全新的浏览器实例，并发跑3个任务就会同时开3个浏览器，再加上之前没关掉的僵尸进程，内存很快就会耗尽。
• 第五是返回值占内存过大：你把Puppeteer生成的截图原始Buffer直接挂在返回对象上，整页截图的单张Buffer体积就有几十到上百MB，3张截图就能占掉几百MB内存。

按以下顺序修改，改完默认内存配置就能正常运行，不需要设8G的堆上限：

1. 先修正getScreenShot的形参列表，补全browser参数，修正参数顺序：

const getScreenShot = async(festival, $, page, browser, timeout) => {

2. 清理遍历逻辑里的无效操作：
   • 删除循环里的console.log(process.memoryUsage())日志
   • 删除未被使用的html变量、replaceParent变量定义，不要在元素遍历循环里调用全局$.html()序列化整个DOM
   • 缩小选择器范围，去掉a、span、img、i、b这类嵌套内联元素，只遍历块级元素div,p,li,h1,h2,h3,h4,section，避免同一段文本被父子元素重复匹配多次
3. 删除重复的Axios请求：Puppeteer打开页面后，直接用const html = await page.content()拿到页面内容传给cheerio加载即可，不需要再发一次HTTP请求。
4. 复用浏览器实例：不要在每个scraper任务里都调用puppeteer.launch()，服务启动时全局启动一个浏览器实例，所有爬取任务复用这个实例创建新页面，爬完单个页面后及时调用page.close()释放页面资源，所有任务结束后再关闭浏览器；如果要做并发控制，直接用你已经引入的puppeteer-cluster配置最大并发数为2即可，避免同时开太多页面占内存。
5. 优化截图逻辑：如果不是必须返回截图Buffer给前端，就只把截图存到本地磁盘，不要把Buffer挂在festival响应对象里返回；如果不需要整页截图就去掉fullPage: true配置，大幅降低截图生成的内存占用。
6. 临时释放内存：现在跑不了Node脚本是因为后台攒了大量僵尸Chromium进程，打开系统任务管理器/活动监视器，把所有Chromium、Chrome进程全部强制结束，就能释放被占满的内存。

内容的提问来源于stack exchange，提问作者Leonie