Fumadocs、Nextra、Rspress、Starlight：个人内容网站如何选型

过去选择个人网站框架，第一批问题通常是：

• 会不会 React？
• 团队用 Vue 还是 Next.js？
• 能不能自己写组件？
• 要不要为了一个框架重新学习技术栈？

Coding Agent 出现后，这些问题的重要性明显下降了。

现在，即使你不熟悉 Astro、Rspress 或 Fumadocs，也可以让 Agent 完成脚手架、路由、组件、样式和部署。只要框架有清楚的官方文档，跨技术栈实现一个可用原型已经不再是最大的门槛。

但这不代表“选什么都一样”。

Agent 降低了把网站做出来的成本，却没有替你回答几个更重要的问题：

• 这个网站究竟要呈现什么；
• 内容怎样被组织和持续更新；
• 首页需要多少品牌表达；
• 哪些能力应该开箱即用，哪些值得自己维护；
• 一年以后，谁来理解和升级这套系统。

所以今天选择个人内容网站框架，技术栈不应该再是第一入口。更合理的顺序是：

先选择最符合自己需求的产品形态，再让 Coding Agent 帮你跨过实现门槛。

先给一个简化结论：

这不是综合排名。它只是说明：不同框架默认帮你解决的问题不同。

本文根据 2026 年 8 月的官方资料整理。容易变化的版本、功能和产品边界集中维护在 持续更新对比表。

Coding Agent 改变了什么，没有改变什么

改变的是进入门槛

以前跨技术栈意味着学习成本。现在可以让 Agent：

• 阅读官方 Quickstart；
• 创建项目和内容目录；
• 实现中英文路由；
• 接入 MDX；
• 建立主题和响应式布局；
• 运行构建并修复错误；
• 把同一份需求分别做成多个原型。

这使选型从“我会什么”转向“我需要什么”。

没有改变的是系统责任

Agent 可以生成 Sidebar，但 Sidebar 是否应该存在，仍然是产品判断。

Agent 可以接入搜索，但当前内容量是否值得搜索，仍然需要判断。

Agent 可以复制一个框架组件并改到完全符合设计稿，但复制之后谁来跟进上游升级，仍然是维护责任。

“能做出来”和“值得这样做”是两件事。Coding Agent 让第一件事越来越便宜，也让第二件事越来越重要。

先判断自己需要哪一种网站

不要先打开框架官网。先判断你希望网站一年后是什么样子。

个人主页附带博客

内容主要按时间发布，重点是作者、作品和近期动态。

真正需要的通常是：

• 自定义首页；
• 文章列表；
• 标签、RSS 和归档；
• 简单的 Markdown/MDX；
• 低维护部署。

这种场景不需要为了“以后可能有知识库”提前建设复杂 Sidebar 和内容树。

知识库型个人网站

内容开始按主题组织，旧文章需要持续更新，读者会通过目录而不是时间流进入。

真正需要的是：

• 内容树和稳定分类；
• Sidebar 与页内目录；
• 系列文章关系；
• 搜索或资源索引；
• 多语言；
• 可复用的 MDX 组件。

品牌网站加结构化内容

首页需要鲜明的品牌表达，内容区却需要克制、稳定的阅读体验。

真正的问题是：

• 能否让首页和 Blog 使用不同布局；
• 能否只把通用内容能力交给框架；
• 品牌样式会不会侵入文档结构；
• 内容、OG、导航和机器输出能否共用一份来源。

Orbit Studio 属于这一类。

团队文档平台

如果核心需求是多人编辑、审核、权限、搜索分析和无需维护基础设施，那么应该同时比较 Mintlify、GitBook 等托管平台。

开源框架解决“怎样构建”，托管平台还要解决“怎样协作和运营”。它们不是同一种产品。

用八个需求维度做选择

1. 内容是按时间，还是按结构增长

按时间增长的博客需要文章流、标签和 RSS；按结构增长的内容需要 Page Tree、Sidebar、目录和稳定 URL。

如果两者都有，就要观察框架能否让 Blog 和 Docs 共存，而不是强迫所有内容进入一种导航方式。

2. 首页承担多少品牌任务

有些网站的首页只是文档入口，有些则承担品牌、作品和个人表达。

首页越重要，越应该确认：

• 能否建立完全独立的页面；
• 是否必须跟随文档主题；
• 导航、主题和语言状态能否共享；
• 自定义是否需要 fork 框架内部布局。

3. 你希望框架替你决定多少

主题型框架通常更快、更统一；模块化框架通常更自由，也需要更多判断。

这不是自由越多越好。如果你只是希望写作，过高的定制上限反而会诱发长期折腾。

4. 内容怎样进入网站

