Next.js 的架构、运行与数据流

00定位与心智模型

面试官问"Next.js 是什么"，最差的答案是"一个 React 框架"。这句话对，但什么都没说。准确的定位是：

三个层次理解它

要真正"懂"Next.js，得在脑子里分清它同时扮演的三个角色。这三层贯穿全文，建议先记住：

版本演进：为什么现在长这样

理解架构必须知道它"从哪来"。这条演进线本身就是高频面试题：

01整体架构：一次请求看穿全貌

先建立"上帝视角"。下面这张图是 Next.js 处理一个页面请求时，各个子系统的协作关系。后面每一章，本质上都是在放大其中某一块。

把这张图拆开，本文的章节其实就是沿着这条流水线展开的：路由匹配（第 5 章）→ RSC 渲染（第 2 章）→ SSR 流水线 + Streaming（第 7、8 章）→ 数据与缓存（第 10、11 章）→ 回到客户端的 水合与导航（第 9 章）。而第 13、14 章专门讲流水线里流动的"数据结构"是什么样子。

关键架构原则：服务端优先，按需下沉到客户端

App Router 的所有设计都围绕一条原则：默认在服务端做尽可能多的事，只把必须交互的部分下放到客户端。 这条原则带来三个直接结果——默认更少的客户端 JS、组件可以直接访问后端资源、数据获取就在组件内联完成。理解了这条原则，后面 RSC、边界、缓存的种种约定就都顺理成章了。

02React Server Components：渲染内核

RSC 是 App Router 的地基。如果只能记住一个概念，就是它。

它到底是什么

React Server Components 是一类只在服务端运行、永远不会被打包进客户端 JS 的组件。 在 App Router 里，组件默认就是 Server Component，除非你显式声明 "use client"。

Server Component 能做与不能做

app/posts/page.tsx — Server Component（默认）
// 没有 "use client"，这就是一个服务端组件
// 注意它是 async 的，可以直接 await 数据 —— 这是 RSC 才有的能力
export default async function PostsPage() {
  // 直接读数据库 / 调内部服务，代码不会下发到浏览器
  const posts = await db.post.findMany({ orderBy: { createdAt: 'desc' } })

  return (
    <ul>
      {posts.map((p) => (
        <li key={p.id}>{p.title}</li>
      ))}
    </ul>
  )
}

RSC 的输出不是 HTML，而是"RSC Payload"

这是最容易答错的点。Server Component 渲染的产物不是直接的 HTML 字符串，而是一种 React 专用的序列化格式，常被称为 RSC Payload 或 Flight 数据。它本质上是一棵被序列化的 React 元素树，里面包含：

• Server Component 渲染出来的结果（已经"算好"的元素树）；
• 遇到 Client Component 的地方，不内联代码，而是放一个模块引用（reference）——告诉客户端"这里要挂载哪个 chunk 里的哪个组件"；
• 从服务端传给 Client Component 的 props（必须可序列化）；
• Suspense 边界的占位与后续补发的分块（用于 Streaming）。

这个 payload 有两个用途：① 服务端用它生成初始 HTML（首屏）；② 同时把 payload 本身也发给客户端，客户端据此水合，并在后续导航时复用。第 13 章会详细拆 payload 的结构。

03Server / Client 边界

整棵组件树被 "use client" 切成两个世界。理解"边界画在哪、props 怎么穿过去"是 App Router 工程实践的核心，也是面试常考的"原理 + 实践"结合题。

"use client" 是一道传染性的边界

"use client" 写在文件顶部，含义是：从这个模块开始，它以及它 import 进来的所有模块，都进入客户端世界。 它标记的是"进入客户端的入口点"，而不是"只有这个组件是客户端"。

关键规则：Server 可以包 Client，Client 不能直接 import Server

数据流方向决定了组合方式。下面这三条是必背规则：

1. Server Component 可以渲染 Client Component（在树里把客户端组件当子节点）。
2. Client Component 不能直接 import 一个 Server Component——因为 Client 的代码要打包进浏览器，而 Server Component 本不该出现在浏览器。
3. 但可以通过 children / props 把 Server Component "插槽"进 Client Component。这是绕过上一条限制的标准姿势。

