什么是 React 服务器组件以及为什么逻辑要移回服务器

十多年来，React 规则一直很简单：一切都发生在浏览器中。服务器交付了一个几乎空的 HTML 文件，浏览器下载了一个很大的 JavaScript 包，执行了这段代码，然后界面才真正出现。它确实有效，但成本却不断增加。

这个成本就是 React Server Components 来收取的。中心思想很简单：并非每个组件都需要在用户的浏览器中运行。它的大部分界面仅搜索数据、格式化文本和创建结构。这种类型的工作可以在到达客户端之前在服务器上进行。

这不是一个实现细节。这是应用程序所在位置的变化，它直接影响速度、维护成本和产品使用人员的体验。

没人愿意承认的问题

传统的 React 应用程序（称为 SPA）几乎将所有责任都推给了浏览器。用户打开页面，收到一个空骨架，等待 JavaScript 下载、执行，然后才能看到有用的内容。

凭借良好的连接和功能强大的手机，这一点几乎不会被注意到。在网络不稳定的普通设备上，它会变成白屏，需要很长时间。而大多数真实的公众比第一种情况更接近第二种情况。

最糟糕的是这个 JavaScript 包只会增长。每个日期格式化库、每个 API 客户端、每个实用程序都会进入浏览器需要下载的捆绑包中。大部分代码永远不需要在那里，因为它的唯一功能是准备已经准备好的数据。

服务器组件正是针对这种浪费。它们允许您将没有理由存在于客户端的代码移动到服务器。

需要理解的最重要的区别是两种组件类型之间的区别。服务器组件仅在服务器上运行。它搜索数据、组装结构并生成准备发送到浏览器的结果。它的代码不附带，因此它不会影响用户下载的包。

客户端组件就是你已经知道的 React。它在浏览器中运行，具有状态，响应点击，控制表单并处理任何交互。要将组件标记为客户端，请使用文件顶部的 0 指令。

经验法则几乎是直观的。如果该组件仅显示信息，则它可能是服务器端的。如果它需要对用户做出反应、保存状态或使用浏览器资源，则它需要是客户端的。

优雅的细节是两人住在同一棵树上。服务器组件可以在其中呈现客户端组件。您不必明确选择哪一方，而是根据每个部分的实际需求将两者混合来组成界面。

第一个收获是数据搜索。在服务器组件中，您可以直接查询数据库或调用 API，无需中间层即可让浏览器能够与后端通信。数据是在靠近源的地方获取的，对于基础设施内的数据来说延迟很低。

第二个收益是到达客户手中的商品的规模。由于未提供服务器组件的代码，因此 JavaScript 捆绑包会缩小。下载的代码更少，浏览器处理的代码更少，页面可用的时间也更少。在普通设备中，皮肤可以感受到这种差异。

第三个增益是初始加载。用户收到已经渲染的内容，文本和结构几乎立即可见，而不是等待 JavaScript 唤醒的空白画布。对速度的感知会发生变化，而感知决定了某人是留下还是离开。

还有一个经常被忽视的好处：秘密保留在服务器上。 API 密钥、敏感业务逻辑和您不希望公开的规则仍保留在浏览器外部，因为它们永远不会发送到那里。如果您要了解更大的情况，值得阅读[2026 年的网络开发1]，看看它适合什么地方。

值得理解这个对话中经常出现的一个概念：水合作用。当客户端组件到达已经由服务器渲染的浏览器时，React 需要将事件和状态附加到现有的 HTML，以使其成为交互式的。将静态 HTML 变为现实的过程就是水化。

传统应用程序的问题在于它们会水合所有内容，包括永远不会对用户做出反应的部分。对于那些只想阅读的人来说，这不会消耗设备上的处理能力。

使用服务器组件，您只需补充需要交互的内容。这些纯粹的信息片段到达时是现成的，并且保持安静，不会浪费手机的处理器。更少的水合作用意味着更少的设备工作和更快的响应界面。

对 React 生态系统中的任何新事物保持警惕是公平的，因为它经常改变范式。但服务器组件并不是当前的框架。它们应对不断累积的压力：应用程序太大，浏览器无法正常处理。

当应用程序很小时，将所有内容发送给客户是一种有用的简化。当它们成长时，该模型开始在性能和解决方法的复杂性方面花费大量成本，以克服捆绑包的重量。

将部分逻辑返回给服务器并不是对PHP时代的怀旧。它认识到每种类型的工作都有正确的发生地点，并且坚持在浏览器中完成所有操作是一种选择，而不是法律。服务器组件将这种选择权返回给团队，并使用现代工具来执行它。

如果您领导一个团队或决定架构，那么重点不是采用该技术，因为它是新技术。可以理解的是，服务器和客户端之间的边界再次是一个有意识的决定，忽略它会降低用户感知到的性能。

下一步最好是在推广这一想法的框架内看看它在实践中的表现如何。继续阅读 [Next.js App Router2 指南，了解服务器组件如何成为日常标准。