帮助中心和文档站源码怎么选：五条路线，先看谁来写内容

站做久了都会碰到同一个问题：产品说明、常见问题、更新日志堆在博客分类里，越堆越乱。单独开一个文档站或者帮助中心，比在首页加十几个页面清爽得多。可一搜“文档站源码”，Docusaurus、VitePress、Wiki.js、BookStack、Outline 全冒出来，参数表看得人头大。

这篇不比较功能清单，只讲一件事：谁来写这些文档。写的人决定技术路线，顺序反过来，基本都要返工。

图片由 AI 生成

静态生成器：内容跟着代码走

Docusaurus 和 VitePress 都属于这一类。Markdown 放在仓库里，构建成纯 HTML，扔到对象存储或者 Pages 上就能跑，没有数据库，也就没有后台被扫、被拖库的烦恼。

Docusaurus：多版本文档的默认答案

它的版本化是原生功能，一条命令就能把当前文档快照成 v1、v2，之后维护多个大版本的手册不用手工复制目录。MDX 允许在文档里嵌 React 组件，接口文档里放一个可交互的请求示例很自然。代价是 Node 工具链偏重，几百页的站点首次全量构建会吃掉不少内存。

VitePress：快，但版本切换要自己想办法

Vue 3 加 Vite，开发服务器几乎是秒起，构建产物也小。适合组件库文档、单版本的产品手册。多版本不是原生能力，得靠插件或者约定式路由自己搭，官方没有开箱即用的版本切换界面。如果文档只维护“当前版本”，这个短板可以忽略。

两者共同的坑是搜索。静态站没有后端，默认要么接 Algolia（免费额度对文档站够用，但需要申请），要么在构建时生成本地索引。中文分词在本地索引里经常表现一般，词库小的时候搜“伪静态”搜不到“伪静态规则”，上线前务必用真实的中文长句试几轮。

动态 Wiki：编辑体验换运维成本

Wiki.js

它的定位在静态站和团队 Wiki 之间：后台可视化编辑，内容又能存到 Git 做版本管理。需要注意的是版本，2.5.x 是 AGPL-3.0 的稳定线，3.0 目前还在 beta，官方明确不建议上生产；3.x 只支持 PostgreSQL，现在新建站点直接用 Postgres，能省掉以后迁移的麻烦。

BookStack

书架、书、章节、页面四层结构，听起来幼稚，用起来反而最不容易散架——每篇文档都有明确归属，不会变成一堆没标题的笔记。MIT 协议，PHP 加 MySQL 8 或 MariaDB 10.6，2GB 内存的机器能跑，LDAP、SAML2、OIDC 登录都是内置的。项目在 2026 年 4 月把代码仓库从 GitHub 迁到了 Codeberg，部署脚本里写死 GitHub 地址的要改。

Outline

编辑体验是这几款里最像 Notion 的，实时协作、快捷键、全文搜索都顺手。但它的协议是 BSL 1.1，2030 年 9 月才转 Apache 2.0，期间不能拿它对外提供文档托管服务；登录必须接外部认证（Google、Slack、OIDC），邮箱密码登录不支持，SAML 还要另外付费。团队内部用很舒服，想做公开帮助中心就要想清楚。

图片由 AI 生成

一张表看清成本

按写作的人来选，不用犹豫

只有你自己写，或者写的人会提 PR：Docusaurus 或 VitePress，静态站省下的运维时间够你多写十篇文档。

三五个同事一起维护，谁都能改：BookStack 或 Wiki.js。前者结构强制，后者自由度高，选哪个看团队更怕乱还是更怕约束。

要给外部用户看的帮助中心，且希望它被搜索引擎正常收录：优先静态方案。帮助中心的流量大头来自搜索，静态页的加载速度和抓取稳定性都更占优，还能顺手把 sitemap 和结构化数据做干净。

文档站真正的成本不在装哪套程序，而在一年后还有没有人愿意往里写。选那套让写的人最不费劲的。

三个常见的坑

把帮助中心做成博客分类

短期省事，长期难受：没有层级导航，没有版本，改一篇文章要翻遍分类。文档一旦超过三十篇，搜索和目录结构就会开始拖后腿。

忽略了附件和图片

Outline 需要 S3 兼容存储放图片；Wiki.js 也要单独配置上传目录。上线前先想好图片放哪、备份怎么做，别等文档里几百张截图都在本地磁盘上才发现迁移麻烦。

没做导出测试

选型时不妨做一次“删库恢复”：把数据导出来，在新机器上恢复成可用的文档站。做不成的方案，不管功能多好，都是在给自己埋雷。

最后提醒一句，文档站和主站最好放在同一个域名下，用子目录而不是子域名。权重集中在一个域名上，收录和排名都更稳；跨域名跳转反而把刚攒起来的一点权重分薄了。

本文链接：https://www.zkui.cn/post/69.html