揭秘 React Flight：驱动服务器组件的可序列化协议

Web 开发的世界在不断演进。多年来，主流范式是单页应用 (SPA)，即向客户端发送一个最小化的 HTML 外壳，然后由客户端获取数据并使用 JavaScript 渲染整个用户界面。这种模型虽然强大，但也带来了诸如打包体积过大、客户端-服务器数据瀑布流以及复杂的状态管理等挑战。为此，社区正在见证一场向以服务器为中心的架构的重大回归，但这是一种带有现代特色的回归。引领这场变革的是 React 团队一项开创性的功能：React 服务器组件 (RSC)。

但这些仅在服务器上运行的组件，是如何神奇地出现并无缝集成到客户端应用程序中的呢？答案在于一项鲜为人知但至关重要的技术：React Flight。你不会每天都直接使用这个 API，但理解它却是解锁现代 React 生态系统全部潜能的关键。本文将带你深入了解 React Flight 协议，揭开驱动下一代 Web 应用程序引擎的神秘面纱。

什么是 React 服务器组件？快速回顾

在我们剖析协议之前，让我们简要回顾一下什么是 React 服务器组件以及它们为何重要。与在浏览器中运行的传统 React 组件不同，RSC 是一种新型组件，专为仅在服务器上执行而设计。它们从不将其 JavaScript 代码发送到客户端。

这种仅在服务器端执行的特性带来了几个颠覆性的好处：

零打包体积：由于组件代码从未离开服务器，它对你的客户端 JavaScript 打包没有任何贡献。这对于性能来说是一个巨大的胜利，特别是对于复杂、数据密集的组件。
直接数据访问：RSC 可以直接访问服务器端资源，如数据库、文件系统或内部微服务，而无需暴露 API 端点。这简化了数据获取并消除了客户端-服务器请求瀑布流。
自动代码分割：因为你可以动态选择在服务器上渲染哪些组件，你实际上获得了自动代码分割。只有交互式客户端组件的代码才会被发送到浏览器。

将 RSC 与服务器端渲染 (SSR) 区分开来至关重要。SSR 在服务器上将你的整个 React 应用预渲染成一个 HTML 字符串。客户端接收到这个 HTML，显示它，然后下载整个 JavaScript 包来“注水”（hydrate）页面并使其具有交互性。相比之下，RSC 渲染的是一种特殊的、对 UI 的抽象描述——而不是 HTML——然后流式传输到客户端，并与现有的组件树进行协调。这使得更新过程更加精细和高效。

React Flight 介绍：核心协议

那么，如果服务器组件发送的既不是 HTML 也不是它自己的 JavaScript，那它发送的是什么？这就是 React Flight 发挥作用的地方。React Flight 是一个专为将渲染后的 React 组件树从服务器传输到客户端而设计的序列化协议。

你可以把它看作是一个能够理解 React 原语的、可流式传输的专用版 JSON。它是连接你的服务器环境和用户浏览器的“线路格式”。当你渲染一个 RSC 时，React 不会生成 HTML，而是生成一个 React Flight 格式的数据流。

为什么不直接使用 HTML 或 JSON？

一个自然而然的问题是，为什么要发明一个全新的协议？为什么我们不能使用现有标准？

为什么不是 HTML？发送 HTML 是 SSR 的领域。HTML 的问题在于它是一个最终的表示形式，失去了组件结构和上下文。你无法轻易地将新的流式 HTML 片段集成到一个现有的、交互式的客户端 React 应用中，除非进行整页刷新或复杂的 DOM 操作。React 需要知道哪些部分是组件，它们的 props 是什么，以及交互式的“孤岛”（客户端组件）位于何处。
为什么不是标准 JSON？JSON 非常适合传输数据，但它无法原生表示 UI 组件、JSX 或像 Suspense 边界这样的概念。你可以尝试创建一个 JSON 模式来表示组件树，但这会非常冗长，并且无法解决如何表示一个需要在客户端动态加载和渲染的组件的问题。

React Flight 正是为了解决这些特定问题而创建的。它被设计为：

