Next.js 数据获取：getServerSideProps 与新 fetch 缓存策略详解

一、Pages Router 中 getServerSideProps 的运行机制与瓶颈

在 Next.js 的 Pages Router 时代，动态数据获取的核心是页面级导出函数 getServerSideProps。每当浏览器向特定路由发起页面导航或初次加载时，Node.js 运行时都会在服务端拦截该请求并执行此函数。

该函数的典型形态如下：

// pages/dashboard.tsx (Pages Router)
import type { GetServerSideProps, InferGetServerSidePropsType } from 'next';

interface DashboardData {
  user: { id: string; name: string };
  unreadCount: number;
  serverTime: string;
}

export const getServerSideProps: GetServerSideProps<{ data: DashboardData }> = async (context) => {
  const { req, res, query } = context;

  // 1. 从请求中提取鉴权 Token 或 Cookie
  const token = req.cookies['auth_token'];
  if (!token) {
    return {
      redirect: {
        destination: '/login',
        permanent: false,
      },
    };
  }

  // 2. 串行或并行请求服务端业务 API
  const [userRes, statsRes] = await Promise.all([
    fetch('https://api.internal/user/me', { headers: { Authorization: `Bearer ${token}` } }),
    fetch('https://api.internal/stats/unread', { headers: { Authorization: `Bearer ${token}` } })
  ]);

  if (!userRes.ok) {
    return { notFound: true };
  }

  const user = await userRes.json();
  const { unreadCount } = await statsRes.json();

  // 3. 将序列化后的对象通过 props 注入顶层页面组件
  return {
    props: {
      data: {
        user,
        unreadCount,
        serverTime: new Date().toISOString(),
      },
    },
  };
};

export default function DashboardPage({ data }: InferGetServerSidePropsType) {
  return (
    <main>
      <h1>欢迎回来，{data.user.name}</h1>
      <p>未读提醒：{data.unreadCount} 条</p>
    </main>
  );
}

1.1 核心局限与架构痛点

尽管 getServerSideProps 提供了可预测的服务端执行环境，但在现代复杂前端架构中暴露出以下三项根本瓶颈：

• 页面根节点阻塞与木桶效应：getServerSideProps 只能在 pages/ 顶层路由文件中导出，无法下沉至叶子组件。如果一个页面由“个人信息”、“主体内容”、“侧边栏热门推荐”三个模块组成，哪怕热门推荐可以容忍数小时缓存，由于全部逻辑写在同一个函数中，最慢的那个接口将直接拖死整页的 TTFB（首字节到达时间）。
• 全量重算与缺乏细粒度缓存：Next.js 没有为 getServerSideProps 提供内置的组件级或数据级缓存层。开发者要么手写复杂的 Redis/内存缓存中间件，要么依赖全站 CDN 反向代理；而一旦依赖反向代理，又很难针对登录用户等私有状态做精准局部失效。
• Props 透传链条冗长（Prop Drilling）：所有数据必须由顶层页面作为 Props 层层向深层子组件传递，或借助全局状态管理器初始化，破坏了组件的高内聚与可维护性。

二、App Router 中扩展 fetch 的架构演进与缓存体系

在基于 React Server Components（RSC）的 App Router 中，Next.js 全面扩展了 Web 标准的 fetch API。每个服务端组件均可直接在自身函数体内声明 async/await 并直接调用 fetch，数据获取逻辑与渲染视图实现真正共置。

为了在组件化获取的同时避免重复网络开销，Next.js 构建了分层的多级缓存架构，其中直接参与 fetch 请求判定的核心是请求记忆化（Request Memoization）与数据缓存（Data Cache）。

2.1 React 请求记忆化（Request Memoization）

当多个嵌套的服务端组件（例如根布局 layout.tsx、当前页面 page.tsx 和侧边栏 sidebar.tsx）在同一次服务端渲染中发起完全相同的 GET fetch 调用时，React 底层会自动进行请求去重。仅有第一个组件的调用会真正触发后续管道或网络请求，其余组件将直接复用内存中已解析的数据。该缓存仅存活于当前 HTTP 请求的渲染生命周期中，请求结束即被垃圾回收，无需手动清理。

2.2 Next.js 数据缓存（Data Cache）

不同于生命周期仅限单次请求的记忆化，数据缓存是 Next.js 服务端维护的跨请求、跨部署的持久化数据存储。无论是本地开发环境的文件系统，还是生产环境中的分布式存储，fetch 获取的 JSON 响应均可在此持久化。通过在 fetch 的第二个参数中传入不同的配置选项，开发者可以精确指定数据的持久化与失效策略。

三、新 fetch 缓存策略深度拆解与代码实战

在 App Router 下，数据获取不再使用诸如 getStaticProps 或 getServerSideProps 这样的专用钩子，而是全部收敛于原生 fetch 的配置项中。以下针对四种最核心的缓存策略进行具体讲解。

3.1 强制静态持久缓存：cache: 'force-cache'

