Next.js 教程 · 起点

Next.js App Router：从 React 到服务端组件

这是一份概念向的深挖教程，写给会 React、没用过 Next.js 的工程师。目标不是教你调 API，而是重建一个被 React Server Components 改写过的心智模型。

基于：Next.js 16.2 / React 19（2026 年初） 阅读时间：约半天（深挖） 代码状态：示例为讲解性片段，阐明概念与 API 形态，未逐一在本机运行

·适合谁

这份教程假设你已经具备以下三项能力。三项都满足，阅读会很顺畅；缺一项，对应章节会偏吃力。

  • 能用 React 函数组件 + Hooks（useState / useEffect / useContext）写出带交互的页面，理解受控组件与 props 单向流动。
  • 清楚浏览器端渲染（CSR / SPA）的基本链路：HTML 空壳 → 下载 JS bundle → 执行 → 渲染 → 事件绑定。这条链路是后面理解"服务端渲染省掉了哪一段"的对照基线。
  • 用过 npm 或 pnpm，能读 TypeScript 的类型签名（不要求精通 TS）。

·不适合谁

如果你属于下面任一种，先去更合适的地方，再回来。

  • 没写过 React：服务端组件是建立在 React 组件模型之上的概念。先过一遍 react.dev 官方教程。
  • 只想要能跑的脚手架：直接 npx create-next-app，照 官方 Getting Started 抄。这份教程讲的是"为什么"，不是"怎么起项目"。
  • 在维护 Pages Router 老项目、只想查某个 API：去 官方文档 或 App Router 迁移指南。本教程默认讲 App Router，不覆盖 getServerSideProps 那套旧模型。

·读完之后你能做到什么

读完之后，看到一段 Next.js 代码，你不再纠结"这放服务端还是客户端"，而是先问"'use client' 这条网络边界该划在哪"，再问"哪些数据值得显式缓存"——因为 App Router 里渲染、数据、缓存的几乎所有决策，都是这条边界的位置加上你的显式缓存声明推导出来的结果。

具体的、可验证的能力：

  • 拿到任意一个组件，判断它该是 Server 还是 Client Component，并说清 'use client' 会把哪些代码推进客户端 bundle、哪些 props 因此必须可序列化。
  • 给定一种页面（营销页 / 个人仪表盘 / 电商商品页 / 个性化信息流），选出 static、dynamic、streaming、Cache Components 里正确的渲染策略，并讲出依据。
  • 诊断三类高频问题——"改了数据库页面不刷新""整页突然变慢""hydration mismatch 报错"——定位到是四层缓存里的哪一层，还是边界划错了。
  • 为一次写操作在 Server Action 与 Route Handler 之间选对工具，并在写完后正确地让相关缓存失效。
  • 读懂 Next.js 16 的缓存模型，区分三代默认行为：v14 隐式缓存 fetch → v15 默认全关 → v16 'use cache' 显式开启。

一句话本质

组件默认在服务器上运行，把一段"UI 描述"（RSC payload）流式发给浏览器；'use client' 不是文件位置，而是一条网络边界——它划定 JS、状态、交互从哪里开始。路由、渲染、数据、缓存，本质上都是"这条边界落在哪"以及"你显式缓存了什么"的结果。

现状速览 · 截至 2026 年初

稳定的核心：RSC、'use client' 边界、文件系统路由——自 Next 13–14 起已稳定，是这份教程的主干。

正在变 / 刚翻转的：缓存模型在 v15→v16 发生根本翻转。v14 默认缓存 fetch，v15 默认全部关闭，v16 改为 'use cache' 显式开启（Cache Components，PPR 默认开启）。同期：Turbopack 成为 dev + build 默认打包器；middleware.ts 改名 proxy.ts（Node 运行时，旧名废弃保留给 Edge）；cookies() / headers() / params / searchParams 全部改为 async、必须 await。

已被取代的旧做法：getServerSideProps / getStaticProps（Pages Router）、隐式 fetch 缓存、experimental.ppr 旗标（已移除并入 Cache Components）、next lint、AMP——读到老教程里这些，要警惕。

