Node.js 处理 GB 级文件时，fs.readFile 会把整个文件读入内存：如果是 2GB 的日志文件，仅 Buffer 就可能超过 2GB，再加上字符串转换和中间变量，进程很容易触发 OOM。Stream 按块处理可以显著降低内存压力，但并不是用了 Stream 就高枕无忧。可读流和可写流之间一旦出现速度差，数据块就会在中间的缓冲队列里堆积，处理几 GB 数据时，这种堆积会迅速吃光可用内存。想让大文件处理稳定跑完，需要理解并主动控制背压。

一、背压的形成与 highWaterMark

背压的本质是上下游处理能力不匹配。假设磁盘读取速度是 200MB/s，而下游写数据库或网络只能处理 20MB/s，那么每隔一秒，就有约 180MB 的数据滞留在内存里。Node.js 的流并不是无限缓冲，它提供了 highWaterMark 这个水位线来控制内部缓冲大小。可读流的 highWaterMark 默认是 64KB，表示内部缓冲最多暂存 64KB 数据；当缓冲数据超过这个值时，可读流会停止从底层读取，直到消费者把数据取走。同样，可写流的 highWaterMark 控制写入队列的长度，当队列超过水位线时，write 方法会返回 false。

手动绑定 data 事件的代码如果忽略了 write 的返回值，直接把每个 chunk 都塞给写流，那么即便写流来不及处理，读流仍然继续产生数据，背压机制没有被触发，水位线形同虚设。正确的做法是：当 write 返回 false 时暂停读流，等到 drain 事件触发再继续。下面是一个手动实现背压的例子。

const fs = require('fs');
const readStream = fs.createReadStream('bigfile.bin', { highWaterMark: 1024 * 1024 });
const writeStream = fs.createWriteStream('copy.bin');
readStream.on('data', function(chunk) {
  const canContinue = writeStream.write(chunk);
  if (!canContinue) {
    // 写流内部缓冲已满，先暂停读流
    readStream.pause();
    writeStream.once('drain', function() {
      readStream.resume();
    });
  }
});
writeStream.on('finish', function() {
  console.log('复制完成');
});

这种方式有效但繁琐，而且容易漏掉错误处理和结束事件。日常开发中更推荐使用 pipe 或 pipeline，它们内部已经封装了背压传播和结束转发。

二、pipe 与 pipeline 的背压差异

pipe 是 Stream 中处理背压最经典的方式。它会监听 data 事件，把读到的块写入目标流；一旦目标流返回 false，pipe 会自动暂停源流，直到 drain 再恢复。这个过程不需要开发者额外写逻辑。对于简单的文件复制、静态文件转发场景，pipe 足够稳定。假设要把一个 3GB 的备份文件复制到另一个目录，使用 createReadStream 接 pipe 到 createWriteStream，内存占用通常会维持在一个相对平稳的水平。

不过 pipe 有两个明显缺点。第一，它不会自动销毁出错的源流或目标流，源流读取出错时目标流可能还挂在半截文件上，导致句柄泄漏或不完整输出。第二，中间加入多个转换流时，单个环节报错不一定能传递到最终回调，排查起来比较麻烦。Node.js 提供的 stream.pipeline 方法解决了这些问题，它会自动处理背压、结束和错误传播，任何一个环节失败都会执行回调并销毁整条管道。下面是一个通过 pipeline 处理大文件并加入自定义转换流的示例。

const fs = require('fs');
const { pipeline, Transform } = require('stream');
pipeline(
  fs.createReadStream('source.dat', { highWaterMark: 512 * 1024 }),
  new Transform({
    transform(chunk, encoding, callback) {
      // 模拟 CPU 密集型处理，强制下游消费速度变慢
      setTimeout(function() {
        callback(null, chunk);
      }, 3);
    }
  }),
  fs.createWriteStream('dest.dat'),
  function(err) {
    if (err) {
      console.error('管道处理失败：', err);
    } else {
      console.log('GB 级文件处理完成');
    }
  }
);

