Next.js 是什么：React 之上的全栈 Web 框架

学习资源：Next.js 官网、Next.js Docs、Learn Next.js，以及一个入门视频链接。视频页面这次没有成功抓取到正文或字幕，所以我先把它作为待观看资源保留，不把视频内容当作事实来源。

我现在对 Next.js 的第一层理解是：它不是 React 的替代品，而是把 React 放进生产级 Web 应用所需要的工程框架里。

React 主要负责 UI 表达：组件、状态、交互、渲染。但一个真正要上线的网站还需要很多 React 本身不直接负责的东西：

Next.js 做的事情，就是把这些“每个项目都会遇到，但每次从零配都很烦”的工程问题，收束成一套约定。

一句话定义

Next.js 官方文档把它定义为一个用于构建全栈 Web 应用的 React 框架。我的翻译是：

Next.js = React UI 能力 + Web 应用工程约定 + 服务端能力 + 性能优化 + 部署路径。

所以它适合的不是“我只想写一个局部交互组件”的场景，而是“我要做一个完整网站或应用”的场景。

比如这个 PersonalWebsite 项目本身就是 Next.js 的典型使用方式：页面来自 app/ 路由，内容来自 Markdown / MDX，构建时生成静态页面，同时也有 RSS、搜索 API、OG 图这些动态能力。

传统 React 项目经常需要自己接路由库、配置页面结构、组织 layout。Next.js 把路由变成文件系统约定：

txt

app/
  page.tsx
  blog/
    page.tsx
    [slug]/
      page.tsx
  learning/
    [topic]/
      [slug]/
        page.tsx

这种方式的好处是：目录本身就是信息架构。看到文件结构，我大概就知道网站有哪些页面。

对学习来说，这一点很关键。Next.js 不是先要求我理解一堆抽象概念，而是让我从“页面在哪里”开始建立地图。

Web 应用最麻烦的地方之一，是渲染不只有一种方式。

有些页面适合提前生成，比如博客文章、文档、作品集；有些页面需要请求时计算，比如搜索结果、用户后台；还有些交互需要在浏览器里完成，比如按钮状态、弹窗、表单输入。

Next.js 把这些模式放在同一个框架里：

我觉得这里的核心不是记术语，而是形成一个判断：

能在服务端完成的，不要急着丢给客户端；只有真正需要浏览器状态和事件的部分，才放到客户端。

这个判断会直接影响性能、复杂度和可维护性。

Next.js 的数据获取不是一个独立 API，而是和渲染模型绑定在一起的。

如果一个页面在服务端渲染，它可以直接在服务端读取数据；如果内容可以缓存，就可以减少重复请求；如果数据变了，又可以通过重新验证机制让页面更新。

这比“组件 mounted 后再 fetch 数据”更接近完整应用的思路。因为用户看到页面之前，框架已经有机会把数据、HTML、缓存策略一起安排好。

对我来说，可以先记住三个问题：

Next.js 的很多概念，其实都是围绕这三个问题展开。

Next.js 不只是前端页面框架。它也提供 Route Handlers、Server Actions、表单处理、metadata、图片字体优化等能力。

这意味着一个小型产品可以从同一个项目里长出来：

这也是为什么 Next.js 经常被称为 full-stack React framework。它的“全栈”不是说替代数据库和业务系统，而是说它把前端应用和服务端入口放到同一个开发模型里。

如果从零学，我不想直接陷进 API 文档。我会按下面的顺序：

这条路径的目标不是“背完 Next.js”，而是建立一个可运行的心智模型。

Next.js 最重要的价值，是把 React 从“组件库”带到“完整 Web 应用工程”。

它提供的不是某一个单点能力，而是一组互相配合的约定：路由、布局、渲染、数据、缓存、优化、部署。学 Next.js 的时候，我真正要掌握的是这些约定背后的判断力：

当这些问题想清楚，Next.js 就不再只是一个框架名字，而是一个组织 Web 应用复杂度的方法。