1.1 什么是 Next.js
1.1 什么是 Next.js
本节摘要：Next.js 是构建在 React 之上的全栈框架。本节从"纯 React 应用有哪些痛点"出发，讲清 Next.js 解决了什么：服务端渲染、文件系统路由、全栈能力一体化。并给出"何时该用 Next.js、何时用 Vite/纯 React"的选型判断。
学习目标
阅读完本节，你应当能够：
- 说出纯 React 应用的三大痛点
- 解释 Next.js 的"全栈一体化"定位
- 区分 Next.js、纯 React（Vite）、传统 MPA（服务端模板）
- 判断自己的项目是否适合 Next.js
问题与直觉：React 能做的，为什么还要 Next.js
如果你写过纯 React 应用（用 Vite 或 CRA 搭建），一定遇到过这几个问题：
痛点一：SEO 无力。 纯 React 是客户端渲染（CSR）——浏览器先拿到一个空壳 HTML，再执行 JS 动态填充内容。搜索引擎爬虫看到的往往只有空壳，页面标题、描述、内容都拿不到。做内容型网站（博客、电商、官网）时这是致命伤。
痛点二：首屏慢。 CSR 的首屏要等 JS 下载、解析、执行完才显示内容。网络差或设备差时，白屏时间很长。
痛点三：前后端两套代码。 React 只解决"视图层"。数据从哪来？需要一个单独的后端（Express/FastAPI）提供 API。两个项目、两套部署、两种技术栈——心智负担与维护成本都翻倍。
直觉类比：纯 React 像"装修公司只卖家具"——你买了家具（组件），还得自己找人盖房子（后端）、自己拉水电（路由与状态管理）。Next.js 是"全包整装"——家具、硬装、水电都给你配齐，你只管提需求（写组件和页面）。
💡 关键直觉：Next.js = React 组件 + 服务端渲染能力 + 文件系统路由 + 内置后端能力（API 路由/Server Actions）。它让"一个框架从页面跑到数据库"成为可能。
核心原理：Next.js 的三大支柱
2.1 服务端渲染（SSR/SSG）
Next.js 让组件可以在服务器上渲染成 HTML，再发给浏览器：
- SSG（静态生成）：构建时把页面渲染成静态 HTML，部署到 CDN，全球秒开；
- SSR（服务端渲染）：每次请求时在服务器渲染，适合需要实时数据的页面；
- ISR（增量静态再生）：静态为主，定期后台更新。
这些渲染方式（第二章 2.1 详解）是 Next.js 区别于纯 React 的根本。
2.2 文件系统路由
在 Next.js 里，文件名就是 URL 路径：
app/ ├── page.tsx → / ├── about/page.tsx → /about ├── blog/[slug]/page.tsx → /blog/xxx（动态路由） └── layout.tsx → 共享布局
不用写路由配置表——放一个文件，就多一个页面。这就是"约定优于配置"。
2.3 全栈一体化
Next.js 内置了后端能力：API 路由（route.ts）、服务器组件、Server Actions（第二章 2.8）——前后端可以在同一个项目、同一套代码里完成，组件直接访问数据库、调用服务端函数，不用再单独维护一个后端项目。
工程实践要点：与纯 React / 传统 MPA 对比
| 维度 | 纯 React（Vite） | Next.js | 传统 MPA（服务端模板） |
|---|---|---|---|
| 渲染方式 | 仅 CSR | CSR/SSR/SSG/ISR 可选 | 服务端模板渲染 |
| SEO | 差 | 好 | 好 |
| 首屏速度 | 慢（JS 依赖） | 快（可预渲染） | 快 |
| 路由 | 手动配置（react-router） | 文件系统约定 | 服务器路由 |
| 后端能力 | 无（需独立后端） | 内置 API/Actions | 同服务端 |
| 交互体验 | 强（SPA） | 强 + 可渐进增强 | 弱（整页刷新） |
| 适合场景 | 管理后台、交互型 SPA | 内容站、电商、全栈应用 | 传统内容站 |
选型判断：
- 需要 SEO、需要全栈、需要快速开发 → Next.js；
- 纯后台系统（无需 SEO，交互复杂，已有后端 API）→ 纯 React（Vite）更轻；
- 简单内容站、团队无 React 经验 → 传统服务端模板即可。
常见误区与排查
| 误区 | 现象 | 正解 |
|---|---|---|
| 以为 Next.js 只能 SSR | 所有页面都实时渲染 | 按需选择 SSG/SSR/ISR |
| 把 Next.js 当纯 SPA 用 | SEO 优势浪费 | 用服务器组件/预渲染 |
| 与 Vite 项目混淆 | 目录结构对不上 | App Router 是文件即路由 |
| 认为必须懂后端 | 望而却步 | 服务端能力从零学即可 |
动手演练：建立渲染模型直觉
打开 Next.js 官方文档或创建示例项目（1.2 会教），观察三种页面：
- 一个静态内容页面——观察构建时被预渲染（
next build输出里标○为静态）； - 一个实时数据页面——观察每次请求都重新渲染（标
ƒ为动态）； - 一个交互组件（如计数器）——观察客户端 JS 被加载执行。
看构建输出的标记（○/ƒ），建立"哪个页面用了哪种渲染"的直觉——这是全书最重要的一张心智地图。
一节小结
- 纯 React 三大痛点：SEO 无力、首屏慢、前后端两套代码。
- Next.js 定位：React 之上的全栈框架，服务端渲染 + 文件路由 + 内置后端能力。
- 渲染方式：CSR/SSR/SSG/ISR 四种，按需选择，这是 Next.js 的根本优势。
- 文件系统路由：文件名即 URL，约定优于配置。
- 全栈一体化：组件可直接访问服务端资源，一个项目从页面跑到数据库。
- 选型：需 SEO/全栈用 Next.js；纯后台用纯 React 更轻。
深入理解：Next.js 的版本演进与定位
了解 Next.js 的历史能帮你理解它为什么长这样：
Pages Router 时代（Next.js 9-12）：路由在 pages/ 目录，数据获取用 getServerSideProps/getStaticProps，组件默认客户端。这套体系让 Next.js 从"SSR React 框架"站稳脚跟。
App Router 时代（Next.js 13+）：路由移到 app/ 目录，引入服务器组件（默认服务器渲染）、布局系统、流式渲染、Server Actions。这是一次"范式升级"——从"客户端为主、服务端补充"变为"服务端优先、客户端按需"。
为什么这次升级重要：它让"全栈"从"前端调后端 API"进化为"组件直接访问服务器能力"。数据库查询、密钥使用、表单处理都变得更直接、更安全。
定位再确认：Next.js 不是"又一个 React 脚手架"——它是 React 之上的应用框架，提供路由、渲染、数据、部署的全套约定。用 React 是"造轮子"，用 Next.js 是"开车"——前提是你会开车（懂 React 基础）。
一句话总结：理解 Next.js 的演进 = 理解"服务端优先"的必然性。SEO、性能、安全、开发效率——四个维度都指向"能服务器渲染就服务器渲染"。这个认知贯穿全书。