把 Server Component 作为 children 传进 Client Component
// ✅ 正确：服务端组件作为 children 注入客户端组件
// app/page.tsx (Server)
import ClientWrapper from './client-wrapper'      // client
import ServerData from './server-data'            // server

export default function Page() {
  return (
    <ClientWrapper>
      {/* ServerData 在服务端渲染好，作为 RSC payload 的一部分 */}
      {/* 被"投影"进客户端组件的插槽里，客户端拿到的是渲染结果而非源码 */}
      <ServerData />
    </ClientWrapper>
  )
}

实践：把 "use client" 推到叶子节点

性能上的最佳实践是让边界尽量靠近叶子。一个常见反模式是在根布局上写 "use client"，结果整棵树都变成客户端，RSC 的优势荡然无存。正确做法：只把真正需要交互的那一小块（按钮、表单输入、带动画的卡片）标成客户端，其余保持服务端。

04编译与构建架构

这一章回答"你的代码是怎么变成能跑的东西的"。面试里属于加分项——能讲清工具链说明你懂底层。

工具链分工

核心机制：一份代码，两份产物

这是构建阶段最关键的认知。因为有 Server/Client 之分，构建器会从你的代码生成两套 bundle：

构建器以 "use client" 标记的模块为分界：边界以上（含 Server Components）进入服务端图，不打包给浏览器；边界以下进入客户端图，做代码分割后输出到 static/chunks。RSC payload 里对 Client Component 的"模块引用"，指向的就是客户端图里对应的 chunk。

next build 都做了什么

• 编译：SWC 把所有 TS/JSX 转译成可执行 JS。
• 打包与分割：Turbopack 构建依赖图，按路由做代码分割（每个路由只加载自己需要的 chunk）。
• 预渲染（prerender）：对可静态化的路由，在构建时就跑完 RSC + SSR，产出静态 .html 和对应的 .rsc（RSC payload 快照）。
• 生成清单（manifests）：把"哪个路由对应哪些文件、哪些是静态/动态、入口 chunk 是什么"等元信息写成一堆 JSON（第 14 章详解）。
• 优化：tree-shaking、minify、图片/字体处理等。

05路由系统：文件即路由

Next.js 用文件系统约定来表达路由——目录结构就是路由结构，特殊文件名承担特殊角色。这是"开发者界面"层最直观的部分，也是数据结构层"路由树"的来源。

约定式特殊文件

在 app/ 下，每个目录代表一个路由段（route segment），目录里的特殊文件决定这一段的行为：

这些文件如何"组装"成一个页面

关键认知：同一路由的特殊文件会按固定顺序嵌套包裹起来。 Next.js 渲染一个路由时，自动生成这样一棵包裹树：

特殊文件的嵌套顺序
<Layout>
  <Template>
    <ErrorBoundary fallback={<Error />}>
      <Suspense fallback={<Loading />}>
        <ErrorBoundary fallback={<NotFound />}>
          <Page />
        </ErrorBoundary>
      </Suspense>
    </ErrorBoundary>
  </Template>
</Layout>

嵌套布局：路由树天然分层

目录嵌套天然形成布局嵌套。app/layout.tsx 包裹一切，app/dashboard/layout.tsx 只包裹 dashboard 子树。导航到 /dashboard/settings 时，只有变化的最深层段会重新渲染，外层布局原地不动——这是性能与体验的关键。

动态路由与高级路由约定

app/blog/[slug]/page.tsx — 动态路由读参数（注意 params 现在是 async）
// Next 16：params / searchParams 都是 Promise，必须 await
export default async function BlogPost({
  params,
}: {
  params: Promise<{ slug: string }>
}) {
  const { slug } = await params
  const post = await getPost(slug)
  return <article>{post.title}</article>
}

// 静态预渲染：告诉构建器要为哪些 slug 生成静态页
export async function generateStaticParams() {
  const posts = await getAllPosts()
  return posts.map((p) => ({ slug: p.slug }))
}

路由系统在内存里：路由树（Route Tree）