• 个人与 Coding Agent：本地 Markdown/MDX + Git 通常最直接；
• 多人开发团队：Docs-as-code 仍然合适；
• 产品、运营、编辑共同参与：需要 CMS 或 Web Editor；
• 内容来自多个系统：需要更强的内容源抽象。

选择框架时，不要只看页面组件，还要看真实发布流程。

5. 是否需要交互式内容

Callout、Tabs 和代码块已经是常见能力。真正需要重点评估的是：

• 能否嵌入自己的 React、Vue 或其他组件；
• 领域组件怎样注册；
• 客户端状态与静态内容怎样共存；
• 组件是否能继续使用框架主题 token；
• 同一组件能否在多篇文章复用。

6. 是否需要多语言

“支持 i18n”只是开始。还要看：

• 默认语言能否不带前缀；
• 中英文内容怎样配对；
• 侧栏和主题 UI 怎样翻译；
• 缺少翻译时怎样处理；
• Coding Agent 能否从目录结构判断需要同步哪些页面。

7. 你想拥有多少控制权

自托管意味着代码、部署和数据都由自己控制，也意味着升级、搜索和故障都由自己负责。

托管平台减少了维护工作，却会带来套餐边界和平台依赖。两种选择都合理，关键是是否符合你的长期意愿。

8. 一年后的维护方式是什么

Coding Agent 可以继续帮助升级，但它需要清楚的结构。

一个边界明确、接近官方默认的项目，通常比大量复制组件、覆盖全局 CSS 的项目更容易被未来的 Agent 理解和维护。

因此，选型时还应该观察：

• 自定义集中在哪些文件；
• 官方组件是否被复制；
• 内容是否只有一个来源；
• 生产构建是否容易验证；
• 框架升级时影响面是否清楚。

四个框架默认解决什么

Fumadocs：适合把“网站”和“文档能力”组合起来

Fumadocs 由 Core、UI 和 Content Source 等部分组成。它提供多种 Layout、Page Tree、Loader、MDX、i18n、OpenAPI 和 LLM 输出能力，但允许项目只使用其中一部分。

它最适合的需求不是“我会 React”，而是：

• 首页需要自己的品牌表达；
• Blog 或 Docs 需要成熟内容结构；
• 希望内容、路由和 UI 保持较高控制权；
• 需要在普通文章之外加入领域组件；
• 愿意自己维护和部署网站。

主要代价：

• 概念和组合方式较多；
• 需要主动划分框架与项目边界；
• 灵活性很容易诱发过度定制；
• 搜索、AI、分析等仍需自己决定怎样接入。

官方资料：

• What is Fumadocs
• Layouts
• Loader API
• Fumadocs Showcase

Nextra：适合把个人主页、博客和文档快速放在一起

Nextra 提供 Docs Theme 和 Blog Theme，并保留 Next.js 页面能力。它的优势不只是技术栈，而是产品形态非常贴近个人内容网站：

• 个人主页可以自由设计；
• Blog Theme 提供文章、标签和 RSS 基础；
• Docs Theme 提供侧栏、搜索和目录；
• Markdown/MDX 与普通页面可以共存；
• 默认约定比模块化文档框架更容易理解。

主要代价：

• 超出主题范式后的深度定制可能进入自定义主题；
• 复杂内容源和高级文档自动化不是主要优势；
• Blog Theme 与 Docs Theme 如何组合，仍需根据项目设计。

官方资料：

• Nextra Introduction
• Docs Theme
• Blog Theme
• Nextra Showcase

Rspress：适合想尽快获得完整文档体验的人

Rspress 是基于 Rsbuild 的 React 静态站点生成器。Rspress 2 提供现代默认主题、MDX、自动导航、i18n、多版本、全文搜索、插件和面向 AI 的静态 Markdown 输出。

它最适合的需求是：

• 网站以文档和知识内容为中心；
• 希望默认界面就有较高完成度；
• 需要组件库 Preview 或技术内容能力；
• 希望少做布局决策，快速获得统一效果。

定制从 CSS Variables、BEM Class、ESM 组件覆盖一直到 rspress eject。控制越深入，后续维护责任也越大。

主要代价：

• 它首先是独立静态文档站，不是“任意网站加一块文档”的模块；
• 深度 Eject 后需要自己跟进上游变化；
• Blog 和强品牌首页不是它最核心的默认表达。

官方资料：

• Rspress Introduction
• Announcing Rspress 2.0
• Internationalization
• Component Preview Plugin

Starlight：适合把内容质量、性能和可访问性放在前面

Starlight 是 Astro 官方的文档站解决方案，默认提供导航、搜索、国际化、SEO、排版、代码高亮和深色模式，也可以在 MDX 中使用 React、Vue、Svelte、Solid 等组件。

