反压布尔值才是机制，而非流本身

Node.js 流携带着一个反压信号——.write() 返回的布尔值——而生产环境中绝大多数代码从不读取它。Master.dev 那篇关于 Node.js 流内存泄漏的文章走查了后果：Pod 内存爬升到 3.8GB 后被 OOM 杀掉，因为一个 transform 对每一行都调用 .write()，却忽略了那个请求它减速的 false（Master.dev，《Your Node.js Streams Aren't Backpressuring. They're Silently Eating Your Memory.》，2026）。这不是运行时的 bug。这是正确的行为，由一段从未测量那个本能让属性成立的信号的代码执行出来。

这就是全部的故事，也是我们在 Everythink 反复讲述的故事：一个属性，当且仅当其机制被实现并被测量时，才得到保证。反压布尔值是机制。那个从不检查它的 for await 循环，是缺失的测量。有界内存不是流的特性；它是一种从某个协议中涌现的属性，而这个协议需要有人去遵守。

信号存在。没人读取它。

Master.dev 的文章把这次泄漏框定为两个心智模型之间的鸿沟：教程版（“流逐块处理数据，所以你永远不会把整个文件载入内存”）与运营现实版（“流给你保护自己的工具；它并不保护你”）。作者对运行时做什么、不做什么非常精确：当生产者忽略反压时，Node.js 不会抛异常、不会暂停、不会杀死流。它继续接受数据，继续分配堆，继续前进，直到 V8 用尽空间。

这正是通过抽象接触到流的工程师感到意外的部分。抽象宣告了一项保证——“你永远不会把整个文件载入内存”——却把维持它的工作悄悄甩给一个 API 并不强制你读取的布尔值。highWaterMark 不是限制。它是 .write() 返回 false 的阈值。没有异常，没有自动暂停，没有断路器。文章展示的四行修复——检查返回值，若为假则 await once(writable, "drain")——就是整个模式，而它的缺失就是整个泄漏。

[PERSONAL EXPERIENCE] 过去两年我在三个不同的代码库中读到过这个一模一样的 bug，三次里作者都写了一个干净的 for await...of 循环，通过了代码评审，并发布到了生产环境。代码看起来是对的，因为语法很现代。泄漏不在任何一行里；它存在于两行之间——那个返回了 false 的 .write() 和从未等待的下一轮迭代。

Theorem 3，应用于一个布尔值

在 Everythink，我们在 the 21 papers 中贯穿一个形式化主张，而它正是这次泄漏最清晰地阐明的主张：一个属性，当且仅当其机制被实现并被测量时，才得到保证。“并被测量”是承重的那一半。一个只存在于纸面、却从不在循环中被观测的机制，就保证而言，等于不存在。

反压是经典案例。机制在 Node.js 核心中是存在的——.write() 返回布尔值，drain 触发，writableNeedDrain 翻转。协议的每一块都已实现。缺失的是测量：那个读取布尔值并决定等待的分支。没有这个分支，“流式负载下有界内存”这一属性并未得到保证——它只是被容忍，直到负载超过容器所能容忍的限度。

正因如此，我们对任何只点名机制却不点名测量的能力声明都保持怀疑。“我们有流”并不是关于有界内存的声明。“我们在每条写入路径上检查布尔值并等待 drain”才是。HAI Engine ✅ 自 2016 年在生产中运行，依赖的正是这一纪律：决定哪个 Sister 去想象、哪个 Oracle 去合并、foresight 落在哪个 room 的路由层，是一个被测量的机制，而非一张架构图。The space is the router——network → community → room——而路由发生在任何东西响应之前，每一个跳点都带有反压式的纪律。

Node.js 22 的乘数，以及为何默认值不是安全

Master.dev 的文章指出了一个让静默泄漏加速的变更：在 Node.js 22 中，默认 highWaterMark 从 16KB 提升到 64KB（Robert Nagy 的 PR #52037）。这一变更站得住脚——更少的上下文切换，在大负载上更好的吞吐——同时它也把第一个反压信号触发前累积的缓冲区放大了 4 倍。在一个 256MB 或 512MB 的容器里，这个乘数就是垃圾回收几乎追得上的缓慢爬升与追不上的快速爬升之间的差别。

[UNIQUE INSIGHT] 提升吞吐的默认值正在悄悄重新分配一种有限资源——你容器的内存——却不告诉你。让 happy path 更快的同一版本，也让 unhappy path 更早崩溃。没有一条发布说明会写“你的 OOM 阈值现在近了 4 倍”，因为运行时根本不知道你容器的上限。运维知道。这是一种通用模式，不是 Node.js 的怪癖：任何替你缓冲的抽象都在花一种它看不见的资源。

