7.3 背压（Backpressure）产生原因与自动调控机制

在 7.1 和 7.2 节中我们了解了流的核心价值与四种类型，它们让 Node.js 能够以极低的内存开销处理大文件或连续数据。但如果生产数据的速度远大于消费数据的速度，而没有任何调控机制，内存中就会堆积大量待处理的缓冲数据，最终导致进程崩溃。Node.js 对流数据传输内置了一套自动调速机制——背压，它就像水管中的水龙头：当下游来不及处理时，上游自动放缓甚至暂停供水，等到下游疏通后再继续。

7.3.1 为什么会发生背压？

流处理数据的典型模式是：可读流读出一块数据，通过 'data' 事件或 read() 方法传递给可写流，可写流调用底层系统（如文件系统、网络 socket）将数据写入目标。问题在于，这两个步骤的速度往往是不匹配的。

最常见的例子是用 fs.createReadStream 读取一个大文件，然后通过一个网络响应（如 HTTP 的 res 可写流）传回客户端。硬盘读取速度（数百 MB/s）通常远快于客户端下载带宽（几 MB/s）。如果读取数据不加以限制，可写流的内部缓冲区会迅速被填满，内存占用持续走高，直到所有数据都读入内存等待发送——这不仅违背了流“分块处理”的初衷，甚至可能直接撑爆进程。

在 Node.js 的流实现中，每个可写流都有一个内部缓冲区（大小由 highWaterMark 选项控制，默认为 16KB）。当向流写入数据时，如果缓冲区的长度超过了 highWaterMark，write() 方法就会返回 false，向生产者发出信号：“我已经塞满了，先别写了”。这就是背压的最直观体现。

7.3.2 自动调控机制：`pipe()` 的内部魔法

如果你使用流的 pipe() 方法连接可读流和可写流，背压的调控是完全自动的，不需要任何额外代码。pipe() 的内部逻辑十分精妙：

可读流开始向可写流输送数据，每次调用 writable.write(chunk)。
如果 writable.write() 返回 false（缓冲区已满），pipe() 会立即调用 readable.pause() 暂停可读流，停止数据生产。
当可写流的缓冲区被逐渐消耗完毕，会触发 'drain' 事件。pipe() 监听到这个事件后，调用 readable.resume() 恢复可读流，继续提供数据。

整个过程像自动阀门一样，在水池（缓冲区）快满时关闸，在水位下降后开闸，始终保持内存中的缓存量可控。

下面的例子展示了 pipe() 自动处理背压的效果，即使是几 GB 的文件传输，内存占用也只会维持在 16KB 左右的缓存区大小：

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

http.createServer((req, res) => {
  // 创建可读流
  const readStream = fs.createReadStream('/path/to/largefile.mp4');
  // 管道自动处理背压，不会吃爆内存
  readStream.pipe(res);
}).listen(3000);

7.3.3 不借助 `pipe()` 时的手动背压控制

有时你需要更精细地控制数据流，比如在每一块数据写入后进行某些处理，或者使用双工流、转换流，无法直接 pipe()。这时就需要手动编写背压处理逻辑，但原理与 pipe() 一致：

const fs = require('fs');
const writable = fs.createWriteStream('output.txt');
const readable = fs.createReadStream('input.txt');

// 监听 data 事件获取数据
readable.on('data', (chunk) => {
  // 调用 write 并检查返回值
  const canContinue = writable.write(chunk);
  if (!canContinue) {
    // 如果 write 返回 false，暂停可读流
    readable.pause();
    console.log('写缓冲区已满，暂停读取');
  }
});

// 当可写流缓冲区排空，触发 drain 事件
writable.on('drain', () => {
  console.log('缓冲区已排空，恢复读取');
  readable.resume();
});

readable.on('end', () => {
  writable.end();
});

这里通过检查 write() 返回值来控制可读流的启动与暂停，利用 drain 事件恢复，完全复现了 pipe() 的背压逻辑。实际生产中，如果不使用 pipe()，几乎一定会写这套控制代码，否则很容易出现内存泄漏或写入乱序。

7.3.4 背压不只影响内存，还影响吞吐量

正确实现背压机制不仅保护了进程内存，也间接提升了系统的吞吐效率。如果没有背压控制，数据在缓冲区内堆积，可写流的底层操作会因为大量并发写入而变得低效，甚至触发 TCP 拥塞控制等低层负反馈。适时的暂停与恢复可以让下游以稳定的节奏消费数据，减少系统调用次数，整体性能反而更优。

7.3.5 常见错误与调试信号

很多开发者在第一次接触流时，会犯两个典型错误：

只监听 data 事件而不暂停可读流：当可写流来不及消费，缓冲区持续增长，最终报 ERRSIZE 或内存耗尽。解决办法永远是检查 write() 的返回值并进行 pause()/resume()。
在可写流 finish 或 end 后继续写入：如果流已经结束，继续 write() 会出错。需要确保数据流控制的完整性，通常在 end 事件中执行最终清理。

调试时，可以监听一些关键的生命周期事件来观察背压情况：

writable.on('drain', () => console.log('可写流排空'));
readable.on('pause', () => console.log('可读流暂停'));
readable.on('resume', () => console.log('可读流恢复'));

通过这些日志，可以直观看到背压的调节节奏。

7.3.6 高性能场景下的 `highWaterMark` 调整

默认的 highWaterMark 值（可读流 64KB，可写流 16KB）适合大多数场景，但在特定环境中可以调整以获得更好性能：

处理较大文件且 I/O 性能很高时，适当增大 highWaterMark（如 256KB 或 1MB）可以减少 drain/pause 的切换次数，提高吞吐量。
在内存敏感或低速网络环境中，降低 highWaterMark 可以进一步压低内存占用峰值。

调整方式只需在创建流时传入 options：

const readStream = fs.createReadStream('big.iso', { highWaterMark: 256 * 1024 });

但盲目的增大并不可取，必须结合实际文件大小、可用内存和下游处理速度进行测试验证。

7.3.7 小结

背压是流处理中最重要却容易被忽视的机制。它本质上是一种生产者-消费者之间的反馈信号，保证高速数据流不会淹没低速处理器。pipe() 把这一切透明化了，使得大文件传输如同呼吸一般稳定。在更复杂的流组合中，手动处理背压只要遵循“write 返回 false 时暂停，drain 时恢复”的原则，就能写出高性能且健壮的流处理代码。

掌握了背压，才能真正驾驭 Node.js 的流式处理能力，避免内存峰值失控，让应用平稳服务于生产环境。