它最适合的需求是：

• 内容与文档是网站主体；
• 希望默认获得稳定阅读体验；
• 重视静态输出、性能和无障碍；
• 希望混用不同组件技术而不把全站变成重客户端应用。

主要代价：

• 强品牌首页和复杂应用能力需要继续使用 Astro 页面与组件实现；
• 大量动态产品功能可能让项目超出 Starlight 最自然的范围；
• 从默认文档体验走向完全不同的视觉系统，仍然会增加覆盖成本。

官方资料：

• Starlight
• Project Structure
• Configuration
• Starlight Showcase

用场景而不是总分做决定

Orbit Studio 的选择是怎样形成的

Orbit Studio 不是先完成一个成熟网站，再挑选文档框架接进去。

它从零开始时，对 Fumadocs、Nextra 这些框架几乎没有概念。最初只是让 Coding Agent 按当时的想法搭出首页和内容页面；出现新需求后，再继续增加路由、组件、MDX、语言切换、侧栏和目录。

每一步都能做出来，但经过多轮调整后，问题逐渐显现：

• 页面局部可以很好看，整体规范却需要反复校准；
• 自建 Sidebar、Drawer、TOC 等组件要处理大量边缘情况；
• 新需求不断叠加在旧结构上；
• Agent 很擅长解决当前任务，却不会自动替项目建立长期边界；
• 网站在“品牌站、博客、知识库”之间缺少明确分工。

后来重新调研成熟方案时，Fumadocs 的价值才变得清楚：它不是帮我们完成某个写不出来的组件，而是提供一套已经处理过布局、阅读、导航和响应式规范的基础。

Orbit Studio 最终确定的需求是：

• 首页仍然要有鲜明的品牌视觉；
• Blog 需要文档式的内容树和阅读体验；
• 内容使用本地 MDX，并由 Git 与 Coding Agent 维护；
• 需要中文和英文；
• 未来会出现字体库等领域组件；
• 当前不需要 CMS、全站搜索和 Ask AI；
• 希望尽量使用成熟默认组件，而不是继续自建文档框架。

在这组需求下，Fumadocs 比其他方案更匹配。

选择它不是因为项目“已经被技术栈绑定”，而是因为最终想要的网站形态，恰好需要它所提供的组合能力。

Coding Agent 时代，更应该让候选方案直接做题

现在最可靠的选型方法，不是长时间阅读功能表，而是给每个候选框架同一份真实任务。

可以直接把下面这份 Brief 交给 Coding Agent：

请使用这个框架建立一个个人内容网站原型。

要求：
1. 一个可以完全自定义的品牌首页；
2. Blog 分为 Notes、Reflections、Resources；
3. 一篇普通长文，一篇带代码和表格的文章；
4. 中英文对应页面，中文为默认语言；
5. 桌面 Sidebar、页内目录和移动端导航；
6. 一个可复用的交互式 MDX 组件；
7. 支持静态生成、Metadata 和生产构建；
8. 优先使用框架默认组件，不复制内部布局源码。

请记录：
- 开箱即用的部分；
- 需要自定义的部分；
- 必须覆盖或复制的框架组件；
- 构建和移动端出现的问题；
- 后续升级最可能受影响的文件。

然后比较的不是 Agent 有没有完成，而是：

• 哪个原型最接近你真正想要的产品；
• 哪个项目结构最容易理解；
• 哪个方案需要最少的侵入式定制；
• 删除一个不需要的功能是否容易；
• 一个月后再次让 Agent 修改时，边界是否仍然清楚。

最后的选择规则

Coding Agent 让“不会某个技术栈”越来越不应该成为放弃好方案的理由。

但它也让我们更容易在没有产品判断的情况下不断加功能、换框架和重写组件。

因此，如果只记住三件事：

1. 先确定网站要成为什么，再选择框架。
2. 比较框架默认替你解决的问题，而不是只比较它能不能实现。
3. 让 Agent 负责跨越技术门槛，人负责需求、边界和长期维护方式。

下一篇会继续讲 Orbit Studio 的真实过程：一个从零开始、反复搭建的网站，为什么最后选择用 Fumadocs 规范内容层，又如何避免把所有品牌表达都交给文档主题。

主要参考

• Fumadocs 官方文档
• Nextra 官方文档
• Rspress 官方文档
• Starlight 官方文档
• Docusaurus 官方文档
• VitePress 官方文档
• Mintlify Quickstart

本文的判断面向个人网站、博客和文档混合场景，不代表这些框架在企业开发者门户、API 文档或大型团队协作中的完整能力排名。