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

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

_rsc 问题

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

服务器会这样回复

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

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

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

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

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

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

• https://github.com/vercel/next.js/discussions/59167（GitHub上的Next.js讨论）
• https://www.reddit.com/r/nextjs/comments/1ds5nl4/这些_rsc_网络请求是什么？/
• https://www.reddit.com/r/reactjs/comments/13vkgl0/nextjs_app_router简直是彻底的失败/

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

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

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

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