Next.js 16 Cache Components备忘录

大约半年前，Next.js 16 已于2025年10月21日正式发布。

Cache Components 这一概念本身是从 Next.js 16 开始引入的，使缓存可以被显式控制。

仅在编写了use cache指令的位置才会被缓存，同时还可以借助<Sunpense>实现以组件为单位的缓存。

既然已经有文章发布，这次我们主要围绕 Next.js 16 的“Cache Components”用法进行整理，同时也作为一份备忘录！

Next.js AppRouter 的四种缓存

Next.js AppRouter 中的缓存类型共有以下四种。

Request Memoization： 对相同请求进行去重。即使不同组件调用相同的 fetch，实际执行也只会进行一次。这是 Next.js 自动完成的功能。
Data Cache：通过 fetch 选项控制缓存实现的机制。
Full Route Cache： 以页面为单位的缓存，适用于静态渲染（SSG、ISR）。在服务器端缓存 RSC 载荷和 HTML。
Router Cache： 在客户端内存中临时缓存“仅 RSC 载荷”的机制。使用 Next.js 的组件即可生效。

Next.js 16 的新功能 `"use cache"`

介绍新功能 Cache Components 能够实现的内容。

通过 use cache 简化缓存配置。只有写有 use cache 的位置会被缓存，缓存可以被显式控制。
用 <Suspense>包裹组件即可将其分离，从而可以按组件单位指定缓存。

在 Next.js 15 及之前的版本中，fetch 默认会被缓存，因此很难判断哪些内容被缓存、哪些没有，容易出现不可预期的缓存。

由于默认会自动缓存，若要禁用，需要添加 fetch(URL, { cache: 'no-store' })。

另一方面，Next.js 16 改为在需要缓存时指定 use cache，方式更加明确、简洁。

此外，以往只能通过 fetch 来利用 Next.js 的 Data Cache，而现在无需 fetch，也可以直接对数据库查询等异步函数应用缓存。

实现方法

需要在 next.config.js 文件中启用 Cache Components。

通过此设置，即可使用 Cache Components 的功能！

import type { NextConfig } from "next";

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

export default nextConfig;

在需要缓存的组件顶部添加 use cache 指令。如果只想缓存特定函数，则将该指令写在函数内部。

'use cache'

async function getPosts() {
  const res = await fetch('<https://api.example.com/posts>')
  return res.json()
}

export default async function PostList() {
  const posts = await getPosts()
  return (
    <ul>
      {posts.map(post => <li>{post.title}</li>)}
    </ul>
  )
}

如果对 fetch 函数不添加 use cache，会怎样？

从 Next.js 16 开始，要进行缓存就需要添加 use cache。那么，如果既不添加 use cache，也不设置 cache 选项，会发生什么？

如果设置 cacheComponents: true，则会报错。若要有意禁用缓存，不要使用 fetch(url, { cache: 'no-store' })，只需用 <Suspense>... 包裹即可！（cacheComponents: false（默认）时，仍可像以前一样使用 no-store）

函数级别的缓存

以往只能按页面指定缓存，而现在通过使用 use cache、，即可实现组件和函数级别的缓存设置。

这带来的好处是：可以在同一页面内混合使用静态渲染和动态渲染，使快速的静态分发与动态内容得以共存，从而大幅提升初始加载速度和 UX。（PPR 渲染方式）

Suspense

其作用是将它与页面的其他部分分离，使其能够单独处理，即<Suspense>。

由于用<Suspense>包裹可以将组件分离，因此如果希望以组件为单位进行缓存，则在被包裹的组件内部进行指定。

关于渲染

渲染方式由缓存设置决定。

“这个页面或数据希望如何呈现？”（例如更新频率等）

↓

决定渲染方式（SSG / ISR / SSR / PPR / CSR）

↓

并据此设置相应的缓存

这一思路。

渲染方式也有几种模式，但这次先略过啦！

例如，

“从 microCMS 获取数据并展示博客文章的动态路由页面”的情况

↓

渲染方式最适合使用 SSG 或 ISR（因为文章内容不会频繁更新）

↓

启用缓存最合适 → 添加 use cache

就可以这样实现。

顺便一提，如果在 next.config.js 文件中没有将 Cache Components 设为 true，那么仍然可以像以前一样直接使用 fetch 的 cache 选项。

总结

在考虑缓存设置时，重要的是按照“这个数据、这个页面希望如何呈现？”的思路，结合该页面来思考并实现最佳性能的流程。

一旦确定了这个答案，是否使用 use cache 也会自然而然地确定。

很多人会把缓存相关、渲染方式、数据获取等分开来理解，但我觉得把它们全部连贯起来看，会有一种豁然开朗的感觉！

重要的是不要将它们视为独立的概念，而应将其理解为一个连贯的流程！！

Next.js AppRouter 的四种缓存

Next.js 16 的新功能 `"use cache"`