Web Streams tee 分流后一个消费者变慢会发生什么

我第一次把一个 Response.body 同时交给页面渲染和缓存逻辑时，直觉是“慢的那支会把快的那支也拖住”。但 ReadableStream.tee() 的实际语义不是这样：它返回两个分支，背压只会部分地按较快消费者传播，慢分支来不及读取的 chunk 会继续留在自己的内部队列里。小响应通常没事，大响应或长期速度不一致时，内存才是需要优先排查的地方。

一个分支慢时，快分支不会自动等它

const [left, right] = stream.tee() 会创建两个新的 ReadableStream，原流本身同时被锁定。两个分支拿到的内容顺序一致，但消费速度可以不同。假设渲染分支每次很快读取，而缓存分支要先写入磁盘或等待网络，那么渲染分支仍可能继续前进。

关键不在于数据是否“丢了”，而在于“还没被慢分支读取的 chunk 放在哪里”。标准语义允许这些数据排在慢分支的内部队列中；当两个分支都有未读数据时，上游控制器的 desiredSize 才会影响继续拉取。因此，tee() 是方便的复制入口，却不是默认有界的广播队列。

用延迟读取示例看出积压发生在哪一支

下面的实验故意让第二个消费者每次多等一段时间。代码只用于复现“两个读取循环速度不同”的结构，输出应结合浏览器的内存面板或你自己的计数器观察，不要把示例中的日志当成固定的浏览器运行结果。

async function readBoth(stream) {
  // tee 会把一个可读流拆成两个独立分支，原流随后不能再直接取 reader。
  const [fastBranch, slowBranch] = stream.tee();

  const consume = async (branch, delay, label) => {
    const reader = branch.getReader();
    try {
      while (true) {
        const { value, done } = await reader.read();
        // done 表示该分支结束；结束后不要再访问 value。
        if (done) break;
        console.log(label, value.byteLength ?? value.length ?? 1);
        // 用延迟模拟缓存写入、解码或慢网络，不代表真实吞吐量。
        if (delay) await new Promise(resolve => setTimeout(resolve, delay));
      }
    } finally {
      // 发生异常或提前退出时释放 reader，避免继续占用分支。
      reader.releaseLock();
    }
  };

  await Promise.all([
    consume(fastBranch, 0, "fast"),
    consume(slowBranch, 200, "slow")
  ]);
}

观察这个结构时，先不要急着调高水位线。快分支的日志先出现，只能说明它读取得更快；慢分支尚未取走的内容仍要由队列保存。若把慢分支完全不启动，积压会更明显，这也是 MDN 特别提醒“大响应不要让两支以明显不同速度并行读取”的原因。

背压、内存增长和取消不是同一件事

可以把几个容易混淆的现象分开看：

desiredSize 能帮助理解队列压力，但它不是一个可以把无限积压自动变成安全上限的开关。尤其是 Response.body 较大、一个分支连到慢速写入端时，浏览器或运行时是否继续从底层拉取，还取决于底层 source 对背压的支持。

怎么选分流方案并复查

如果只是把几十 KB 的响应同时交给渲染和短暂的日志处理，tee() 的简单性通常值得保留。若是下载、视频、长轮询或持续生成内容，我会先问三个问题：第二支是否真的必须存在、两支速度差是否长期存在、能不能接受一个明确的内存上限。

不需要第二支时，直接让唯一消费者读取原流；需要两支但必须同步时，让业务层以较慢端的节奏协调读取；需要异步解耦时，使用带明确最大长度和溢出策略的队列。若要求快端继续前进，同时又不能让慢端无限积压，就应选择或实现会把背压传递到慢端的 fan-out，而不是只把 tee() 外面再套一层无界数组。

最后复查关闭路径：两个分支都完成，或两个分支都被取消；异常不会只停掉快分支而把慢分支留在后台。这样看，问题的答案不是“慢消费者会不会让快消费者变慢”，而是“你的分流策略是否为慢消费者定义了可控的存储和结束方式”。

常见问题

tee() 会丢掉慢分支的数据吗？

正常情况下不会因为速度慢就主动丢弃；未读数据会在慢分支的内部队列中等待。真正的风险是队列增长带来的内存压力。

只读取 tee 返回的第一个分支可以吗？

语义上可以，但没有读取的第二支可能持续积累数据。若不需要第二份内容，直接读取原流更清楚，也避免无意义的缓存。

取消一个分支就能停止原流吗？

不要这样假设。按 Web Streams 的 tee 语义，业务应分别处理两个分支的取消与异常，并确认底层资源最终结束。