Next.js App Router：默认思考服务器指南

当 [Next.js2] 推出 App Router 时，它做了一些看似技术性的事情，但本质上是一种心态决定：它扭转了模式。以前，每个组件都是客户拥有的，除非您另有说明。现在，每个组件都是服务器端的，直到您检查它是否需要是客户端为止。

这种反转在语法上很小，但在实践中却很大。它改变了团队向每个组件提出的问题。您不必假设所有内容都在浏览器中运行，而是证明为什么某些内容需要在浏览器中运行。

对于那些来自传统 React 的人来说，App Router 不仅仅是一个具有不同路由器的新文件夹。这是一个重新思考应用程序的每个部分应该存放在哪里的邀请。而这个邀请在它变得有意义之前往往会让人迷失方向。

模式已经逆转

在 App Router 中，布局和页面默认是服务器组件。这意味着，当您创建新页面时，它会开始在服务器上运行，而无需您执行任何操作。它的代码不会进入浏览器，数据搜索可以在响应出来之前就在那里进行。

直接的后果是，您本来推送到客户端的许多内容现在自然会保留在服务器上。产品列表、文章内容、包含用户数据的标题，所有这些都在到达之前呈现，设备上无需 JavaScript 成本。

当您需要交互性时，可以使用0指令来标记该组件。从那时起，该组件及其呈现的内容开始在浏览器中运行，并带有状态和事件。这是一个明确的界限，而不是偶然的。

健康的副作用是顾客有意识地成为例外。你不会因为惯性而陷入其中，你会选择何时进入。如果这听起来仍然很抽象，那么在继续之前有必要回顾一下 React Server Components 3 是什么。

正确的问题是关于工作的性质。如果组件只是搜索和显示信息，那么它就具备了作为服务器的一切条件。列表页面、博客内容、订单详细信息、仅显示数字的仪表板：这些都不需要浏览器存在。

服务器组件在获取数据方面表现出色。您可以直接咨询银行，以基础设施内低延迟的方式调用内部服务，并创建现成的结果。您不需要中间 API 路由来让浏览器能够请求数据，因为该组件已经位于右侧。

还可以减轻客户的体重。繁重的格式化库、降价处理、日期操作：如果它在服务器上运行，它永远不会进入用户下载的包。捆绑包缩小了，用户的设备感谢您。

有效的心理规则是这样的：首先接管服务器。仅当确实需要互动时才转向客户。作为客户，抵制住给所有东西打上品牌的冲动就成功了一半。

并非所有内容都适合服务器，尝试强制这样做会导致挫败感。有一系列明确的情况需要客户，快速识别它们可以避免浪费时间。

第一个是屏幕上变化的状态。计数器、选定的选项卡、打开和关闭的菜单：任何需要记住交互之间的内容的东西都存在于客户端中。第二个是用户事件。单击、键入、拖动，任何直接操作都发生在浏览器中，因为那是用户所在的位置。

第三是浏览器资源的使用。访问本地存储、地理位置、阅读窗口大小以及仅存在于浏览器环境中的任何内容都需要组件位于客户端。无法在服务器上运行它，因为服务器没有窗口或鼠标。

释放团队思想的细节是理解这不是全部或全部。您可以有一个服务器页面，它只为交互式按钮呈现一个小型客户端组件。页面的其余部分仍然是轻量级的并在服务器上呈现。交互性在真正重要的地方被隔离，而不是污染整个页面。

在旧模型中，获取数据是一个众所周知的仪式：组装组件、触发效果、调用 API、处理加载和错误状态，并在响应返回时更新状态。它有效，但冗长且充满陷阱。

使用服务器组件，数据获取再次变得简单。您在服务器渲染期间获取数据，等待结果并返回现成的界面。向客户端添加大量加载状态，因为数据已经随页面到达。

这样简化了代码，同时提升了体验，这是很难得的。用户收到已填写的内容，而在每个部分加载时不会出现一系列空白屏幕闪烁。当您需要渐进式加载时，该框架提供流式传输以在块准备好时交付块，这是一个值得深入研究的主题[Next.js4]中的缓存和流式传输。

数据突变遵循类似的逻辑。您可以使用服务器操作，即在服务器上运行并直接从界面调用的函数，而不是为每个表单组合一个完整的 API。这就结束了循环：接近源的读取和写入，没有仅为服务浏览器而存在的层。

App Router 的困难部分不是语法。它正在忘记一切都在浏览器中运行的反射。在 React 方面经验丰富的团队倾向于出于习惯将组件标记为客户端，因为这就是他们学习的方式，然后他们就失去了很多收获。

典型的症状是几乎每个文件顶部的1。当这种情况发生时，应用程序会变回变相的 SPA，同时增加之前的重量和新的复杂性。团队需要认识到每次客户预约都是一个需要证明的决定，而不是一个可以复制的模式。

还有关于代码执行位置的心理调整。考虑到树的一部分在服务器上运行，一部分在浏览器上运行，需要关心每一方可以做什么。尝试在服务器组件中使用浏览器功能会产生错误，这些最初的错误是学习的正常部分。

一旦一分钱掉下来，模型就会变得直观。问题是这是否需要交互变得自动化，并且团队默认开始设计轻量级界面。但要实现这一目标，需要技术领导层愿意耐心地审查代码并纠正旧的反应。

如果您正在考虑在团队中采用 App Router，请将学习曲线视为项目的一部分，而不是细节。给团队留出时间犯错误、回顾和调整直觉。为了将此选择置于更大的架构决策中，请继续[作为架构决策的服务器优先运动5]。