Next.js 16.4 发布，推荐所有应用使用 Cache Components

在 16.x 的一系列版本中，我们引入了一种新的编程模型，解决了你从最初使用 App Router 以来遇到的许多痛点：

这个新的编程模型叫做 Cache Components，它将在 Next.js 17 中成为默认选项。

在这个版本之前，我们没有普遍推荐它，因为在某些情况下，它无法达到与之前模型相同的成本和性能保证。

这个版本包含了弥补这些差距的关键功能。

从 Next.js 16.4 开始，我们很高兴地推荐 Cache Components 作为每个 Next.js 应用的最佳选择。

从今天起，所有通过 create-next-app 创建的新应用都将默认启用 Cache Components。全新项目可以毫无顾虑地享受新模型带来的所有好处。

对于现有应用，我们一直在投入更好的 agentic 工具来帮助代码库迁移到新模型。新的 next upgrade --agent 命令为 agent 提供针对你应用版本的升级指导，专门的 Skills 帮助 agent 完成你采用 Cache Components 所需的任何重构。

Next.js 16.4 还为所有 Next.js 应用带来了多项开箱即用的改进，包括开发环境下更低的内存占用和磁盘空间、更短的编译时间、更小的生产包体积，以及 React 19.3。

以下是这个版本的全部内容概览，从 Cache Components 开始。

Cache Components 是一组功能，让你可以将组件树中的特定部分标记为可缓存。可以把 'use cache' 理解为组件级别的 Cache-Control HTTP 头：

import { cacheLife } from 'next/cache';

export default async function DashboardPage() { const currentUser = await getCurrentUser(); return (

<div> <p>Welcome, {currentUser.name}</p> <Suspense fallback={<Loading />}> <Projects userId={currentUser.id} /> </Suspense> </div> ); }

async function Projects({ userId }) { 'use cache'; cacheLife('hours'); const projects = await db.query.projects.findMany({ where: eq(projectsTable.userId, userId), }); return (

<div> {projects.map((project) => ( <p key={project.id}>{project.name}</p> ))} </div> ); }

Next.js 在渲染页面时会解释这些 'use cache' 注解，将组件的 UI 缓存在浏览器中（客户端导航期间），并可选地缓存在服务器上（服务端渲染期间，或在构建时提前缓存）。

这些可组合的注解让你可以在单个页面中混合使用客户端缓存、完全可插拔的服务端缓存和请求时渲染，它们取代了之前 App Router 版本中的隐式缓存行为。

要了解更多关于 Cache Components 的信息，请阅读缓存指南。

在本文中，我们用「Cache Components」来指代这个新的编程模型，你现在就可以通过在 Next.js 配置中启用两个标志来使用它：

next.config.ts

import type { NextConfig } from 'next';

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

export default nextConfig;

Cache Components 最初发布时没有 Partial Prefetching，但现在它被视为该模型的一部分。你可以从我们之前的版本发布文章中了解更多关于 Partial Prefetching 的信息。

接下来是 16.4 中 Cache Components 的新内容。

'use cache' 的标志性功能之一是能够构建在单个服务器响应中同时流式传输静态和动态内容的页面。

例如，你可以将当前用户的头像与一个原本静态预渲染的博客文章组合在一起：

export default function Page() { return ( <> <UserAvatar /> <Content /> </> ); }

// This component renders at request time async function UserAvatar() { const currentUser = await getCurrentUser(); // ... }

// This component is statically prerendered async function Content() { 'use cache'; await fetch('...'); // ... }

Next.js 可以从缓存中提供预渲染的博客文章（就像你应用的 /public 文件夹或 CDN 一样），并在请求时渲染 UserAvatar，全部来自同一个 HTTP 响应。

这种灵活性使你能够构建具有复杂 UI 的应用，而不会牺牲速度或动态性。但有时你想构建一个完全静态的页面。在这些情况下，一个动态组件可能会降低原本经过优化的站点的性能或成本特性。

在 Next.js 16.4 中，ensureStatic 提供了一种简单的方式来保证路由的 shell、prefetch 或完整导航是静态的。对于希望避免意外计算并降低服务器成本的应用，这可以让你防止动态组件意外混入路由。

例如，如果我们想强制上面示例中的博客文章页面始终是静态的，并且永远不应该添加像 UserAvatar 这样的动态组件，我们可以在路由中添加 export const ensureStatic：

export const ensureStatic = 'navigation';

export default function Page() { return ( <> <UserAvatar /> {/* 🔴 This component fails the build */} <Content /> </> ); }

通过将 ensureStatic 设置为 "navigation"，如果此页面中包含任何动态内容，Next.js 将导致构建失败，确保对此路由的导航永远不会在请求时渲染。

虽然 "navigation" 是最严格的形式，但你也可以将 ensureStatic 设置为 "prefetch"（确保带有显式 prefetch 到此路由的链接只获取静态内容）或 "shell"（确保此路由首次被发现时只获取静态内容），如果你需要更细粒度的控制。

除了在单个页面上使用之外，你还可以将 ensureStatic 添加到 layout 中，以对该 layout 中的所有页面应用相同的保证。例如，你可以将 ensureStatic = 'navigation' 添加到根 layout，轻松保证你站点中的每次页面导航都是静态的：

// app/layout.tsx

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）