可序列化：能够表示整个组件树，包括 props 和状态。
可流式传输：UI 可以分块发送，允许客户端在完整响应可用之前开始渲染。这对于与 Suspense 的集成至关重要。
React 感知：它对 React 的概念，如组件、上下文和客户端代码的懒加载，提供了一流的支持。

React Flight 的工作原理：分步解析

使用 React Flight 的过程涉及到服务器和客户端之间协调的“舞蹈”。让我们来看看一个使用 RSC 的应用程序中请求的生命周期。

在服务器端

请求发起：用户导航到你应用程序中的一个页面（例如，一个 Next.js App Router 页面）。
组件渲染：React 开始为该页面渲染服务器组件树。
数据获取：在遍历树的过程中，它会遇到获取数据的组件（例如，`async function MyServerComponent() { ... }`）。它会等待这些数据获取完成。
序列化为 Flight 流：React 渲染器不生成 HTML，而是生成一个文本流。这个文本就是 React Flight 载荷。组件树的每个部分——一个 `div`、一个 `p`、一个文本字符串、一个对客户端组件的引用——都被编码成这个流中的特定格式。
流式传输响应：服务器不会等待整个树都渲染完毕。一旦 UI 的第一批块准备就绪，它就开始通过 HTTP 将 Flight 载荷流式传输到客户端。如果遇到 Suspense 边界，它会发送一个占位符，并在后台继续渲染被挂起的内容，当内容准备好后，在同一个流中稍后发送。

在客户端

接收流：浏览器中的 React 运行时接收 Flight 流。它不是一个单一的文档，而是一个连续的指令流。
解析与协调：客户端的 React 代码逐块解析 Flight 流。这就像接收一套用于构建或更新 UI 的蓝图。
重构树：对于每条指令，React 都会更新其虚拟 DOM。它可能会创建一个新的 `div`，插入一些文本，或者——最重要的是——识别出客户端组件的占位符。
加载客户端组件：当流中包含对客户端组件（标有 "use client" 指令）的引用时，Flight 载荷会包含有关下载哪个 JavaScript 包的信息。然后，如果该包尚未被缓存，React 就会去获取它。
注水与交互性：一旦客户端组件的代码加载完毕，React 就会在指定的位置渲染它并进行注水，附加事件监听器，使其完全可交互。这个过程是高度针对性的，只发生在页面的交互部分。

这种流式和选择性注水模型比传统的 SSR 模型效率高得多，后者通常需要对整个页面进行“全有或全无”的注水。

React Flight 载荷剖析

要真正理解 React Flight，看看它产生的数据格式会很有帮助。虽然你通常不会直接与这个原始输出交互，但看到它的结构可以揭示其工作原理。载荷是一个由换行符分隔的类 JSON 字符串组成的流。每一行，或每一个块，都代表一条信息。

让我们来看一个简单的例子。假设我们有这样一个服务器组件：

app/page.js (服务器组件)


<!-- 假设这是真实博客中的代码块 -->
async function Page() {
  const userData = await fetchUser(); // 获取 { name: 'Alice' }
  return (
    <div>
      <h1>Welcome, {userData.name}</h1>
      <p>Here is your dashboard.</p>
      <InteractiveButton text="Click Me" />
    </div>
  );
}

以及一个客户端组件：

components/InteractiveButton.js (客户端组件)


<!-- 假设这是真实博客中的代码块 -->
'use client';

import { useState } from 'react';

export default function InteractiveButton({ text }) {
  const [count, setCount] = useState(0);
  return (
    <button onClick={() => setCount(count + 1)}>
      {text} ({count})
    </button>
  );
}

服务器为这个 UI 发送到客户端的 React Flight 流可能看起来像这样（为清晰起见已简化）：


<!-- Flight 流的简化示例 -->
M1:{"id":"./components/InteractiveButton.js","chunks":["chunk-abcde.js"],"name":"default"}
J0:["$","div",null,{"children":[["$","h1",null,{"children":["Welcome, ","Alice"]}],["$","p",null,{"children":"Here is your dashboard."}],["$","@1",null,{"text":"Click Me"}]]}]

让我们来解析这个神秘的输出：

