Node.js使用管道流下载大文件内存过高及OOM错误问题咨询

开发者阿泽

2026-9-27

问题根因

你使用的request库自带的重试机制是内存占用过高的核心原因：为了支持请求失败重试，request会默认将完整响应体全部缓冲在内存中，完全绕过了pipe的背压管理逻辑，所以300MB的文件会全部加载到内存后才会开始写入磁盘，自然会出现内存占用和文件大小持平的情况。
流变量作用域问题：代码中的req、writestream、tempFile等变量都定义在外层/全局作用域，流使用完成后没有清空引用，V8垃圾回收器无法回收关联的缓冲区，即使删除本地文件，内存中的缓存数据也不会被释放。
流销毁逻辑缺失：请求或写入流出错时，没有主动销毁两个流对象，残留的内部缓冲区无法被回收。
多余的流操作逻辑：pipe方法会自动在源请求流结束时调用写入流的end()方法，你手动调用writestream.end()会导致流缓冲数据还未写完就提前关闭，额外造成内存残留；同时在请求流的end事件中处理写入完成逻辑时序错误，此时写入流可能还未刷完所有缓冲数据。

修复方案

优先解决重试带来的缓冲问题：
如果你必须保留重试能力，放弃使用request自带的重试策略，自己实现基于断点续传的流重试逻辑，不要依赖库级别的全量缓冲重试。如果不需要重试，直接删除配置中的maxAttempts、retryDelay、retryStrategy三个参数即可关闭响应缓冲，让pipe的背压机制正常生效。
调整变量作用域：
将writestream、tempFile等流相关变量改为response回调内部的局部变量，流处理完成后手动将外层的req引用置空，方便GC回收。

完善错误销毁逻辑：
所有错误回调中都主动销毁流对象，清空内部缓冲：

// 写入流错误回调新增
req.destroy();
writestream.destroy();
// 请求流错误回调新增
if (writestream) writestream.destroy();

替换pipe为官方推荐的pipeline方法：
Node.js原生的stream.pipeline会自动处理背压、错误捕获、流销毁，比手动调用pipe更安全，替换示例：

const { pipeline } = require('stream');
// 替换原有的req.pipe(writestream)
pipeline(
  req,
  writestream,
  (err) => {
    if (err) {
      console.log('下载失败', err);
      abortOperation = true;
      isStarted = "no";
      _deleteProgressPointer(ip);
    } else {
      // 原写入流finish事件的逻辑直接写到这里即可
      console.log(methodName, `File successfully downloaded for device ${ip} of firmware version ${firmwareVersion}`);
      // 后续文件校验、删除逻辑不变
    }
  }
)

删除冗余逻辑：去掉手动调用的writestream.end()，以及请求流end事件中的写入完成判断逻辑，全部交给pipeline处理即可。

补充说明：如果你用docker stats查看的内存包含了Linux系统的页缓存，这部分是文件系统的自动缓存，不属于Node.js的堆内存占用，系统会在内存不足时自动回收，不会触发OOM，你遇到的OOM问题基本都是request缓冲导致的Node.js堆内存溢出。

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