这个例子中，Transform 的 callback 延迟 3 毫秒才把数据传出，会明显拖慢读流速度。因为 pipeline 内部传播背压，上游不会一次性把所有数据读入内存，而是等下游消费完一块再读下一块。如果去掉这个延迟，写盘速度接近读盘速度，管道整体吞吐会高很多。

三、用 Transform 和异步迭代细化背压控制

真实的大文件处理往往不只是复制。比如解析 GB 级 JSON Lines 日志、按规则过滤数据、批量写入数据库。此时可以继承 Transform，在 _transform 中完成单块处理，但要注意不要在 _transform 里做无上限的异步任务。如果每个 chunk 都发起一个数据库写入并立即 callback，下游 SQL 连接池很快会被打满，背压也会失效。正确做法是等待写入结果返回后再调用 callback，让单个块的处理时间成为天然限速器。

另一种可读性更好的方式是使用 for await...of 消费可读流。异步迭代会在每次拿到数据后执行循环体，循环体内部的 await 会暂停整个迭代过程，从而给上游施加背压。配合 readline 模块，可以按行处理 GB 级文本文件，且不会把整文件拆成海量小字符串同时驻留内存。下面这个例子统计一个超大日志文件的行数，并每十万行打印一次进度。

const fs = require('fs');
const readline = require('readline');
async function countLines(filePath) {
  const rl = readline.createInterface({
    input: fs.createReadStream(filePath, { encoding: 'utf8', highWaterMark: 1024 * 1024 }),
    crlfDelay: Infinity
  });
  let lineCount = 0;
  for await (const line of rl) {
    lineCount += 1;
    if (lineCount % 100000 === 0) {
      console.log('已处理行数：', lineCount);
    }
  }
  console.log('总行数：', lineCount);
}
countLines('big.log').catch(function(err) {
  console.error('读取失败：', err);
});

这里 highWaterMark 设置为 1MB，可以降低系统调用频率，但也会略微增大内存占用。对于 GB 级文件，1MB 仍然是可以接受的缓冲大小。如果下游写入数据库或远程服务，可在循环体里做 await insertData(line)，一旦写入变慢，for await...of 会自然放慢读取速度，保证内存不会冲高。

四、调整水位线、监控内存与实战建议

highWaterMark 的大小没有万能值。设置得太大，比如 16MB，单次读入和写出的块变大，处理吞吐可能提高，但内存峰值也成倍上升；设置得太小，比如 16KB，内存控制更精细，但系统调用次数增多，CPU 开销变大。处理 GB 级文件时，可以把读写流都设置成 1MB 到 4MB 之间的值，再根据实际内存和磁盘速度做调整。对于机械硬盘或网络文件系统，块太大还可能造成延迟抖动，因此需要结合 process.memoryUsage() 持续观测。

一个实用的监控方式是在处理过程中每 N 个块打印一次内存占用。可以在 Transform 的 transform 里累计处理字节数，当累计值超过 100MB 时输出一次 heapUsed 和 rss。如果发现 heapUsed 持续上涨，说明有数据没有及时释放，要检查是否在 data 事件里同步处理了慢任务，或者是否在流管道外又维护了一份全量数组。另一个常见误区是在 Transform 内部用 push 把每个小块拼成完整行数组，这等于自己实现了一个不受背压控制的缓冲，完全抵消了流式处理的优势。

还可以结合 stream.finished 来确保流结束时资源被正确清理。与 pipeline 类似，finished 会在流结束、关闭或出错后触发回调，适合在回调里关闭数据库连接或删除临时文件。对于超大文件，建议把处理逻辑拆成多个 Transform 串联，每个转换只做一件事，这样定位背压瓶颈时更清晰：如果内存涨得快，通常是某个转换流内部积压；如果 CPU 高但内存稳定，则是处理逻辑本身需要优化。

综合来看，Node.js 处理 GB 级文件的背压控制并不是靠某个单一 API，而是需要理解流的缓冲机制、利用 pipeline 或异步迭代传播背压、合理设置 highWaterMark，并在关键节点监控内存。做到这些，几 GB 甚至更大的文件也能在几百 MB 内存限制下稳定处理。