文章给出的修复是一件钝器——setDefaultHighWaterMark(false, 16 * 1024) 全局回退——和一件手术刀——对关键的流单独设置 highWaterMark。两者都对。两者都不是重点。重点是默认值移动了，几乎没人把发布说明拿来对照自己的容器预算读，而那个一直在的泄漏多了 4 倍的空间去生长，才被注意到。默认值不是安全。被测量的机制才是安全。

objectMode 与双面 Transform

Master.dev 文章里有两处褶皱值得强调，因为它们击碎了开发者仅存的直觉。

第一，objectMode 流不数字节。它数对象。highWaterMark 为 16 意味着 16 个对象被缓冲，如果每个对象是 50KB 的联结 JSON 行，“16”这个标签在第一个信号触发前每条流携带的是 800KB。表盘上的数字不是堆里的数字。

第二，Transform 流有两个独立的 highWaterMark 设置——写侧一个，读侧一个——它们可以不一致。一个 Transform 可以在读侧完美遵守反压（等待 HTTP 响应排空），同时在写侧盲目接受数据，因为它自己的内部对象队列还没到上限。文章把这叫做“一个为了吸收压力而展开的手风琴，把问题掩盖到它自己的缓冲区爆掉为止”。修复是显式设定非对称限制——一个小的写侧 highWaterMark，以便下游缓冲区一满就把反压推向上游。

这正是 Theorem 3 不断教导的同一课：一半接好的机制等于一半缺失。一个只在一边遵守反压的 Transform 只有半个协议。属性——端到端有界内存——要求两半都被测量，在数据穿越系统的每条路径上。

pipe() 是语法；pipeline() 才是机制

文章关于 .pipe() 与 pipeline() 的章节，是对流畅抽象与真正机制之间差别最干净的陈述。.pipe() 不传播错误。如果管道链中间的某个 transform 抛异常，源继续读，目的地保持打开，文件描述符泄漏，套接字挂起，你得不到任何东西坏了的迹象。链式语法——readStream.pipe(transformStream).pipe(writeStream)——读起来像 Unix 管道，却把灾难性缺陷藏在漂亮语法背后。

来自 node:stream/promises 的 pipeline()，在任一失败时销毁链上每个流，并把错误作为被拒绝的 promise 传播。它成为标准已超过五年。文章的规则很锋利：如果你的 .pipe() 链超过两个流，或任何流可能出错，你就在承担一个 pipeline() 免费消除的风险。

这映射到我们自己在栈中执行的更广泛习惯。仓库的不变量是显式的：持久化总是通过一个 port（trait）到达，从不通过具体的 Pg* 适配器；AppState 仓库是 Arc<dyn Trait> 以便测试注入 mock；Sisters 从不写 Postgres，它们返回 SisterOutput，由 Loom 持久化。每一条都是 pipeline() 形的规则——让失败模式结构上不可达的机制，而非要求开发者记住的约定。我们不依赖开发者记得清理文件描述符。我们让类型系统强制：持久化的唯一途径是通过一个会处理清理的 port。

async/await 调度读，不调度写

在我看来，文章中最危险的模式，是看起来最现代的那个：

for await (const chunk of readable) {
  writable.write(chunk);
}

异步迭代器控制你读得多快。它对你写得多快无所作为。如果 writable.write() 返回 false，循环不暂停——它抓起下一块塞进一个已经满的缓冲区。修复还是那四行：检查布尔值，若为假则 await once(writable, "drain")。这单独一个 await 做两件事——它暂停循环，进而暂停迭代器，进而阻止 readable 拉数据；它还把执行让给事件循环，这才让 I/O 回调得以触发并最终 emit drain。没有这次让步，for 循环会独占当前 tick，drain 永远无法触发。

文章的总结句很精确：“Promises manage when your code runs. Backpressure manages how much data accumulates. async/await only solves one of them.” 我会加上 Theorem 3 的推论：一种只调度协议一半的现代语法，是一个只被测量了一半的机制。另一半仍须手工接线，而现代语法让人更容易忘记接线是缺失的。

暂停的隐含代价：连接饥饿

文章的最后一个动作，是大多数“反压已解决”文章跳过的那个。一旦你尊重布尔值并等待 drain，内存变平——压力向上游转移到你的数据库连接池。一个暂停的 Node.js 流保持其数据库游标打开。如果下游客户端在不稳定的 3G 上、花五分钟排空，你池里的一个 worker 就被占用五分钟。一个 20 的池在 20 个缓慢的大导出下就饱和了。内存是平的；应用停止服务新请求；健康检查失败；负载均衡器把流量转到其他 pod，后者达到自己的池上限。级联失败与内存无关，而与一种你忘了保护的有限资源有关。