所有这些文件约定，最终被 Next.js 解析成一棵路由树。每个节点是一个 route segment，携带该段的 layout / page / loading / error 引用、是否动态、参数名等。这棵树既用于服务端匹配请求，也用于客户端导航时定位"哪一段变了"。它的数据结构形态见第 13 章。

06渲染策略全景：SSG / SSR / ISR / CSR / PPR

这是 Next.js 面试的"必考大题"。先把五种策略一次性摆清楚，再讲它们在 App Router 里如何统一到一个模型下。

App Router 如何把这些统一起来

在经典 Pages Router 里，渲染策略是页面级的（由你导出 getStaticProps 还是 getServerSideProps 决定）。App Router 把粒度下沉到组件 / 数据级，并在 Next 16 的 Cache Components 模型下统一成一句话原则：

具体而言，决定某段是静态还是动态的因素：

• 标了 use cache（配合 cacheLife）→ 可被预渲染、缓存复用 → 走静态/ISR 语义。
• 读取了请求特定数据（cookies() / headers() / 动态 searchParams）→ 只能请求时算 → 动态。
• 未缓存的数据访问被 <Suspense> 包裹 → 成为"动态洞"，壳先发、它流式补上 → PPR。

07SSR 渲染流水线：从请求到屏幕

把第 6 章的"策略"落到"过程"。一次动态请求，HTML 是怎么一步步出现在用户屏幕上的？这是把 RSC、SSR、Streaming、Hydration 串起来的关键一章。

逐步拆解

① 路由匹配。 服务端拿到 URL，在路由树里定位命中的 segments，组装出第 5 章那棵"layout→…→page"的包裹树。

② 运行 RSC。 服务端执行所有 Server Components。async 组件在这里 await 数据。产物是 RSC Payload——元素树 + Client 组件的模块引用 + 序列化 props。

③ SSR 转 HTML。 React 把 payload 转成 HTML 字符串。这一步让首屏不依赖 JS 就能显示，对 SEO 和首屏速度至关重要。

④ Streaming。 关键优化：HTML 不是等全部算完才发，而是边算边发。能立即确定的"静态壳"先发出去；被 <Suspense>（或 loading.tsx）包裹、还在等数据的部分先发 fallback 占位，数据 ready 后再把真实内容作为后续 chunk 补发，浏览器原地替换占位。

⑤–⑧ 客户端接管。 浏览器边收边渲染首屏（用户很快看到内容）；同时按 payload 里的模块引用下载交互组件的 JS chunk；然后进行水合——把已有的静态 HTML"激活"，给客户端组件接上事件监听与状态，不重新创建 DOM。水合完成，页面完全可交互。

08PPR：部分预渲染（静态壳 + 动态洞）

PPR 是把第 6、7 章的能力推到极致的产物，也是 Next 现代架构的"招牌"。Next 16 通过 cacheComponents 让它成为常态行为。

核心思想：一页 = 一个静态壳 + 若干动态洞

传统模型里一个页面要么整页静态、要么整页动态。PPR 打破这点：把页面里能静态确定的部分（导航栏、布局、产品标题）在构建时预渲染成静态壳，可直接走 CDN 秒开；把个性化/实时的部分（购物车数量、推荐、库存）留作"动态洞"，用 <Suspense> 包起来，在请求时流式填充。

next.config.ts — 开启 Cache Components（含 PPR 行为）
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  cacheComponents: true, // 启用：默认动态 + use cache 才静态 + PPR 默认
}
export default nextConfig

app/product/[id]/page.tsx — 同页混合静态与动态
import { Suspense } from 'react'

// 静态片段：标了 use cache，可预渲染进壳
async function ProductInfo({ id }: { id: string }) {
  'use cache'
  const product = await getProduct(id) // 缓存复用
  return <h1>{product.name}</h1>
}

// 动态片段：读实时库存，无缓存 → 成为动态洞
async function LiveStock({ id }: { id: string }) {
  const stock = await getStock(id) // 每次请求真实查询
  return <span>剩余 {stock} 件</span>
}

export default async function Page({
  params,
}: { params: Promise<{ id: string }> }) {
  const { id } = await params
  return (
    <div>
      {/* 静态壳的一部分，秒出 */}
      <ProductInfo id={id} />
      {/* 动态洞：壳先发，骨架占位，数据好了再流式替换 */}
      <Suspense fallback={<StockSkeleton />}>
        <LiveStock id={id} />
      </Suspense>
    </div>
  )
}

