大文件流式处理、避免内存驻留

当 Node.js 程序处理大文件（例如几百 MB 的日志、视频或数据库导出文件）时，如果像处理小文件那样一次性将整个文件读入内存，就可能引发严重的内存问题。这里的关键在于 流（Stream），它让我们可以分批处理数据，内存中始终只保留当前处理的那一小块，而不会随着文件体积膨胀而无限制增长。

一次性读取的隐患

用 fs.readFile 读取文件是最直观的方式，但它的实现是把文件完整读到内存中的 Buffer 或字符串：

const fs = require('fs');

// 危险：如果文件有 2GB，这个操作可能会直接撑爆内存
const data = fs.readFileSync('/path/to/large-file.mp4');
console.log(data.length);

即便使用异步版本 fs.readFile，也只是不阻塞事件循环，内存占用的峰值仍然等于整个文件的大小。当并发用户上传多个大文件，或者定期批量处理大型 CSV 时，内存会迅速被吃完，最终导致进程被 OOM Killer 杀死。因此，处理大文件的铁律是：永远不要一次性读入全部内容。

流的本质：分块处理 + 背压控制

流把数据切成一个个小块（chunk），每次只在内存中加载一个块，处理完一个再加载下一个。更重要的是，流自带 背压（backpressure） 机制：如果可写端处理速度跟不上可读端的产块速度，流会自动暂停读取，避免内部缓冲队列堆积过多数据，从而严格控制内存使用。

Node.js 提供了四种基础流：

可读流（Readable）：如 fs.createReadStream，用于从文件、网络等源读取数据。
可写流（Writable）：如 fs.createWriteStream，用于向文件、网络等目标写入数据。
转换流（Transform）：同时可读可写，常用于数据转换（压缩、加密、格式转换）。
双工流（Duplex）：同样可读可写，但读写通道独立（如网络套接字）。

在实际编码中，pipe 管道是最简单的连接方式：

const fs = require('fs');
const zlib = require('zlib');

const readStream = fs.createReadStream('large-file.log');
const gzip = zlib.createGzip();          // 转换流：压缩
const writeStream = fs.createWriteStream('large-file.log.gz');

readStream.pipe(gzip).pipe(writeStream);

pipe 方法自动处理了背压：当 writeStream 来不及写入数据时，gzip 和 readStream 都会暂停，直到可以继续写入，再恢复读取。整个过程中，内存占用大致相当于一个或多个 chunk 的大小（默认 64KB），与原始文件的体积完全无关。

实际开发中的流式处理要点

1. 选择合理的 highWaterMark

流的 highWaterMark 决定了内部缓冲区的大小，即每次最多读取/写入的字节数。默认值一般是 64KB，对大多数场景足够，但可以按需调整：

处理大量小文件时，可适当减小 highWaterMark 以提高并发度；
处理超大文件且磁盘顺序读取性能允许时，可适当增大以减少系统调用次数。

const readStream = fs.createReadStream('giant.csv', { highWaterMark: 256 * 1024 }); // 每次读 256KB

不要盲目追求大 chunk；过大会导致单次处理占用过多 CPU 时间，影响并发请求的响应。

2. 使用 pipeline 管理流生命周期

pipe 虽然方便，但不会自动销毁流链，也不会传递错误。如果中间某个环节出错（比如文件不存在、磁盘写满），上游的流可能未被正确关闭，导致资源泄漏。从 Node.js 10 开始，推荐使用 stream.pipeline：

const { pipeline } = require('stream');
const fs = require('fs');
const zlib = require('zlib');

pipeline(
  fs.createReadStream('source.txt'),
  zlib.createGzip(),
  fs.createWriteStream('source.txt.gz'),
  (err) => {
    if (err) {
      console.error('流处理失败', err);
    } else {
      console.log('压缩完成');
    }
  }
);

pipeline 会在任一阶段发生错误时自动销毁所有流，并触发最终的回调，极大简化了错误处理。

3. 在 HTTP 响应中流畅传输大文件

向客户端返回大文件时，直接把文件流通过管道连到 res 既可有效降低服务器内存压力，也能利用背压控制传输速度：

const http = require('http');
const fs = require('fs');

http.createServer((req, res) => {
  const stream = fs.createReadStream('/large-video.mp4');
  stream.pipe(res);
}).listen(3000);

Node.js 会自动处理 Content-Length 无法确定的情况，切换到分块传输编码（chunked transfer encoding），并且当客户端断开连接时，pipe 会传播 error 事件，使文件读取的流也能及时关闭。

4. 避免内存“慢性泄漏”的细节

及时销毁不再需要的流：如果手动创建流并监听事件，当出现错误或中途抛弃时，调用 stream.destroy() 释放底层资源。
避免在 Transform 流中积压大量数据：转换流若内部处理需要大量内存（如整个 JSON 转义后再输出），会抵消流的优化效果，此时应该设计成真正的逐块转换。
小心缓冲区的叠加效应：如果一组流链里有多个 Transform 流，每个都有自己的缓冲区，背压虽然会暂停产速，但整个链中可能同时存在多个 chunk，应确保它们各自的 highWaterMark 不过大。

5. 手动实现分块处理：灵活场景

当业务逻辑需要逐行解析大 CSV 并插入数据库，不适合直接用 pipe，则需要手动操作可读流：

const fs = require('fs');
const readline = require('readline');

async function processLineByLine() {
  const fileStream = fs.createReadStream('large.csv');
  const rl = readline.createInterface({
    input: fileStream,
    crlfDelay: Infinity
  });

  for await (const line of rl) {
    // 处理每一行，内存中仅保留当前行
    await processLine(line);
  }
}

这里的 for await...of 借助异步迭代器，逐行读取，内存占用只与单行长度相关。

大文件流式处理的价值

流式处理将内存占用从“文件越大，内存越高”的线性增长，转变为“无论文件多大，内存基本恒定在几百 KB”。这一技术不仅适用于文件复制、压缩、解压，也是建设高性能 Web 服务、API 网关、日志中间件的基石。它避免了内存抖动和 GC 停顿，让 Node.js 在处理 GB 级数据时依旧能够保持稳定高效。

总结几个核心原则供日常开发参考：

遇到任何可能超过一百 MB 的文件输入/输出，直接考虑流。
优先使用 pipeline 确保资源安全释放。
通过 highWaterMark 和并发控制精准调控内存。
将转换逻辑设计成无状态的、逐块处理的 Transform 流。

掌握这些技巧，就能够在大量数据处理的场景中充分发挥 Node.js 非阻塞 I/O 和事件驱动模型的优势，写出既快又省内存的生产级代码。