AREX Feed Article
Next.js 16.3 死磕 SPA 级响应，TanStack 刚挖走它的第一批开发者
2023 年 Server Components 落地时，Next.js 团队给出过一个承诺：服务端渲染的应用不需要牺牲响应速度。三年过去了，这个承诺在 16.0 之后仍然悬在半空。开发者拿到了更少的客户端 JavaScript，但点击链接之后，用户看到的还是旧页面，等着浏览器跟服务器来回握手。
8 月 3 日，Next.js 16.3 正式发布。Vercel 随即在 8 月 4 日公布了平台级适配数据：升级到 16.3 的应用平均减少了 45% 的预取请求，17% 的 CDN 静态资源请求，路由元数据在 p99 下快了约 2 倍。 Vercel CEO Guillermo Rauch 在 X 上用了三个词概括："radically more efficient"。
这不是一次让你手忙脚乱的 breaking change。它是一批次改动——大部分默认开启，零应用代码修改——和一个叫做 Instant Navigations 的 opt-in 套件，它回答了那个悬了三年的问题。
零改动，45% 更少的请求
先看数字。以下是 Vercel 在升级 16.3 后的内测数据：
- 预取请求减少 45%：升级后的应用，部分项目的预取请求降幅超过 70%。原因是 16.3 对小体积预取请求做了自动合并（prefetch inlining），而不是为每个链接单独发起一次请求。
- 静态资源请求减少 17%，传输字节减少 24%：immutable static assets 默认启用。内容哈希固定的静态文件在部署间复用，浏览器缓存不会因为一次部署而全部失效。
- p99 路由解析延迟约 2 倍提升：Vercel CDN 的路由元数据层从原来逐条缓存改为 JSONL 分片缓存，缓存未命中率下降约 10 倍。这个改进已经在平台层面对所有 Build Output API 框架生效。
这些数字的背后逻辑很简单：Next.js 16.3 把 Vercel 的平台层和框架层一起改了。 只升级框架不部署在 Vercel 上，你也拿不到 immutable static assets 的跨部署复用和路由元数据的加速，但 prefetch inlining 和 SSR 性能提升在任何托管环境都生效。
社区的反应也验证了这些数字的可信度。独立开发者 Sandeep Miriyala 在 X 上报告，他一个包含 1300 多个 Markdown 文件的应用，升级后首次加载降到一分钟以内，页面路由"感觉明显快了"。另一位用户 Grady Gaugler 直接说 "Updated my sites to 16.3 right away, no question"。Jayadeep Reddy 的评论点到了经济学层面："减少 45% 的预取请求改变了边缘计算的经济模型，二级效应是动态路由的 CDN 出口流量大幅下降。"
从内存到路由：Vercel 改了平台，不只是框架
要理解 16.3 的改动为什么大，需要把框架层和平台层拆开看。
框架层：四个默认开启的性能提升
1. Turbopack 内存驱逐。 next dev 长时间运行后，Turbopack 的内存占用最高可降 90%。Vercel 自己的内部数据：vercel.com 仪表盘编译 50 条路由后，内存从 21.5GB 降到 2GB；nextjs.org 从 4600MB 降到 840MB。如果你在 16 核 MacBook Pro 上开发大型 Next.js 项目每几小时就得重启一次 dev server，这个改动直接解决问题。
2. 构建缓存。 Turbopack 的磁盘缓存从 16.1 开始加速 next dev，现在扩展到 next build 并默认开启。vercel.com/geist 的冷构建 30 秒，缓存后 5.5 秒——5.5 倍加速。CI 上如果持久化缓存目录，增量构建的成本会大幅下降。
3. 原生 Node.js 流。 App Router 的 SSR 层把 web streams 换成了原生 Node.js streams，去掉了每次渲染的转换开销。基准测试显示应用在负载下能多处理 22% 的请求，零应用代码改动。自己托管 SSR 的团队，这意味着同样配置的服务器能撑更多流量。
4. TypeScript 7 支持。 next build 可以用 TypeScript 7 做类型检查，这是上个月发布的 10 倍速原生 TypeScript 编译器。只需把 typescript 依赖升到 ^7 即可启用。
平台层：immutable static assets 和路由元数据
immutable static assets 是 Vercel 平台层的改动。在 Build Output API 中，内容哈希固定的静态文件现在走 /_next/static/immutable/* 路径，Vercel CDN 根据这个前缀区分 immutable 和普通静态资源。部署时，未改动的 immutable 资源跳过重新上传，部署速度平均快了 30%。
更关键的是路由元数据层的改进。Next.js 16 引入了一个优化：应用的公共部分被预取一次后跨导航复用。代价是框架为每个路由段（segment）生成独立的元数据描述文件。在大规模应用中，Vercel CDN 每秒要处理 500 万次元数据查询，缓存条目膨胀后命中率下降，p99 TTFB 开始走高。
Vercel 的解决方案是把独立缓存条目合并为 JSONL 分片，配合进程内和远程缓存优化。结果是路由元数据服务快了约 2 倍，缓存未命中减少 10 倍。这个改动已经在平台层面对所有通过 Build Output API 部署的框架生效——不仅仅是 Next.js。
Opt-in：Instant Navigations 和 PPR 可观测性
Instant Navigations 需要手动打开两个 config flag：cacheComponents: true 和 partialPrefetching: true。背后的机制是 'use cache' 指令从服务器端扩展到了客户端。结合 Suspense，一条路由的 UI 可以被拆成三部分：可预渲染的静态壳、流式加载的动态内容、内联的 loading 状态。Next.js 把前两部分提前送到客户端，点击链接的瞬间就能渲染壳，不再阻塞在服务端往返。
同时，Vercel 在 dashboard 中上线了 Partial Prerendering 可观测性页面，能按请求区分静态壳、动态内容和混合渲染，帮助团队确认哪些路由的静态部分在正常工作。ISR 可观测性页面也新增了基于时间的和按需的 revalidation 展示。
三个月，16.x 的三次跃进
如果把时间线拉回到去年 11 月的 Next.js 16.0，可以清晰地看到 Vercel 在走一条什么样的路。
16.0 引入了 'use cache' 指令，把隐式缓存变成了显式——你想缓存的东西自己标记，其余默认动态。这是一个哲学层面的转向：从"框架替你猜"变成"你告诉框架"。
16.1 和 16.2 在此基础上添加了 Turbopack 的磁盘缓存和 Skew Protection，解决的是开发者体验和部署安全性。
16.3 则是这一轮架构重组的收尾：'use cache' 能力从服务器端延伸到客户端，把 SSR 的性能瓶颈（web streams 转换）去掉，把平台的瓶颈（路由元数据缓存）修好，再把 AI 编码代理的文档版本漂移问题用一个自动维护的 AGENTS.md 块解决掉。
Next.js 团队在博客中明确表示，Instant Navigations 的行为将在未来的大版本中成为默认。现在 opt-in 更像是一个温和的迁移窗口。
关于团队：Next.js 16.3 由 Andrew Clark（acdlite）、Dan Abramov（gaearon）、Tim Neutkens、Sebastian Markbåge（eps1lon）等核心成员推动，Turbopack 侧由 Tobias Koppers（sokra，webpack 作者）领衔。Vercel 至今未披露独立的融资或估值更新，但平台在持续扩展 agentic infrastructure 的产品线——6 月的 Ship 26 上发布了开源 agent 框架 eve，v0 的 API 也在本周 GA。
TanStack 在敲门，Next.js 用 16.3 回应
Next.js 16.3 发布的同一周，有开发者在 X 上公开表示"arrived just in time. was almost moving to tanstack"。这反映了一个更大的竞争压力：TanStack Start 在 2026 年上半年吸引了相当一批因为 Next.js 缓存模型复杂和导航不够快而流失的开发者。
Astro 7 在同一个月发布，主打零 JavaScript 默认输出和 Islands 架构。Nuxt 4.5 也在快速迭代。React 生态的"默认选择"地位正在被多个方向同时拉扯：一边是 TanStack 的轻量客户端方案，一边是 Astro 的极致静态路线，一边是 Remix（现 React Router v7）的 web 标准优先。
Next.js 16.3 的回应策略是两条线并行：对现有用户，零改动的性能增益让你没有理由不升级；对迟疑的观望者，Instant Navigations 解决的就是你之前离开的那个原因。
Appwrite 的开发者关系负责人 Aditya Oberai 在 16.3 的技术博客中写道："Next.js 16.3 is out, and the headline change is not a new API. It is that the App Router finally has a client-side cache." 这句话点到了核心——16.3 的叙事不是"我们又加了多少新功能"，而是"我们修好了你最头疼的东西"。
最安静的那场胜利
回到开头那个悬了三年的问题：服务端渲染的应用能不能做到 SPA 级别的导航响应？
16.3 的答案是：能做到，而且做的方式不是推翻 Server Components 重来，而是在它之上加了一层客户端缓存。这是 Vercel 这一轮架构调整里最克制也最聪明的选择：不另起炉灶，收束而非发散。
一个细节值得一提：Instant Navigations 的 Playwright 测试辅助函数 instant() 会直接断言一次导航中哪些内容必须在网络请求完成前就可见。如果未来的某次重构让你的"即时导航"退回了阻塞式，测试直接红灯。把性能做成可回归测试的——这才是"默认即快"的工程化方式。
参考链接：