跳至内容

fetch

Next.js 扩展了 Web 的 fetch() API,以允许服务器上的每个请求设置其自己的持久缓存和重新验证语义。

在浏览器中,cache 选项指示 fetch 请求将如何与浏览器的 HTTP 缓存交互。通过此扩展,cache 指示服务器端 fetch 请求将如何与框架的持久 数据缓存 交互。

您可以在服务器组件中直接使用 asyncawait 调用 fetch

app/page.tsx
export default async function Page() {
  let data = await fetch('https://api.vercel.app/blog')
  let posts = await data.json()
  return (
    <ul>
      {posts.map((post) => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  )
}

fetch(url, options)

由于 Next.js 扩展了 Web 的 fetch() API,因此您可以使用任何 可用的原生选项

options.cache

配置请求应如何与 Next.js 数据缓存 交互。

fetch(`https://...`, { cache: 'force-cache' | 'no-store' })
  • force-cache(默认):Next.js 在其数据缓存中查找匹配的请求。
    • 如果存在匹配项且其处于新鲜状态,则将从缓存中返回。
    • 如果不存在匹配项或匹配项已过期,Next.js 将从远程服务器获取资源,并使用下载的资源更新缓存。
  • no-store:Next.js 在每次请求时都从远程服务器获取资源,而不查看缓存,并且不会使用下载的资源更新缓存。

options.next.revalidate

fetch(`https://...`, { next: { revalidate: false | 0 | number } })

设置资源的缓存生存期(以秒为单位)。

  • false - 无限期缓存资源。在语义上等效于 revalidate: Infinity。HTTP 缓存可能会随着时间的推移清除较旧的资源。
  • 0 - 阻止缓存资源。
  • number - (以秒为单位)指定资源的缓存生存期最多为 n 秒。

了解一下:

  • 如果单个 fetch() 请求设置的 revalidate 数字低于路由的 默认 revalidate,则整个路由重新验证间隔将减少。
  • 如果同一路由中两个具有相同 URL 的 fetch 请求具有不同的 revalidate 值,则将使用较低的值。
  • 为方便起见,如果 revalidate 设置为数字,则无需设置 cache 选项。
  • 冲突的选项(例如 { revalidate: 3600, cache: 'no-store' })将导致错误。

options.next.tags

fetch(`https://...`, { next: { tags: ['collection'] } })

设置资源的缓存标签。然后可以使用 revalidateTag 按需重新验证数据。自定义标签的最大长度为 256 个字符,标签项的最大数量为 64 个。

故障排除

在开发环境中,cache: 'no-store'fetch 获取不到最新数据

在本地开发环境中,Next.js 会在服务器组件的热模块替换 (HMR) 期间缓存 fetch 响应,以加快响应速度并降低计费 API 调用的成本。

默认情况下,HMR 缓存 应用于所有 fetch 请求,包括那些使用 cache: 'no-store' 选项的请求。这意味着在 HMR 刷新之间,未缓存的请求不会显示最新数据。但是,缓存会在导航或完整页面重新加载时清除。

请参阅 serverComponentsHmrCache 文档以了解更多信息。

版本历史

版本更改
v13.0.0引入了 fetch