cache: 'force-cache' 告知 Next.js 在数据缓存中查找匹配的请求。如果缓存存在且有效，直接返回；如果不存在，则向源服务器发起请求并将返回结果持久化写入数据缓存。这对应了传统架构中的静态生成（SSG）。

// app/docs/[slug]/page.tsx
interface DocPageProps {
  params: { slug: string };
}

export default async function DocPage({ params }: DocPageProps) {
  // 静态缓存：构建时生成并在跨部署期间持久有效
  const res = await fetch(`https://api.cms.internal/docs/${params.slug}`, {
    cache: 'force-cache', // 默认行为（在没有使用动态函数时亦为默认值）
  });

  if (!res.ok) {
    throw new Error('无法拉取文档内容');
  }

  const doc = await res.json();

  return (
    <article>
      <h1>{doc.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: doc.content }} />
    </article>
  );
}

3.2 动态无缓存获取：cache: 'no-store'（对标 getServerSideProps）

如果数据与用户的即时状态强相关（例如用户个人资产、实时股票行情、每次均需验签的订单），应显式指定 cache: 'no-store'。这会告知 Next.js 完全跳过数据缓存，在每次请求到达时均穿透至源端 API，与 getServerSideProps 的行为完全一致。

// app/account/orders/page.tsx
import { cookies } from 'next/headers';

export default async function OrdersPage() {
  const cookieStore = cookies();
  const sessionToken = cookieStore.get('session_id')?.value;

  // 实时动态获取：跳过数据缓存，每次请求都向后端查询
  const res = await fetch('https://api.internal/orders/realtime', {
    method: 'GET',
    headers: {
      Authorization: `Bearer ${sessionToken}`,
      'Content-Type': 'application/json',
    },
    cache: 'no-store', // 核心配置：关闭持久缓存
  });

  if (!res.ok) {
    return <div>暂无订单或会话已过期</div>;
  }

  const orders = await res.json();

  return (
    <section>
      <h2>实时订单列表</h2>
      <ul>
        {orders.map((order: any) => (
          <li key={order.id}>
            订单号：{order.id} | 金额：￥{order.amount} | 状态：{order.status}
          </li>
        ))}
      </ul>
    </section>
  );
}

3.3 基于时间的增量再验证（Time-based ISR）：next: { revalidate: N }

对于数据更新不频繁、但需要定期同步的场景（例如博客首页、商品分类列表、热搜排行榜），可以使用时间戳再验证。传入一个正整数秒数即可激活 Stale-While-Revalidate（SWR）工作机制。

// app/news/page.tsx
export default async function NewsPage() {
  // 60 秒内复用已有缓存；超出 60 秒后的首次请求先返回旧缓存，并在后台静默更新缓存
  const res = await fetch('https://api.internal/news/hot-topics', {
    next: {
      revalidate: 60, // 单位：秒
    },
  });

  const topics = await res.json();

  return (
    <div>
      <h2>热点新闻列表（每分钟异步刷新）</h2>
      <ul>
        {topics.map((t: any) => (
          <li key={t.id}>{t.title}</li>
        ))}
      </ul>
    </div>
  );
}

运行原理：在设定的时间窗口（如 60 秒）内，所有用户请求均秒级命中数据缓存；当 60 秒过后首个请求到达时，Next.js 依然立即向当前用户返回已过期的旧数据（保证极低 TTFB），同时在后台异步启动该 fetch 的刷新任务。一旦源数据拉取成功并解析完毕，数据缓存会被原子更新，后续所有访客即可读取到全新内容。

3.4 基于标签的按需再验证（On-demand Tag Revalidation）

时间戳再验证仍然存在“时滞”：如果文章刚刚在后台被编辑修改，访客可能仍需等待 60 秒甚至数小时才能看到最新版本。App Router 引入了业界领先的 Cache Tags 体系，通过给 fetch 请求打上具名业务标签，实现事件驱动的零延迟精准刷新。

// 1. 在数据获取端绑定 Tag (app/posts/[id]/page.tsx)
export default async function PostPage({ params }: { params: { id: string } }) {
  const res = await fetch(`https://api.cms.internal/posts/${params.id}`, {
    // 永久缓存，直至 posts 标签或该篇专属标签被显式清除
    next: {
      tags: ['posts', `post-${params.id}`],
    },
  });

  const post = await res.json();
  return <article><h1>{post.title}</h1><p>{post.body}</p></article>;
}

// 2. 在业务更新触发端执行失效 (app/api/revalidate/route.ts 或 Server Action)
import { revalidateTag, revalidatePath } from 'next/cache';
import { NextRequest, NextResponse } from 'next/server';

export async function POST(request: NextRequest) {
  const secret = request.headers.get('x-revalidate-secret');
  if (secret !== process.env.CMS_WEBHOOK_SECRET) {
    return NextResponse.json({ message: '未授权访问' }, { status: 401 });
  }

  const body = await request.json();
  const { targetId } = body;

  if (targetId) {
    // 精准失效某篇特定文章的数据缓存
    revalidateTag(`post-${targetId}`);
  } else {
    // 失效全站所有文章列表缓存
    revalidateTag('posts');
  }

  return NextResponse.json({ revalidated: true, timestamp: Date.now() });
}

