引言：为什么 Next.js 会成为 React 生态的首选？
从 2016 年首次发布至今，Next.js 已从简单的“React SSR 框架”进化为集服务端渲染、静态生成、API 路由、文件系统路由、全栈开发能力于一体的综合性框架。截至 2026 年，它已成为构建生产级 React 应用的事实标准。
1.1 React 的局限性
React 本身是一个 UI 库，而非完整框架。当用它构建实际应用时，你会遇到以下核心痛点：
|
痛点 |
具体表现 |
|
路由系统 |
React 本身没有路由方案，需依赖 React Router 等第三方库配置管理 |
|
SEO 不友好 |
纯客户端渲染的 SPA 中，搜索引擎爬虫难以抓取动态生成的内容 |
|
性能问题 |
首屏需下载全部 JavaScript 后才能渲染，导致白屏时间过长 |
|
构建配置复杂 |
从零配置 Webpack、Babel、TypeScript、图片优化等非常耗时 |
|
数据获取混乱 |
没有统一的客户端/服务端数据获取模式 |
|
图片/字体优化 |
需手动处理图片懒加载、响应式、格式转换等 |
1.2 Next.js 的解决方案
Next.js 是一套“开箱即用”的 React 全栈框架，它以约定优于配置的哲学整合了以下能力：
┌─────────────────────────────────────────────────────────┐
│ Next.js │
├─────────────┬─────────────┬─────────────┬───────────────┤
│ 文件路由 │ SSR/SSG │ API 路由 │ 构建优化 │
│ 自动配置 │ 按需渲染 │ 开箱即用 │ Turbopack │
├─────────────┼─────────────┼─────────────┼───────────────┤
│ 图片优化 │ 字体优化 │ 中间件 │ 环境变量 │
│ 自动处理 │ 自动处理 │ 灵活拦截 │ 类型安全 │
└─────────────┴─────────────┴─────────────┴───────────────┘
二、核心概念：理解 Next.js 的三块基石
在深入代码之前，先建立对 Next.js 核心架构的宏观认识：
2.1 渲染模式体系
Next.js 将多种渲染模式统一到单个框架中，允许在页面级别灵活选择最优策略：
|
渲染模式 |
全称 |
工作原理 |
适用场景 |
SEO |
首屏速度 |
|
SSG |
Static Site Generation |
构建时预生成静态 HTML |
文档、博客、营销页 |
✅ 完美 |
最快 |
|
SSR |
Server-Side Rendering |
每次请求在服务器动态渲染 |
个性化页面、实时数据 |
✅ 优秀 |
中等 |
|
ISR |
Incremental Static Regeneration |
静态生成 + 后台增量更新 |
周期性更新内容 |
✅ 优秀 |
快 |
|
CSR |
Client-Side Rendering |
客户端渲染空壳 + 动态取数 |
管理后台、高交互应用 |
❌ 较差 |
慢 |
|
PPR |
Partial Prerendering |
静态外壳 + 流式动态内容 |
混合型页面 |
✅ 优秀 |
最快 |
在 App Router 中，默认采用静态渲染（SSG）策略，但如果组件中使用动态函数或主动禁用缓存，框架会自动切换至动态渲染（SSR）。ISR（增量静态再生）可通过设置
