了解 Next.js 16.3 中的缓存组件与部分预取功能

解释了 Next.js 16.3 的 Instant Navigations 功能如何通过共享路由壳与明确的流式处理机制，让服务器渲染的应用具备即时响应的效果。

1155 词

与纯客户端渲染的单页应用相比，App Router长期以来存在一个隐性的劣势。

当所有操作都在浏览器中完成时，切换路由只不过是状态更新，按定义而言应能瞬间完成。而服务端优先渲染则放弃了这种即时性，但初始加载数据量会大幅减少。

不过你之后要为这种权衡付出代价：每次导航（超过第一次之后）都意味着需要再次与服务器通信。

Next.js 16.3直接针对这一问题进行了改进。

该功能被称为即时导航，它依赖于两种底层机制：组件缓存与部分预取。

该框架推出的每一项导航功能在MacBook上都能展现出出色的性能。

那它到底能实现什么？

这一设计理念几乎直接借鉴自单页应用的设计思路。与早期版本会为每个链接预加载目标页面的完整内容不同，

Next.js现在会预加载每个路由共用的框架结构，并将其缓存在客户端。一旦点击链接，该框架结构会立即渲染，同时服务器再流式传输其后剩余的内容。

这个框架结构被刻意设计得较为简单，包括布局、导航栏、标题以及骨架结构——基本上就是无论进入该路由的哪个具体页面都会保持一致的元素。由于它永远不会改变，因此只需缓存一次即可安全地被用于指向同一路由的数十个链接中。

你可以通过两个配置标志来启用此功能：

const nextConfig: NextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
};

预计这两个标志都将在未来的某个重大版本中成为默认设置。现在就启用它们，能让你提前适应这一变化，而非陷入某种实验性的死胡同。

为何这不仅仅是“预加载，但速度更快”

这里真正的变化并非仅仅关乎原始速度，而是要在每条路由上强制做出明确决策。

Next.js 16.3引入了一项名为Instant Insights的新开发工具，它能在你的开发环境中自动标记出那些不属于即时加载的导航操作。要移除这些标记，现在每条路由都必须明确说明在数据尚未准备好时应如何处理。共有三种有效的解决方案：

流式传输：将耗时的部分用<Suspense>包裹，这样在服务器完成处理期间会显示加载界面。

缓存它。用 'use cache' 标记该内容，这样就可以直接提供之前生成的版本，而无需等待。

刻意阻止缓存。对于那些确实需要等待的路由，比如结账确认页面，显示过时的数据比让用户稍等片刻更糟糕，此时应使用 export const instant = false。

第三种方式值得重视。它将“此路由响应缓慢”这一原本可能被忽视的问题，转变为一种有明确记录的刻意决策。框架并非要求所有路由都必须即时响应，而是规定从现在起，延迟响应必须是刻意为之，而非默认状态。

这种做法真正能带来好处之处

最典型的情况是那些包含大量链接的页面，比如显示有四十条工单记录的支持邮箱界面。每一页工单很可能都使用相同的工具栏、元数据网格以及对话框架。如果为每个链接单独预加载页面，就意味着要重复四十次地加载同样的结构。而部分预加载则只需预先加载一次这个共享框架，将其用于所有指向该路径的链接，仅传输真正独特的内容——即具体工单的信息。

这是一种切实且有效的改进，也与许多SaaS控制台的实际构建方式十分契合。

大多数介绍都忽略的弊端

有一名开发者将个人博客迁移到了单独分支上的16.3预览版，全面采用了缓存组件和部分预加载功能，并通过包含19个测试用例的Playwright测试套件来确保导航操作能够即时完成，所有测试均通过。

连续一周对比两个版本后，他们未能发现任何实质性的差异。

原因其实简单得令人有些失望。

该网站早已是完全静态的：所有页面在构建时就已预渲染完毕，直接通过CDN提供内容。无需再进行任何服务器端的数据传输，因此“即时导航”功能根本不存在需要弥补的差距。

真正让网站显得更流畅的因素完全是别的东西：压缩后的JavaScript文件体积减少了341KB。

在采用此功能之前，您必须牢记这一注意事项。即时导航能够消除点击链接与查看内容之间的延迟，尤其适用于依赖服务器的动态路由。

如果您的应用已经是静态的，或者由于其他原因已经具备快速响应能力，那么采用这项功能其实是在解决一个在您的情况下并不存在的问题。

请先在那些确实反应缓慢的路由上尝试该功能，而非在整个网站范围内推广；同时应在速度受限的中端安卓设备连接下进行测试，而非在办公区高速WiFi连接的笔记本电脑上测试。开头关于MacBook的评论值得注意：该框架此前推出的几乎所有导航功能在MacBook上都能展现出出色的性能。

该框架并不要求每个路由都必须立即响应。它的意思是，从现在开始，延迟响应必须是刻意为之，而非默认状态。

实际该怎么做

如果您已经在使用 Next.js 16.x，且发现页面导航速度较慢，建议从小处着手。先在使用最频繁的两三个路由上启用部分预取功能，之后再逐步推广到其他页面。大部分好处来自于前期准备工作，而在有限范围内进行测试还能帮助您确认布局是否真正与数据获取逻辑分离——对于许多实际项目而言，这往往才是更有价值的发现。

如果你仍在使用 Pages Router 并犹豫是否要迁移，这一功能不应成为你的决定因素。Turbopack 成为开发时的默认选择，再加上 App Router 的进一步稳定，才是真正促使你迁移的理由。即时导航只是迁移后的额外好处，并非开始迁移的初始原因。

如果你的应用已经是完全静态的，那就直接跳过迁移步骤。

去寻找属于自己的 341KB 吧。