09客户端导航：软导航与 Router Cache

首屏之后，应用就变成了 SPA。理解"客户端导航时到底请求了什么"，是区分初级与中级的分水岭。

软导航：只取变化段的 RSC Payload

用 <Link> 或 useRouter() 在应用内跳转时，不会请求整页 HTML，也不会刷新浏览器。Next 客户端路由器做的是：

1. 对比当前路由树与目标路由树，算出哪些 segment 变了；
2. 只向服务端请求变化段的 RSC Payload（不是 HTML）；
3. 把新 payload 与保留的布局拼接，局部更新 UI；外层 layout 及其状态原地保留。

Router Cache：客户端的内存缓存

客户端有一个内存中的 Router Cache（也叫 Client-side Router Cache），按路由段缓存已获取的 RSC payload。它带来两个效果：前进/后退秒回（命中缓存不再请求）、预取（prefetch）——视口内的 <Link> 会被自动预取其 payload，点击时几乎瞬开。

客户端导航的两种姿势
// 声明式：视口内自动预取 payload
import Link from 'next/link'
<Link href="/dashboard/billing">账单</Link>

// 命令式
'use client'
import { useRouter } from 'next/navigation'
const router = useRouter()
router.push('/dashboard/billing')   // 软导航
router.refresh()                    // 重取当前路由的 server 数据并合并

10数据获取与缓存模型

这是 Next.js 区别于纯前端框架的灵魂，也是面试最能拉开差距的部分。我们分"读"（本章）与"写"（下一章 Server Actions）两条线。

读路径：在组件里直接取数据

App Router 的数据获取哲学是"数据获取下沉到需要它的组件，且优先在服务端完成"。Server Component 是 async 的，直接 await 即可——不需要 getServerSideProps 那种页面级钩子。

服务端组件内联取数（最常见）
async function UserProfile({ id }: { id: string }) {
  // 直接调数据库 / 内部服务 / fetch，代码不下发浏览器
  const user = await db.user.findUnique({ where: { id } })
  return <h2>{user.name}</h2>
}

四类缓存：先认清各自管什么

"缓存"在 Next.js 里不是一个东西，而是分布在不同层、生命周期不同的几套机制。这是面试的"深水区"，务必分清：

Next 16 的新缓存模型：Cache Components

Next 16 用 Cache Components 重塑了上面的"服务端持久缓存"那部分。核心是三个新原语，配合 cacheComponents: true 使用：

use cache + cacheLife + cacheTag 三件套
import { cacheLife, cacheTag } from 'next/cache'

async function ProductCard({ id }: { id: string }) {
  'use cache'                 // 标记可缓存
  cacheLife('hours')          // 缓存按"小时"档过期/再验证
  cacheTag(`product-${id}`)   // 打标签，便于精准失效
  const product = await db.product.findById(id)
  return <ProductDetail product={product} />
  // id 作为入参，自动成为缓存键的一部分：
  // 不同 id 命中不同缓存条目
}

失效：让缓存"过时"

缓存的另一半是"如何让它失效"。数据变更（通常在 Server Action 里）后调用：

• revalidateTag('product-42') —— 失效所有打了该标签的缓存条目（精准、推荐）。
• revalidatePath('/products') —— 失效某路径相关缓存。
• updateTag('...') —— 较新 API，在当前这次变更后立即让对应内容在本次渲染中更新（更强的即时一致性）。

11Server Actions：数据变更（写路径）

读路径之外，App Router 用 Server Actions 统一了"写"。它让你在客户端直接调用一个运行在服务端的函数，无需手写 API 路由。

本质：编译器生成的安全 RPC

带 "use server" 标记的函数，会被编译器处理成一个可从客户端安全调用的服务端端点。客户端调用它时，实际是发起一个 POST 请求，参数被序列化送到服务端执行，结果（或副作用）再返回。你写起来像调一个本地异步函数，底层是 RPC。

app/actions.ts — 定义 Server Action
'use server'                      // 整个文件的导出都是 Server Action
import { revalidateTag } from 'next/cache'
import { redirect } from 'next/navigation'