`M` 行 (模块元数据)：以 `M1:` 开头的行是一个模块引用。它告诉客户端：“由 ID `@1` 引用的组件是 `./components/InteractiveButton.js` 文件的默认导出。要加载它，你需要下载 JavaScript 文件 `chunk-abcde.js`。” 这就是动态导入和代码分割的处理方式。
`J` 行 (JSON 数据)：以 `J0:` 开头的行包含了序列化后的组件树。让我们看看它的结构：`["$","div",null,{...}]`。
`$` 符号：这是一个特殊的标识符，表示一个 React 元素（本质上就是 JSX）。其格式通常是 `["$", type, key, props]`。
组件树结构：你可以看到 HTML 的嵌套结构。`div` 有一个 `children` prop，它是一个包含 `h1`、`p` 和另一个 React 元素的数组。
数据集成：注意名字 `"Alice"` 被直接嵌入在流中。服务器的数据获取结果被直接序列化到 UI 描述中。客户端不需要知道这些数据是如何被获取的。
`@` 符号 (客户端组件引用)：最有趣的部分是 `["$","@1",null,{"text":"Click Me"}]`。`@1` 是一个引用。它告诉客户端：“在树的这个位置，你需要渲染由模块元数据 `M1` 描述的客户端组件。当你渲染它时，给它传递这些 props：`{ text: 'Click Me' }`。”

这个载荷是一套完整的指令。它精确地告诉客户端如何构建 UI，显示哪些静态内容，在哪里放置交互式组件，如何加载它们的代码，以及要传递给它们什么 props。所有这些都以一种紧凑、可流式传输的格式完成。

React Flight 协议的主要优势

Flight 协议的设计直接促成了 RSC 范式的核心优势。理解了这个协议，就能清楚地知道为什么这些优势是可能的。

流式传输与原生 Suspense

因为协议是一个由换行符分隔的流，服务器可以在渲染 UI 的同时发送它。如果一个组件被挂起（例如，等待数据），服务器可以在流中发送一个占位符指令，发送页面其余部分的 UI，然后，一旦数据准备就绪，就在同一个流中发送一条新指令，用实际内容替换占位符。这提供了一流的流式体验，而无需复杂的客户端逻辑。

服务器逻辑零打包体积

从载荷中可以看到，`Page` 组件本身的代码完全不存在。数据获取逻辑、任何复杂的业务计算，或者像仅在服务器上使用的大型库这样的依赖项，都完全没有。流中只包含该逻辑的*输出*。这就是 RSC “零打包体积”承诺背后的基本机制。

数据获取的同地协作 (Colocation)

`userData` 的获取发生在服务器上，只有其结果 (`'Alice'`) 被序列化到流中。这允许开发者将数据获取代码直接写在需要它的组件内部，这个概念被称为同地协作 (colocation)。这种模式简化了代码，提高了可维护性，并消除了困扰许多 SPA 的客户端-服务器瀑布流问题。

选择性注水 (Selective Hydration)

协议对已渲染的 HTML 元素和客户端组件引用（`@`）的明确区分，是实现选择性注水的原因。客户端的 React 运行时知道，只有 `@` 组件需要其对应的 JavaScript 才能变得可交互。它可以忽略树的静态部分，从而在初始页面加载时节省大量的计算资源。

React Flight 与替代方案：全球视角下的比较

为了欣赏 React Flight 的创新之处，将其与全球 Web 开发社区中使用的其他方法进行比较会很有帮助。

对比传统 SSR + 注水

如前所述，传统的 SSR 发送一个完整的 HTML 文档。然后客户端下载一个大的 JavaScript 包并“注水”整个文档，将事件监听器附加到静态 HTML 上。这可能既慢又脆弱。一个错误就可能阻止整个页面变得可交互。React Flight 的流式和选择性特性是这一概念更具弹性和性能的演进。

对比 GraphQL/REST API

一个常见的困惑是 RSC 是否会取代像 GraphQL 或 REST 这样的数据 API。答案是否定的，它们是互补的。React Flight 是一个用于序列化 UI 树的协议，而不是一个通用的数据查询语言。实际上，一个服务器组件通常会在服务器上使用 GraphQL 或 REST API 来获取其数据，然后再进行渲染。关键区别在于，这个 API 调用是服务器到服务器的，这通常比客户端到服务器的调用更快、更安全。客户端通过 Flight 流接收最终的 UI，而不是原始数据。

