在 Node.js 的实际开发中，我们经常会面对一个简单但致命的问题：如何高效地读写大文件？
想象这样一个场景：你需要处理一个 2GB 的日志文件，提取其中某些关键信息。如果采用最直接的方式——把整个文件一次性读入内存，会发生什么？在第六章中我们了解到，V8 的堆内存有明确的限制（默认约 1.4GB–1.7GB），即便显式扩大了内存上限，将 2GB 的数据全量加载到 Buffer 中也会瞬间消耗大量 RAM，导致进程变慢、GC 压力剧增，甚至直接触发内存溢出（OOM）而崩溃。即便勉强没奔溃，这种方式的处理效率也极低，因为你得等所有数据都读完了才能开始处理。
解决问题的关键就是“流”（Stream）。流的核心理念很简单：不要一次性把全部数据灌进内存，而是把数据切成若干个小块（chunk），一块一块地读、一块一块地处理、处理完就丢弃，内存中同时只保留当前正在处理的那一小段数据。这种“滑窗”式的处理方式，让内存占用从“文件有多大就占多大”骤然降到一个稳定的、极低的水平。
一个直观的对比：readFile vs createReadStream
我们用 Node.js 的文件模块做一个对比实验：
const fs = require('fs');
// ❌ 错误示范：一次性加载 1GB 文件
fs.readFile('/path/to/large-file.log', (err, data) => {
if (err) throw err;
console.log(`文件大小: ${data.length} 字节`);
// 此时整个文件内容都在 data 这个 Buffer 中
});如果你监控这段代码运行时的内存，会看到一个可怕的内存尖峰：进程的 RSS 瞬间攀升到 1GB 以上，然后 data 被使用完毕，等待 GC 回收。如果文件再大一点，整个服务就可能因 JavaScript heap out of memory 错误而直接挂掉。
再看流式处理的版本：
const fs = require('fs');
// ✅ 流式读取：内存稳定在一个极低值
const readable = fs.createReadStream('/path/to/large-file.log', {
highWaterMark: 64 * 1024 // 每次读取 64KB
});
readable.on('data', (chunk) => {
console.log(`收到 ${chunk.length} 字节数据`);
// 可以在这里逐块处理，比如写入另一个文件、解析日志、计算哈希等等
});
readable.on('end', () => {
console.log('文件处理完成');
});无论文件是 1GB 还是 10GB，程序的内存曲线会变成一个非常平缓、几乎固定的数值（可能只有几十 MB），因为内存中同时只存在一个大小为 highWaterMark 的 chunk。其他已经被读取的数据块在 data 回调执行完毕后就可以被 GC 回收，不会在内存中堆积。
真实世界中的分块优势
这种“分块处理”的优势并不仅仅体现在内存节省上。在实际业务中，流还带来了以下非常实用的好处：
1. 即时处理，无需等待全量加载
当处理一个超大文件时，使用 readFile 需要等到整个文件读取完毕才能开始解析内容。而流可以让你在收到第一块数据时就开始处理，数据处理时间和读取时间高度重叠，整体处理速度反而更快。对于 Web 服务的响应而言，用户可以更快地看到第一条处理结果，用户体验更好。
2. 天然避免内存爆炸，适合长时间运行的服务
服务端应用需要长期稳定运行，一次偶然的大文件请求不应该导致整个服务内存耗尽。采用流处理模式，即便同时处理多个大文件，内存占用也可控，服务更容易保持平稳的吞吐量，避免因异常峰值而引发雪崩。
3. 管道式组合，形成数据“生产线”
流可以彼此连接，形成一条处理链。例如：
读取文件流 → 解压转换流 → 加密转换流 → 写入文件流这种管道（pipe）方式不仅代码简洁，而且每道工序之间也是分块处理的：读取到的 chunk 传递给解压，解压后的 chunk 再加密，加密后的数据立刻写入目标文件，全程内存占用与单个 chunk 相关。相较于先把整个文件读到内存 → 解压成更大的内存块 → 加密 → 再写入，流式管道的效率高出不止一个数量级。
const { createReadStream, createWriteStream } = require('fs');
const { createGzip } = require('zlib');
// 管道式处理：读取 → 压缩 → 写入
createReadStream('input.log')
.pipe(createGzip())
.pipe(createWriteStream('input.log.gz'))
.on('finish', () => console.log('压缩完成'));4. 网络场景中的背压控制能力
在网络请求中，流同样能够防止数据接收方被“淹没”。如果服务端向客户端推送一个巨大的文件，而客户端的带宽有限，若一次性把全部数据发给底层 socket，数据会在内核缓冲区堆积，造成内存浪费和传输不稳定。而流天然具备背压（backpressure）机制：当下游的 write 返回 false 时，上级读流会暂停推送，直到下游排空。这让整个数据传输过程变得平滑、可靠。
流的核心价值总结
| 对比维度 | 一次性加载 (readFile) | 流式处理 (createReadStream) |
|----------|-------------------------|----------------------------|
| 内存占用 | 约等于文件大小，大文件直接 OOM | 稳定在几十 KB～几 MB，与文件大小无关 |
| 处理时机 | 读取完毕才能开始处理 | 第一块数据到达即可处理 |
| 并发友好 | 多文件处理会叠加内存，易崩溃 | 每个流只占据少量内存，并发文件数可很高 |
| 编程模式 | 简单（回调中获得完整 Buffer） | 事件驱动，需要处理 data/end/error |
正因如此，流才被设计为 Node.js 的核心抽象之一。在文件系统、网络套接字、数据压缩、加解密、进程通信等几乎所有 I/O 相关的模块中，你都能看到流的影子。所谓“流”，本质上就是一种基于事件的、非阻塞的、分块处理数据的机制，它将成批的数据处理转化为可持续运转的“管道生产线”，使得 Node.js 的高并发 I/O 能力在实践中被具象化、可控制。
理解了流的分块价值之后，下一节我们将系统地介绍 Node.js 中四种流的类型（可读流、可写流、双工流、转换流），以及它们各自的使用方式和典型实现。