export async function createPost(formData: FormData) {
  const title = formData.get('title') as string
  // 直接在服务端写库（安全，代码不下发）
  await db.post.create({ data: { title } })

  // 写完让相关缓存失效，UI 拿到新数据
  revalidateTag('posts')
  redirect('/posts')              // 也可重定向
}

在表单中使用 — 支持渐进增强（无 JS 也能提交）
import { createPost } from './actions'

export default function NewPost() {
  return (
    // 把 action 直接绑到 form，提交即调用服务端函数
    <form action={createPost}>
      <input name="title" />
      <button type="submit">发布</button>
    </form>
  )
}

Server Action 的完整数据流

12数据流全链路：把一切串起来

这一章是全文的"会合点"。我们把前面的零件拼成一张完整的数据流图，覆盖读（首屏→交互）与写（变更→回流）两个方向。能把这张图讲顺，原理题基本稳了。

读方向（首屏）一句话串联

数据源 →（经缓存层去重/复用）→ Server Component await 取数 → 产出 RSC Payload → SSR 转 HTML 并 Streaming → 浏览器首屏直出 → 下载 chunk → 水合 → 可交互。

读方向（软导航）一句话串联

用户点 <Link> → 客户端路由器算出变化段 → 只请求该段的新 payload（命中 Router Cache 则直接用）→ 与保留布局拼接 → 局部更新。

写方向一句话串联

用户提交 → Server Action 序列化参数 POST 到服务端 → 服务端执行写操作 → revalidateTag/Path 失效相关缓存（服务端 Data Cache + 客户端 Router Cache）→ 服务端重渲生成新 payload 回传 → 客户端局部更新，UI 反映最新数据。

13核心数据结构

前面流水线里"流动"的东西，落到具体形态就是这几个数据结构。把它们的形状、职责、生命周期记清楚，是回答"有哪些重要数据结构"的标准答案。

① 路由树 / 路由段（Route Tree / Segment）

文件约定被解析成一棵树，每个节点是一个 segment。它是服务端匹配请求和客户端定位变化的共同依据。概念上每个节点大致携带：

路由段节点（概念形态）
type RouteSegment = {
  name: string                 // 段名，如 'dashboard'、'[id]'
  type: 'static' | 'dynamic' | 'catch-all' | 'group'
  layout?: ComponentRef        // 该段的 layout.tsx
  page?: ComponentRef          // page.tsx
  loading?: ComponentRef       // loading.tsx（→ Suspense fallback）
  error?: ComponentRef         // error.tsx（→ ErrorBoundary）
  children: RouteSegment[]     // 子段
  params?: string[]            // 动态参数名，如 ['id']
}

② RSC Payload（Flight 数据）—— 最核心

这是整个体系的"血液"：Server Component 渲染的序列化产物，既用于生成 HTML，也发给客户端用于水合与导航复用。它是一个流式的、分行的序列化结构，概念上每一"行"是一个带 id 与类型标记的条目：

③ Router Cache（客户端路由缓存）

浏览器内存里的一份缓存，按路由段为键存储已获取/预取的 RSC payload。生命周期是当前会话（刷新即清）。它支撑前进后退秒回与 <Link> 预取。概念形态：

Router Cache（概念形态）
// 以路由段路径为键，缓存对应的 RSC payload 与状态
type RouterCache = Map<
  string,                       // segment key，如 '/dashboard/billing'
  {
    payload: RSCPayload         // 该段的渲染数据
    prefetched: boolean         // 是否由 Link 预取
    timestamp: number           // 用于判定新鲜度
  }
>

④ Build / Prerender 产物

构建期对静态路由生成的快照，存在 .next 里：每个可静态化路由一份 HTML + 一份 .rsc（RSC payload 快照）+ 元数据。运行时静态请求直接吐这些文件，ISR 再生时在后台更新它们。第 14 章细看。

14构建产物与清单文件

这一节"很实在"——讲 next build 后磁盘上到底有什么。知道这些，部署、调试、自托管时才不慌，也是面试加分细节。

.next 目录结构（概念）