对比其他现代框架

全球生态系统中的其他框架也在解决服务器-客户端分离的问题。例如：

Astro Islands：Astro 使用了类似的“孤岛”架构，其中大部分网站是静态 HTML，而交互式组件是单独加载的。这个概念类似于 RSC 世界中的客户端组件。然而，Astro 主要发送 HTML，而 React 通过 Flight 发送结构化的 UI 描述，这使得与客户端 React 状态的集成更加无缝。
Qwik 与可恢复性 (Resumability)：Qwik 采用了另一种名为“可恢复性”的方法。它将应用程序的整个状态序列化到 HTML 中，这样客户端在启动时就不需要重新执行代码（注水）。它可以从服务器停止的地方“恢复”。React Flight 和选择性注水旨在通过一种不同的机制——即只加载和运行必要的交互式代码——来实现相似的快速可交互时间目标。

对开发者的实际影响与最佳实践

虽然你不会手写 React Flight 载荷，但理解这个协议会影响你构建现代 React 应用程序的方式。

拥抱 `"use server"` 和 `"use client"`

在像 Next.js 这样的框架中，`"use client"` 指令是你控制服务器和客户端之间边界的主要工具。它向构建系统发出信号，表明一个组件及其子组件应该被视为一个交互式孤岛。它的代码将被打包并发送到浏览器，而 React Flight 将序列化一个对它的引用。相反，没有这个指令（或对服务器操作使用 `"use server"`）则将组件保留在服务器上。掌握这个边界是构建高效应用程序的关键。

以组件而非端点的思维方式思考

使用 RSC，组件本身就可以是数据容器。你可以创建一个单一的服务器组件 `` 在内部获取数据，而不是创建一个 API 端点 `/api/user` 和一个从中获取数据的客户端组件。这简化了架构，并鼓励开发者将 UI 及其数据视为一个单一、内聚的单元。

安全是服务器端的责任

因为 RSC 是服务器代码，它们拥有服务器权限。这很强大，但需要严谨的安全方法。所有的数据访问、环境变量的使用以及与内部服务的交互都在这里发生。对待这些代码要像对待任何后端 API 一样严格：对所有输入进行净化，对数据库查询使用预处理语句，并且绝不暴露可能被序列化到 Flight 载荷中的敏感密钥或秘密。

调试新一代技术栈

在 RSC 的世界里，调试方式也发生了变化。一个 UI 错误可能源于服务器端的渲染逻辑，也可能源于客户端的注水过程。你需要能够自如地检查服务器日志（用于 RSC）和浏览器的开发者控制台（用于客户端组件）。网络(Network)选项卡也比以往任何时候都更加重要。你可以检查原始的 Flight 响应流，以确切地看到服务器正在向客户端发送什么，这对于故障排查非常有价值。

React Flight 与 Web 开发的未来

React Flight 及其所赋能的服务器组件架构，代表了我们对 Web 构建方式的根本性反思。这种模型结合了两个世界的优点：基于组件的 UI 开发所带来的简单而强大的开发者体验，以及传统服务器渲染应用程序的性能和安全性。

随着这项技术的成熟，我们可以期待看到更多强大的模式出现。允许客户端组件调用服务器上安全函数的服务器操作 (Server Actions)，就是一个基于这种服务器-客户端通信渠道构建的功能的典型例子。该协议是可扩展的，这意味着 React 团队未来可以添加新功能而不会破坏核心模型。

结论

React Flight 是 React 服务器组件范式中无形但不可或缺的支柱。它是一个高度专业化、高效且可流式传输的协议，它将服务器渲染的组件树转换成一套指令，客户端的 React 应用程序可以理解并使用这些指令来构建丰富、交互式的用户界面。通过将组件及其昂贵的依赖项从客户端转移到服务器，它使得 Web 应用程序更快、更轻、更强大。

对于世界各地的开发者来说，理解 React Flight 是什么以及它如何工作，不仅仅是一项学术活动。它为在这个服务器驱动 UI 的新时代中架构应用程序、进行性能权衡和调试问题提供了一个至关重要的心智模型。变革正在发生，而 React Flight 正在为前方的道路铺路。