四、非 fetch 场景的数据缓存方案：React cache() 与 unstable_cache

在实际开发中，并非所有数据均通过 HTTP fetch 获取。例如直接通过 ORM（Prisma、Drizzle）查询 PostgreSQL 数据库，或使用第三方 SDK（如 AWS S3、Firebase）读写资源。此时无法直接享受 fetch 的自动缓存与去重，需要采用配套工具补齐能力：

• 单次渲染去重：React.cache()
  使用 React 内置的 cache 函数包装异步数据库查询，可以为该函数提供针对相同入参的单请求记忆化能力，防止同一渲染树中重复查询数据库。
• 跨请求持久化与 Tag 控制：unstable_cache
  通过 next/cache 导出的 unstable_cache，可以将任意异步函数（包括 ORM 查询）接入 Next.js Data Cache，支持配置 revalidate 秒数及 tags 数组。

// lib/db-queries.ts
import { cache } from 'react';
import { unstable_cache } from 'next/cache';
import { prisma } from './prisma';

// 1. 使用 React cache() 实现单次请求记忆化
export const getUser = cache(async (userId: string) => {
  return await prisma.user.findUnique({ where: { id: userId } });
});

// 2. 使用 unstable_cache 实现跨请求持久化与标签失效
export const getCachedProduct = unstable_cache(
  async (productId: string) => {
    return await prisma.product.findUnique({ where: { id: productId } });
  },
  ['product-detail-key'], // 缓存 Key
  {
    revalidate: 3600, // 默认 1 小时过期
    tags: ['products'], // 支持 revalidateTag('products') 精确失效
  }
);

五、从 getServerSideProps 平滑迁移至 App Router

将存量 Pages Router 页面迁移到 App Router 时，可以遵循以下具体操作步骤与对照关系：

5.1 完整迁移重构对比示例

下面是一个典型的用户个人中心页面在迁移前后的代码比对：

// 【迁移前】：Pages Router (pages/profile.tsx)
export const getServerSideProps: GetServerSideProps = async (ctx) => {
  const token = ctx.req.cookies['token'];
  if (!token) return { redirect: { destination: '/login', permanent: false } };

  const user = await fetchUser(token);
  const notify = await fetchNotifications(token);

  return { props: { user, notify } };
};

export default function ProfilePage({ user, notify }: any) {
  return (
    <div>
      <Header user={user} />
      <Notifications list={notify} />
    </div>
  );
}

// 【迁移后】：App Router (app/profile/page.tsx)
import { Suspense } from 'react';
import { cookies } from 'next/headers';
import { redirect } from 'next/navigation';

// 子组件一：自包含取数逻辑
async function UserProfileSection() {
  const token = cookies().get('token')?.value;
  if (!token) redirect('/login');

  const res = await fetch('https://api.internal/user/me', {
    headers: { Authorization: `Bearer ${token}` },
    cache: 'no-store', // 纯动态私有数据
  });
  const user = await res.json();
  return <header><h1>{user.name}</h1><p>{user.email}</p></header>;
}

// 子组件二：自包含取数并使用 Suspense 解耦加载耗时
async function NotificationsSection() {
  const token = cookies().get('token')?.value;
  const res = await fetch('https://api.internal/notifications', {
    headers: { Authorization: `Bearer ${token}` },
    cache: 'no-store',
  });
  const list = await res.json();
  return <ul>{list.map((item: any) => <li key={item.id}>{item.msg}</li>)}</ul>;
}

export default function ProfilePage() {
  return (
    <main>
      <UserProfileSection />
      <Suspense fallback={<p>正在加载通知提醒...</p>}>
        <NotificationsSection />
      </Suspense>
    </main>
  );
}

六、全景对比与技术选型建议

在设计系统架构时，不同数据获取与缓存模式的核心维度差异如下：

基于上述对比，在技术选型与日常研发中建议遵循以下工程准则：

1. 默认优先考虑按需缓存（Tags）或静态缓存（force-cache）：对于任何全站公共展示型数据（如商品详情、文档、资讯列表），优先使用带 tags 的缓存模式，并在后台 CMS 或管理后台更新时触发 revalidateTag。这是兼顾接近纯静态 CDN 速度与即时一致性的最佳实践。
2. 明确界定私有数据的 no-store 边界：只有在数据强依赖 Cookie、Header、每次必须实时反映账务流水或安全鉴权结果时，才使用 cache: 'no-store'。
3. 合理利用 React Suspense 拆解慢接口：无论采用何种缓存策略，一旦页面包含耗时较长、不可缓存的慢接口，切勿将其与首屏关键数据串行阻塞。将其拆分为独立的 Server Component 并包裹在 <Suspense> 中，使首屏关键结构通过流式渲染毫秒级送达浏览器，显著优化用户实际感知的加载体验。