.next/（生产构建产物，简化）
.next/
├─ server/                 # 服务端运行的产物
│  ├─ app/                 #   各路由的服务端模块、预渲染 .html / .rsc
│  ├─ chunks/              #   服务端代码分块
│  └─ *-manifest.json      #   服务端用的各种清单
├─ static/                 # 发给浏览器的静态资源
│  ├─ chunks/              #   客户端 JS 分块（含 use client 组件）
│  └─ css/                 #   样式
├─ cache/                  # 构建/数据/图片等缓存
└─ *-manifest.json         # 顶层清单（见下表）

关键清单文件（Manifests）

清单是一堆 JSON，记录"路由↔文件↔chunk"的映射与元信息，让运行时能快速找到该加载什么。常见的：

15proxy.ts / 中间件

在请求进入路由渲染之前，有一道可编程的"关卡"。Next 16 把它从 middleware.ts 改名并改造为 proxy.ts。

它是什么、能干什么

这道关卡在请求抵达页面渲染之前运行，对所有匹配的请求生效。典型用途：鉴权拦截、重定向、URL 重写、A/B 分流、注入/改写请求与响应头、地理或语言路由。它不渲染 UI，只做"请求路由层"的决策。

proxy.ts（项目根）
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export function proxy(request: NextRequest) {
  const token = request.cookies.get('session')?.value
  // 未登录访问后台 → 重定向到登录页
  if (!token && request.nextUrl.pathname.startsWith('/dashboard')) {
    return NextResponse.redirect(new URL('/login', request.url))
  }
  return NextResponse.next() // 放行
}

// 只对匹配的路径运行，避免拦截静态资源
export const config = {
  matcher: ['/dashboard/:path*', '/account/:path*'],
}

16完整请求生命周期（总装）

把所有零件按时间顺序装成一条线。这是面试"讲讲一个请求的完整过程"的标准答题脚本。

1. 发起：地址栏输入或应用内导航产生请求。
2. proxy.ts：边缘/Node 关卡先处理——可重定向（如未登录）、重写、改 header，或直接放行。
3. 路由匹配：在路由树定位命中的 segments，组装 layout→…→page 的包裹树。
4. 缓存检查：若该路由/片段有可用静态快照或缓存命中，直接复用，跳过重渲。
5. RSC 渲染：运行 Server Components，await 数据（受缓存层去重/复用），产出 RSC Payload；Client 组件以模块引用形式占位。
6. SSR + Streaming：payload 转 HTML，静态壳先发，Suspense 包裹的动态洞发 fallback、数据 ready 后补发。
7. 浏览器首屏：边收边画，用户快速看到内容（不依赖 JS）。
8. 下载与水合：按 payload 引用拉取客户端 chunk，水合激活交互。
9. 进入 SPA：之后导航走客户端软导航，只取变化段 payload，命中 Router Cache 则秒回。
10. 变更回流：用户操作触发 Server Action → 服务端写 + 失效缓存 → 回传新 payload → 局部更新。

17项目工程化要点

实际项目里除了原理，还有一组"做对就省心"的工程实践，面试也常顺带问。

推荐项目结构

典型 App Router 工程布局
src/
├─ app/                    # 路由与页面（约定式）
│  ├─ layout.tsx           #   根布局
│  ├─ page.tsx
│  ├─ (marketing)/         #   路由组：组织而不入 URL
│  ├─ dashboard/
│  │  ├─ layout.tsx
│  │  └─ page.tsx
│  └─ api/                 #   Route Handlers（对外接口）
├─ components/             # 共享组件（区分 server/client）
├─ lib/                    # 数据访问、工具、db 客户端
├─ actions/                # Server Actions（"use server"）
└─ proxy.ts                # 请求关卡

环境变量与密钥

• 仅 NEXT_PUBLIC_ 前缀的变量会被打进客户端 bundle；密钥绝不要加该前缀。
• Server Component / Action 里可以直接读私有环境变量与 DB——因为它们不下发浏览器。这正是 RSC 的安全优势之一。

性能优化清单（高频问）

18面试速记 Q&A

把全文压缩成可以快速过的问答。点击问题看要点（也可直接通读）。这些覆盖了 Next.js 面试的绝大多数原理题。