文章给出的修复是三个架构动作，不是代码改动：严格的查询超时、为重型导出准备的专用 worker 池、以及基于队列把数据卸到对象存储并用预签名 URL。重点是：修复本地机制（检查布尔值）会暴露栈上的下一个机制（池），它同样必须被测量与限定。反压不是本地属性。它是一条链，每个环节都有自己的表。

这就是我们在 Everythink 跨栈应用的纪律。World Monitor ✅（Atlas）网关把每个上游 geo feed 通过一个有界的 poller 路由，固定调度、每源 token bucket 预算，归一化为 GeoSignal，并 upsert 进一个持久的 Postgres 缓存。客户端读缓存，从不读上游——上游调用量由我们的调度限定，而非客户端数量。这是同一形态：一种有限资源（上游 API 预算）由一个被测量的机制（poller 的调度与预算）保护，而非靠客户端自觉。Sisters → Oracle ✅ 路径又是同一形态：每个 Sister 的 imagine() 输出由 Loom 强制的协议限定；Oracle 的 merge() 在唯一一处归一化概率，使消费者可以依赖 sum(probability) ≈ 1.0。机制，被测量，在一处。

[ORIGINAL DATA] 在我们审阅过的、涉及流式导出的每份事故复盘里，根因从来不是“我们没有流”。而是“读取布尔值的那个分支不在写入路径上”。机制在场；测量缺失。这就是一个跑在 80MB 的服务与一个爬到 3.8GB 被杀的服务之间的全部差值。

关键要点

• 流不是有界内存的保证。 它是一个带信号——.write() 布尔值——的协作协议，消费者必须去读它。Master.dev 文章把生产 OOM kill 追溯到从不读它的代码。
• Theorem 3 直接适用。 一个属性当且仅当其机制被实现并被测量时才得到保证。反压机制在 Node.js 核心中已实现；测量（检查布尔值的那个分支）是团队省略的部分。没有测量，属性不被保证——它被容忍。
• 默认值在你不知情时移动。 Node.js 22 对 highWaterMark 的 4 倍提升是吞吐的胜利，也是更安静、更快的泄漏。替你缓冲的默认值在花一种它们看不见的资源（你容器的内存）。
• 半个协议等于半个缺失。 一个只在一侧遵守反压的 Transform，或一个只调度读不调度写的 async 循环，是一个只接了一半的机制。属性要求两半都被测量。
• 修好本地泄漏会暴露下一个。 尊重反压把压力向上游推进你的连接池。反压是一条链；每个环节都需要自己的表。文章的三项修复（超时、专用池、队列卸载）是架构性的，不是语法性的。

常见问题

我用 .pipe() 时 Node.js 不是自动处理反压吗？ 对于简单的两流管道，大致是——当 writable 的缓冲区满时，.pipe() 暂停 readable。Master.dev 文章的要点是，一旦你加入一个 transform、一个网络套接字或任何错误路径，.pipe() 就停止传播错误并开始泄漏文件描述符。用 node:stream/promises 的 pipeline()；它已是超过五年的标准。

highWaterMark 是内存限制吗？ 不是。它是一个建议性阈值。缓冲区达到它时，.write() 返回 false。没有异常、没有自动暂停、没有断路器。如果你忽略 false，Node.js 会持续缓冲直到进程死亡。在 objectMode 下，数字数的是对象而非字节——16 可以是 800KB 的联结 JSON。

我用 for await...of 就安全了吗？ 只在读侧。异步迭代器调度你从 readable 拉取的速度。它对写入速度无所作为。你仍需检查 .write() 返回值，并在为 false 时 await once(writable, "drain")。文章的句子：“Promises manage when your code runs. Backpressure manages how much data accumulates.”

这和预测基础设施有什么关系？ 同一纪律。一个属性——有界内存、校准概率、隔离路由——只有在其机制被实现并被测量时才得到保证。在 Everythink，“the space is the router”意味着 network → community → room 拓扑在任何东西响应之前就路由，每个跳点都有自己的表。HAI Engine 自 2016 年就在这条纪律下运行。

连接饥饿真的和内存泄漏是分开的吗？ 是的，文章对这一权衡很诚实。尊重反压让内存变平，并把压力推进你的数据库池。一个 20 的池在 20 个慢导出下就饱和。修复是架构性的——超时、专用池、队列卸载——而不是流里的代码改动。

阅读 the 21 papers——该系列把 Theorem 3 与这次泄漏所阐明的“被测量的机制”纪律形式化。

Sources

• Master.dev, "Your Node.js Streams Aren't Backpressuring. They're Silently Eating Your Memory."（Durgesh Rajubhai Pawar，2026 年 5 月 25 日）— https://master.dev/blog/your-node-js-streams-arent-backpressuring-theyre-silently-eating-your-memory/