各位同学，大家好。
今天我们不谈那些虚无缥缈的架构设计，也不聊那些没用的后端微服务。我们今天要聊的是所有程序员最痛、最恨，却又不得不面对的一个物理现实——网络带宽。
想象一下，你在一个信号只有两格的 3G 网络下，试图打开一个现代化的 React 单页应用（SPA）。你看到了那个令人心碎的旋转圆圈，那一刻，你的内心是崩塌的。这就是所谓的“长任务”。浏览器在等待整个 HTML 文件下载完毕，解析完毕，编译完毕，然后才把第一行文字渲染到屏幕上。
这时候，一位资深专家——也就是我——拿着一个扳手走了过来。我告诉你：“嘿，别等了。为什么要把整锅汤煮好了才端上桌？我们可以先把汤倒进碗里，再倒进盘子里，让客人先喝一口。”
这就是我们今天的主题：React 流式渲染与 Express 响应流：在低带宽环境下的“分片”生存指南。
我们将深入探讨如何利用 React 的流式能力，配合 Express 的响应管道，在这个充满丢包和延迟的互联网丛林中，像玩俄罗斯方块一样，把数据一块一块地塞进用户的浏览器，哪怕网速只有 5KB/s。
准备好了吗？让我们把连接插上。
第一部分：传统的等待艺术（以及为什么它很烂）
在 React 18 之前，我们在服务端渲染（SSR）或者使用 ReactDOMServer.renderToString 时，基本上是在玩“一次性吐出”。React 会生成一个巨大的 HTML 字符串，就像是你把一整座山炸成粉末，然后打包成一个巨大的包裹，扔给 Express。
Express 收到包裹，把它塞进 HTTP 响应流，然后开始发送。如果包裹太重，网络太慢，用户的屏幕就会长时间处于一片空白，直到那几百 KB 的 HTML 数据终于爬过光纤，钻进浏览器的缓存。
这就好比你去吃自助餐，你走进去，服务员把你锁在厨房里，直到把整个后厨的菜都给你端上来，你才能吃一口。这简直是犯罪。
CLS (Cumulative Layout Shift)，也就是累积布局偏移，就是拜这种延迟所赐。用户看到页面一闪一闪，因为浏览器在解析 DOM，最后才把布局定下来。
所以，我们需要改变策略。我们要流式。
第二部分：React 的流式渲染（那是水管，不是蓄水池）
React 18 引入了 renderToPipeableStream（以及 renderToReadableStream）。这是一个巨大的突破。
当你调用这个函数时，React 不会一次性吐出整个 HTML。它开始生成一个可读流（Readable Stream）。这个流就像是一条不断涌出的水管。
ReadableStream 接口的工作原理是这样的：它内部有一个生产者（React），不断产出“数据块”，还有一个消费者（Express 的 res）。React 喷出来一块 HTML，Express 就收进去一块，然后通过 HTTP 发送给浏览器。
这有什么好处？浏览器开始下载 HTML 的第一块数据，立刻就能解析出 <html> 和 <head>，然后开始解析 <body> 里的第一个 <h1>。用户不需要等待整个文件下载完毕，就能看到文字闪烁出来。
代码示例 1：最基础的 React 流式渲染
// server.js
import React from 'react';
import ReactDOMServer from 'react-dom/server';
import fs from 'fs';
import path from 'path';
import App from './App';
const handleRequest = async (req, res) => {
// 这里的 renderToPipeableStream 返回一个 pipeable stream
// 它会源源不断地吐出 HTML 片段
const { pipe } = ReactDOMServer.renderToPipeableStream(
<App />,
{
// 这是一个回调，当流开始发送数据时触发
onShellReady() {
// shell 准备好了，发送 HTTP 200 和头部
res.statusCode = 200;
res.setHeader('Content-type', 'text/html');
// 关键一步：把 React 的流直接 pipe 到 Express 的响应流
// 注意：这里我们还没压缩！
pipe(res);
},
onShellError(error) {
res.statusCode = 500;
res.send('<!doctype html><p>Error loading app.</p>');
}
}
);
};
// 在 Express 中使用
import express from 'express';
const app = express();
// 这里我们暂时忽略静态文件，直接处理这个路由
app.get('*', async (req, res) => {
await handleRequest(req, res);
});
app.listen(3000);看，上面的代码很简单。但是，问题来了。
第三部分：Express 的“缓冲区”与“肠梗阻”
如果你直接在代码示例 1 里运行这个，你会发现，在低带宽环境下，效果并没有你想象的那么好。
为什么？
因为 Express 的 res（响应对象）背后，有一个叫 Node.js 模块 Buffer 的东西在守着。Express 并不是每收到一个字节就立刻通过 TCP socket 发出去的。为了提高效率，它会攒够一定量的数据，或者攒够一定的时间（通常是 16KB 或 250ms），才调用底层的 socket.write()。
如果你在一个只有 5KB/s 的网络下，React 流式渲染每 16ms 就生成了一小块数据（比如 1KB）。这些数据会进入 Express 的缓冲区。Express 在缓冲区攒满了，才会发一次。这意味着，用户浏览器接收到的数据间隔是不均匀的。有时候，它会收到一大块，然后卡顿半天。
这就导致了“丢包”和“延迟抖动”。
我们需要在 Express 和 React 之间做一个中间层，或者说一个调节阀。这个调节阀的作用就是分片。
我们要把 React 那源源不断的水流，切割成更小的、更符合 TCP 窗口大小的水滴。
第四部分：分片策略（那把扳手）
分片策略不仅仅是把一个大文件切成小文件，它涉及到两个层面：
- 渲染层面的分片： React 生成 HTML 的粒度。
- 传输层面的分片： Express 发送数据的粒度。
4.1 渲染层面的分片
React 18 的 renderToPipeableStream 默认是按“文本片段”分片的。它会尽力快。但有时候，为了性能优化，我们需要手动干预。
4.2 传输层面的分片（核心）
我们需要拦截 React 的流，把它变成更细的流。
Node.js 提供了 pipeline 函数，以及 stream 模块。我们需要创建一个自定义的“分割器”流。
策略核心思想：
不要让所有数据都堆在 Express 的内存缓冲区。当 React 喷出 10KB 数据时，我们不要等它攒够 16KB 再发。我们利用 Node.js 的 setImmediate 或者 process.nextTick，强制让 Express 尽快发送当前已经收到的数据。
代码示例 2：自定义的“急躁”流式传输中间件
import stream from 'stream';
import { pipeline } from 'stream/promises';
// 这是一个自定义的可读流，它会从源流中读取数据，
// 但是每次只读出一小块，并立即通过管道转发，而不是攒一大包
class TinyChunkStream extends stream.Readable {
constructor(sourceStream, chunkSize = 1024) {
super({ objectMode: true });
this.sourceStream = sourceStream;
this.chunkSize = chunkSize;
this.paused = false;
}
_read(size) {
// 如果源流已经结束，发一个结束信号
if (this.sourceStream.destroyed) {
this.push(null);
return;
}
if (this.sourceStream.readableEnded) {
this.push(null);
return;
}
// 暂停源流，防止它继续生产数据堆积在我们的缓冲区
this.sourceStream.pause();
// 立即读取一小块数据
const chunk = this.sourceStream.read(this.chunkSize);
if (chunk !== null) {
// 如果读到了数据，立即推送到我们的输出流
this.push(chunk);
// 然后立即恢复源流的读取，形成循环
this.sourceStream.resume();
} else {
// 如果源流没有数据可读（通常是源流内部缓冲区空了但还没结束）
// 我们稍微等一下（可选），或者如果源流已经结束，我们就结束
if (this.sourceStream.readableEnded) {
this.push(null);
} else {
// 监听下一次可读事件
this.sourceStream.once('readable', () => this._read());
}
}
}
}
// 这是我们的“流量控制”函数
async function streamWithManualChunks(res, reactStream) {
const transformer = new TinyChunkStream(reactStream, 2048); // 每次只取 2KB
// 响应头
res.setHeader('Content-type', 'text/html');
try {
// 使用 pipeline 确保错误能正确传递
await pipeline(
transformer,
res, // Express 的响应流
(err) => {
if (err) console.error('Pipeline failed:', err);
}
);
} catch (err) {
console.error('Stream error:', err);
if (!res.headersSent) {
res.statusCode = 500;
res.end('Internal Server Error');
}
}
}代码解析：
上面的代码有点绕，我们来理一理。
- 我们创建了一个
TinyChunkStream。 - 当你调用
sourceStream.read(2048)时，React 流只会吐出 2KB 的数据。 - 我们把这个 2KB 推给
res。 - 然后我们马上
sourceStream.resume()，告诉 React：“别停，再吐一点。” - 我们重复这个过程。
这就像是一个交通协管员。以前是车流（React）直接冲进高速公路（Express），现在协管员拦住车流，一辆一辆（分片）地放行。
注意： 在这个简单的实现中，我们忽略了 gzip 压缩。压缩通常需要看到整个数据块才能有效地压缩，如果我们强制 2KB 就发一次，压缩率会大幅下降。所以我们通常会在分片流之后，或者之前，加上压缩层。
第五部分：HTTP 转码流与压缩
现在，我们有了分片，但在低带宽下，数据量还是太大了。HTML 文件即使被压缩了，通常也有几百 KB。
我们需要“转码”。这里的“转码”不是把视频转码，而是把文本流压缩。
HTTP 支持几种压缩算法：gzip, deflate, br (Brotli)。Brotli 是目前效率最高的，但 CPU 消耗也大。
策略：流式压缩
你不能把整个 HTML 读入内存再压缩。你必须利用 Node.js 的 zlib 模块。
代码示例 3：流式压缩 + 分片
import { createGzip } from 'zlib';
import { pipeline } from 'stream/promises';
async function streamWithCompression(res, reactStream) {
// 1. 设置响应头
res.setHeader('Content-Encoding', 'gzip');
res.setHeader('Content-Type', 'text/html');
// 2. 创建压缩流
const gzip = createGzip();
try {
// 3. 管道连接：
// React 流 -> 压缩流 -> Express 响应流
await pipeline(
reactStream,
gzip,
res
);
} catch (err) {
console.error('Compression pipeline failed:', err);
if (!res.headersSent) {
res.statusCode = 500;
res.end('Internal Server Error');
}
}
}批评： 上面的代码其实非常常见。但回到我们的低带宽痛点，压缩流也是有缓冲区的。createGzip 内部维护着一个滑动窗口。如果 React 流的输出速度（比如 100MB/s）远快于压缩速度（比如 50MB/s），压缩流可能会积压数据。
怎么办？
我们需要在压缩流和 Express 响应流之间，再插入一个缓冲控制流。这就回到了我们在示例 2 中写的 TinyChunkStream，只不过这次我们的目标对象是 gzip，而不是 res。
代码示例 4：终极版的流式渲染中间件
这是一个综合了 React 流、手动分片、压缩控制的完整解决方案。
import stream from 'stream';
import { pipeline } from 'stream/promises';
import { createGzip } from 'zlib';
class ChunkingTransformStream extends stream.Transform {
constructor(options) {
super({ ...options, objectMode: false }); // 必须是 false，因为我们处理的是二进制 Buffer
this.chunkSize = options.chunkSize || 8192; // 默认 8KB
}
_transform(chunk, encoding, callback) {
// 我们把这一块 chunk 切分成多个小 packet
let offset = 0;
const len = chunk.length;
// 这是一个闭包，用于处理当前 chunk 的切片
const processChunk = () => {
if (offset >= len) {
// 当前 chunk 处理完了
callback();
return;
}
const end = Math.min(offset + this.chunkSize, len);
const subChunk = chunk.slice(offset, end);
// 关键点：push 到下一级流
this.push(subChunk);
offset = end;
// 每次只推出去一部分，让 Node.js 的事件循环有机会处理其他任务
// 这防止了阻塞，也实现了更细粒度的分片
setImmediate(processChunk);
};
processChunk();
}
}
async function handleStreamingRequest(req, res) {
// 1. 准备 React 流
const reactStream = ReactDOMServer.renderToPipeableStream(
<App />,
{
onShellReady() {
// 2. 创建压缩流
const gzip = createGzip();
// 3. 创建手动分片流
// 这里我们设置 4KB 的切片，这是针对低带宽优化的
const chunker = new ChunkingTransformStream({ chunkSize: 4096 });
res.setHeader('Content-Encoding', 'gzip');
res.setHeader('Content-Type', 'text/html');
// 4. 拼接管道
// React -> Chunker -> Gzip -> Express
pipeline(
reactStream,
chunker,
gzip,
res
).catch(err => {
console.error('Pipeline failed:', err);
if (!res.headersSent) {
res.statusCode = 500;
res.end('Server Error');
}
});
}
}
);
}第六部分：深入解析分片策略（那些坑）
在上面的代码中，我设置了 chunkSize: 4096 (4KB)。为什么不是 1KB？为什么不是 100KB？
这需要根据你的具体网络环境和 React 组件特性来调整。这是一个玄学，也是一门艺术。
6.1 粒度的选择
- 太细（1KB – 2KB）：
- 优点： 极低的延迟，浏览器能极快地开始渲染文本。适合长文本内容，比如小说或日志。
- 缺点： HTTP 头部开销变大（虽然对于连接复用来说可以忽略）。最重要的是，CPU 压力激增。你的 Node.js 服务器需要为每一个 1KB 的包创建新的 Buffer 分配和内存拷贝。如果你的 CPU 已经是瓶颈（比如 1 个核心在跑），这会直接导致响应变慢，甚至崩溃。
- 太粗（16KB – 64KB）：
- 优点： 减少了系统调用次数，减少了内存拷贝，CPU 效率最高。
- 缺点： 在慢速网络下，用户可能要等很久才能看到第一屏。
- 黄金分割点：
- 通常 8KB – 16KB 是一个比较稳健的选择。
- 但在“低带宽环境”下，我建议 4KB – 8KB。这能提供足够的刷新率，又不会让 CPU 晕头转向。
6.2 水合（Hydration）的挑战
当你开始流式渲染，数据流是乱序到达的。浏览器解析完 HTML 1，然后解析 HTML 2，然后解析 HTML 3。
React 需要做“水合”。它要把这些 HTML 节点变成可交互的组件。
如果 React 收到了 HTML 1，它尝试水合，但是发现 HTML 2 还没到（网络慢），React 就会报错或者处于一种不稳定状态。这被称为“Hydration Mismatch”。
为了解决这个问题，React 提供了 <Suspense> 组件。
策略：使用 Suspense 进行流式保护
在你的 React 组件树中，把那些重计算、重渲染的部分包裹在 <Suspense fallback={<Loading />}> 中。
当网络慢，React 还在生成 <Suspense> 后面的代码时，它先把这个 <Suspense> 的 fallback（通常是简单的 Loading Spinner）直接渲染并流式发送出去。
代码示例 5：利用 Suspense 进行“异步优先”渲染
// App.js
import React, { Suspense } from 'react';
// 这是一个模拟的异步组件，比如获取用户数据
const UserProfile = React.lazy(() => import('./UserProfile'));
export default function App() {
return (
<html lang="en">
<head>
<title>Streaming React App</title>
</head>
<body>
<h1>欢迎来到流式世界</h1>
{/* 这里是流式渲染的关键 */}
{/* React 会先流式渲染 h1，然后遇到 Suspense */}
{/* 如果网络慢，UserProfile 还没加载完，React 会先把 <Suspense> 的 fallback (这里假设是 div) 发出去 */}
<Suspense fallback={<div style={{color: 'red'}}>Loading User...</div>}>
<UserProfile />
</Suspense>
<p>这是页面底部的内容，它也会随着流式传输慢慢显示。</p>
</body>
</html>
);
}这样，即使网络慢得像蜗牛爬，用户也能立刻看到 “欢迎来到流式世界” 和红色的 “Loading User…”。他们知道自己正在加载，而不是页面卡死了。这种反馈感对于用户体验的提升是巨大的。
第七部分：Express 的其他优化技巧
除了流式处理，在 Express 中还有一些骚操作能让低带宽下的传输更稳。
7.1 调整 sendTimeout 和 timeout
默认情况下，如果客户端不活跃，Express 会断开连接。在流式传输中，客户端一直在接收数据，所以 timeout 不会触发。但是，如果客户端断网了，Node.js 的底层 socket 可能会挂起，占用资源。
你可以设置一个合理的超时时间，比如 5 分钟。
app.use((req, res, next) => {
// 允许流式传输更长时间
res.setTimeout(300000); // 5 分钟
next();
});7.2 启用 HTTP/2
这是终极的带宽优化手段。HTTP/2 支持多路复用。你不需要为每一个小的 HTML 片段都建立一个新的 TCP 连接，也不需要担心 Header 开销。所有的数据流都在一个 TCP 连接上并发传输。
如果你的 Express 服务器支持 HTTP/2（使用 spdy 或 http2-express-bridge），那么你上面的流式代码完全不需要改动，性能会直接翻倍。
但请注意，HTTP/2 的头部压缩（HPACK）也是需要一定的内存开销的。
第八部分：故障排查（当水管爆了怎么办）
在构建这套流式系统时，你会遇到很多奇怪的问题。
问题 1：浏览器一直显示白屏，没有文字。
- 原因： React 流式渲染出错，或者压缩流出错。
- 排查： 检查服务端日志，看
onShellError是否被触发。在浏览器 DevTools 的 Network 面板，查看响应状态码是否 200，Content-Encoding 是否正确设置。
问题 2：页面闪烁。
- 原因： React 水合时，旧的 HTML（可能是浏览器缓存的）和新的流式 HTML 不匹配。
- 排查： 确保你的 CSS 在
<head>中，并且尽早发送。使用<style>标签内联关键 CSS，防止 CSS 下载阻塞 HTML 渲染。
问题 3：内存溢出（OOM）。
- 原因： React 生成的流速度太慢（比如组件里有个死循环），而缓冲区一直在积压数据。
- 排查： 在生产环境中，使用
AbortController来取消那些生成过慢的流。如果 5 秒内还没生成完第一屏，就放弃，直接返回一个简单的 HTML 骨架，或者回退到 CSR（客户端渲染）。
结语：拥抱不确定性
好了，同学们，今天的讲座就到这里。
我们探讨了如何通过 React 的 renderToPipeableStream 拿起水管，如何通过 Express 的 res.pipe 把水送出去，以及如何通过自定义的 ChunkingTransformStream 把水切割成滴滴答答的小水滴，去适应那些贫瘠的土地。
流式渲染不是银弹。它增加了代码的复杂度，增加了调试的难度，要求我们更深刻地理解 Node.js 的 Event Loop 和 Buffer 机制。
但是，当你在高铁上，用着只有 2G 信号，看着你的 React 应用流畅地一个个字显现出来，当你的用户不再因为等待那个该死的 Loading 而关闭标签页时，你会发现，这一切的努力都是值得的。
记住，网络是慢的，但你的代码可以快一点。
我是你们的技术向导，现在，下课。