关于"为什么学"的假设

这份教程假设你学 Next.js 是为了构建真实应用的前端 / 全栈，并兼顾面试准备。因此重心放在"建立可迁移的判断力"，而非某个 API 的逐项参数。如果你只是评估选型，直接看 概念地图 和 07 自测 的判别题即可。

先承认一件事 · 读得顺 ≠ 学会了

RSC 这套模型对 React 老手反直觉。这份教程会在关键处要求你停下来预测、自测、动手画图——别跳过，那些"卡顿"正是学习在发生。三个要警惕的自我欺骗信号：

「我读得很顺」——顺往往是"熟悉"而非"学会"。越反直觉的东西（比如 props 为什么必须可序列化），读着越顺，越要当心是没真卡进脑子。
「我做题很快」——多半是在做见过的题型，换个场景就卡。
「我没卡壳」——没卡壳常常意味着没碰到真正的 schema。

·概念地图

App Router 的全部内容挂在六根支柱上，而六根支柱共享同一个中心——组件默认在服务端渲染。先把这张图记住，后面每一章都是在给某一根支柱补细节。

默认服务端 组件里 await 段 = 文件夹 静态 ↔ 动态 写完重新验证 显式 opt-in App Router 心智模型 组件模型 Server / Client 边界 文件路由 page / layout 渲染 static / stream 变更 Server Actions 数据获取 async 组件 缓存 'use cache'
图 0App Router 的六根支柱挂在同一个中心。注意：组件模型（朱红）是其余五项的源头——渲染、数据、缓存、变更的每个决策，最后都回到"'use client' 边界划在哪"。

·学习路径建议

顶部的 breadcrumb 就是默认线性路径。按目标也可以走捷径：

  • 最快建立心智模型起点 → 02 组件 → 03 渲染 → 07 自测。先抓住边界与渲染这两块反直觉的硬骨头。
  • 系统学一遍 · 推荐从 01 到 07 顺序读。每章末尾的自测做完再往下。
  • 带读他人代码 / Code Review02 组件 → 05 缓存 → 06 变更。边界、缓存、写操作是 Next 代码最容易出错的三处。
  • 选型 / 面试准备02 + 03 + 07 的判别题。重点是"何时用哪种渲染"和"边界怎么划"的判断力。

·目录

01文件系统路由 · URL 就是文件夹树；layout 嵌套且导航时不重渲染；动态段、路由组、平行与拦截路由 02服务端组件与 'use client' 边界 · 默认 Server；边界的本质是网络边界；RSC payload / Flight 机制；为什么函数不能跨界 03渲染：静态、动态与流式 · 一个路由默认静态，碰到请求数据就转动态；Suspense 是流式单元；PPR / Cache Components 04数据获取 · 数据在组件树里取；async 组件与 await；瀑布 vs 并行；请求记忆化 05缓存模型与它的三代翻转 · 四层缓存；v14→v15→v16 默认行为变迁；'use cache'、revalidateTag / revalidatePath 06变更：Server Actions 与 Route Handlers · 变更是加密的 RPC 端点；写完必须 revalidate；两种工具如何选 07自测题库与判别场景 · 三层梯度题；跨章节"该选哪个方案"的场景判别；亲手画架构图

·学完之后

这份教程聚焦 App Router 的核心模型。学完之后，下面几个方向各自给你的 schema 添一块：

  • 数据层：在 Server Components 里直接接 ORM（Prisma / Drizzle）和数据库——给"数据在组件树里取"补上真实数据源。
  • 认证与授权：Auth.js 或自建 session，配合 proxy.ts 做路由级鉴权——给"边界"补上"谁能跨过它"。
  • 性能：React Compiler、PPR 调优、bundle 分析——给"渲染"补上量化的优化手段。
  • 部署：Vercel 托管 vs 自托管（standalone 输出、Node 运行时差异）——给整套模型补上"它最终跑在哪"。