Next.js App Router 的阴暗面：不必要的rsc请求让人头疼-原创手记-慕课网

今天我想谈谈关于 Next.js 的一个令人失望的问题——App 路由。

关于SSR（此处可补充SSR的全称或具体含义）的一些介绍

我认为你对SSR有所了解，并且大致知道它是如何运作的。例如，服务器返回带有标签的HTML页面，而JS和CSS包正在下载中，用户可以立即看到页面，但JS代码的解析需要一些时间。

`_rsc` 问题

每次你在 Next.js 中切换路由时，它会从服务器请求一些元信息，你可以在这些请求中看到 {smt}_rsc 这样的格式，我猜这应该代表 _ReactServerComponent。

_rsc 请求

服务器会这样回复

这是一张图片链接，点击可以查看图片。

Next.js 路由器在更新 searchParams 时，它仍会发起请求，例如 /url?param=value，这完全是客户端操作，但依旧会发起 _rsc 请求。

另一个例子，当有一个卡片列表时，每个卡片都包含一个带有 Next/Link 组件的编辑按钮，还有一个单独的编辑页面，例如 /card/{some_id}/edit。
Next.js 尝试优化这些资源并提前预取那些 _rsc 请求。结果是，每个卡片都会有一个请求，但用户可能根本不会点击这个编辑按钮。

即使你的服务器非常快，互联网连接也非常快，网络请求还是会拖慢UI，并给服务器带来更多压力。

SSR 对初始页面加载很有帮助，但在应用加载后的导航更为频繁。

讨论：

大家对于这个问题讨论得不多：

如何解决这个问题

切换到类似 Remix 的方式对现有的项目来说有点太复杂了。

当你确定这是完全客户端的操作时，可以使用普通的 window.history 接口，并用 pushState/replaceState 替代应用路由器。

可以使用一个库，比如 state-in-url（state-in-url），来简化 queryParams 和 searchParams 的处理。它默认使用 history API，并且可以选择使用应用路由。相比之下，它比 NUQS 更加简单，可以直接使用具备正确类型的解析功能。

谢谢阅读，考虑给个赞，或者分享一下也行。

Next.js App Router 的阴暗面：不必要的rsc请求让人头疼

_rsc 问题

`_rsc` 问题