Hexo 怎么选¶

一个人如果有好几个站点，迟早会撞上这个问题：用什么引擎搭？ 我目前就有四个半站：wiki（知识库）、digest（书摘）、nav（导航）、works（作品集），以及一个用户页博客（Hexo，挂在 blog2.hanvon.top）。它们用的引擎并不一样—— 前两个是 MkDocs，中间两个是 Hugo，用户页博客是 Hexo。

这篇文章就把「引擎怎么选」这件事讲清楚：先看你内容长什么样，再决定引擎；而不是反过来，先迷恋某个引擎再硬塞内容。文中「更多建站引擎 / 平台全景」一节，把我用过或调研过的几乎所有平台都列了出来、逐一点评，这部分改编自 Power's Wiki 《为什么你需要一个知识库》一文（CC BY-NC-SA 4.0），结合我自己的实测重写。

顺带澄清一个我之前说漏嘴的点：「项目页成品落 gh-pages」是对的，但有前提——详见第七节。

一、为什么要想「引擎怎么选」¶

内容模型不同，趁手的引擎就不同。 我手上的站点，本质是完全不同的东西：

知识库 / 书摘：一页一篇 Markdown，按类别归档，要搜索、要互相链接。
导航站：本质是一组「链接卡片」，没有正文 Markdown，只是结构化数据。
作品集：一组「带分类的卡片」，同样没有正文，靠 categories 过滤。
时间线博客：一篇篇文章按时间排，主题生态丰富、评论/分页之类现成。

用一个引擎通吃，往往别扭。 比如硬用 MkDocs 做导航站，你就得把每一条链接都写成一篇 Markdown 页；想复刻某个 Hugo 主题的观感却又用 MkDocs，主题写法对不上。选错引擎的代价 要么是观感不到位，要么是维护痛苦。所以「先定内容、再选引擎」比「先选引擎、再凑内容」稳得多。

二、第一性原理：先看内容模型¶

问自己一个问题，基本就能定位引擎：

我的内容，是一篇篇「文档」，还是一条条「数据」，还是一串「时间线文章」？

内容长相	典型站点	趁手引擎
一篇篇 Markdown（文档/知识库）	wiki、文档站、书摘	MkDocs Material
一条条结构化数据（无正文）	导航站、作品集、目录	Hugo（data + 自定义 layout）
一串时间线文章（博客流）	个人博客	Hexo / Hugo

文档型：重分类、重搜索、重内部链接，最好跟 Obsidian 打通 → MkDocs。
数据驱动型：内容天然是「一条条记录」，渲染逻辑自己写最干净 → Hugo。
时间线型：要成熟博客体验（主题、分页、标签）→ Hexo 或 Hugo。

一句话：MkDocs 管「文档」，Hugo 管「数据 + 观感」，Hexo 管「博客流」。

三、我实际用到的三个引擎¶

3.1 MkDocs Material（wiki / digest）¶

适合：文档、知识库、书摘。
最大卖点：Obsidian 的 [[wikilink]] 能直接转成站内链接（装 roamlinks 插件），改 mkdocs.yml 就能换配色、开关功能，几乎不用写前端。
部署：mkdocs build + mkdocs gh-deploy --force → gh-pages（项目页）。
优点：门槛低、中文界面完善、内置搜索（装 jieba 后中文分词好）、tags 聚合现成。
局限：做「非文档」站点（导航 / 作品集）要硬写成很多页，观感受主题约束，不如 Hugo 自由。

3.2 Hugo（nav / works）¶

适合：导航站、作品集、以及「想复刻某个 Hugo 主题观感」的站。
最大卖点：单文件 Go 二进制、构建极快；layouts/ 完全自定义。我没装任何现成主题，而是用 data/*.yaml 存内容 + 自写 layouts/index.html + 自写 CSS，把参考站 nav.wiki-power.com / works.wiki-power.com 的观感对齐了。
内容模型：导航站就是 data/links.yaml 里的 sections → items；作品集就是 data/projects.yaml 里带 categories 数组的条目。加一条链接只改数据文件，不动模板。
部署：hugo --minify + peaceiris/actions-hugo + peaceiris/actions-gh-pages → gh-pages（项目页）。
优点：数据驱动、layout 自由、构建飞快、主题/无主题都行。
局限：要懂 Go 模板 {{ }}，学习曲线中等；站内搜索需另接（如 Pagefind），本站暂未做。

3.3 Hexo（用户页博客：`wild-civil.github.io` → `blog2.hanvon.top`）¶

适合：经典时间线博客，主题生态大、博客功能成熟。
最大卖点：文章流体验开箱即用，主题多，分页/标签/评论集成方便。
部署：Hexo 构建出 public/，由 hexo-deployer-git 推到仓库。因为它仓库名恰好是 <user>.github.io（用户页），所以成品直接进 main 分支根目录，Pages 直接 serve （不经过 gh-pages）；并配了自定义域名 blog2.hanvon.top，wild-civil.github.io 会 301 过去。
优点：博客场景最省心，主题选择多。
局限：相对重；做 Wiki / 导航这类非博客站点不灵活（参考站作者也提到 Hexo 缺好看的 Wiki 主题）。

四、更多建站引擎 / 平台全景（我都用过或调研过）¶

前面三节只讲了我最终留下的三个引擎。但选型前我把市面上几乎所有主流方案都摸了一遍。下面这张表是我亲身用过或认真调研过的平台，逐一点评（评价口径改编自 Power's Wiki 的选型笔记，原文采用 CC BY-NC-SA 4.0，转载请注明出处）。它和「第一性原理」是互补的：原理告诉你该选哪类，下表告诉你同类里哪个值得试。

平台	类型	我的点评
WordPress	动态 / 数据库	使用方便，但底层过于庞大复杂，需要数据库，不利于迁出。
Hexo	静态 / 博客	较为冗杂，且没有比较好看的 Wiki 主题（做博客还行）。
GitBook	静态 / 文档	CLI 版本已停止更新支持，V2 版本国内访问速度较慢。
Jekyll	静态 / 博客	技术相对较旧，且缺少更新支持。
GitHub Issues / Gist / Wiki	平台内	国内访问速度较慢，UI 不可定制。
Bitcron	动态托管	可定制性较差，访问速度时快时慢。
DokuWiki	动态 / 需服务器	需自备服务器，且本身过于老旧。
Gridea	静态	部署简单，但可定制性较差，只能用其专用编辑器。
wiki.js	动态 / 需服务器	需自备服务器搭建，一般适用于团队知识库，存在部分小问题。
语雀	第三方知识库	相对不错的第三方平台，缺点是 UI 不可定制，且数据迁出不方便。
Hugo	静态	部署速度快，但没有比较好看的 Wiki 主题（做导航 / 作品集很香）。
Gatsby	静态	与 Hugo 相似，偏重、生态偏 React。
Ghost	动态	UI 美观，需要自备服务器（或花钱买服务），可定制性较差。
docsify	静态（加载渲染）	比较推荐。部署简易，UI 美观，但加载时渲染，某些设备性能较差。
Docute	静态（加载渲染）	比较推荐。部署简易，UI 美观，比 docsify 插件更少。
VuePress	静态	比较推荐。各方面不错，社区插件多；局限是官方文档较乱、有些小 bug。
Docusaurus	静态	比较推荐。各方面不错；局限是编译较慢、框架较臃肿。
MkDocs（Material 主题）	静态	比较推荐。各方面不错，编译也快——我现在的方案。

第三方平台再提一嘴：语雀、知乎、简书、公众号、CSDN 这类「不用管底层」的平台，适合纯写作分发的场景；但只要你在意数据所有权和可定制性，迟早会回到自建（参见 GitHub Pages 分支区别笔记 → 里「用户页 vs 项目页」的思路——自建就是把产出权握在自己手里）。

怎么读这张表： - 想要文档 / 知识库观感 → 优先看 MkDocs、docsify、Docute、VuePress、Docusaurus（都「比较推荐」）。 - 想要导航 / 作品集 / 自定义观感 → Hugo、Gatsby 这一支（Hugo 更轻、构建更快）。 - 想要时间线博客 → Hexo、Ghost 这一类（Hexo 静态免费、Ghost 偏动态需服务器）。 - 凡是带「需自备服务器 / 数据库 / 动态」的，维护成本都更高；我全部选了静态站，省服务器、好托管、对 SEO 友好。

五、三引擎对照表¶

维度	MkDocs Material	Hugo	Hexo
最佳场景	文档 / 知识库	导航 / 作品集 / 自定义观感	时间线博客
内容模型	一篇篇 Markdown	数据文件 + 自定义 layout	一篇篇 Markdown（时间线）
主题方式	配置驱动（改 YAML）	任意主题 / 自写 `layouts`	主题生态丰富
Obsidian 友好	✅（`roamlinks` 直转）	⚠️ 需转换	⚠️ 需转换
构建速度	快	极快	中
项目页部署分支	`gh-pages`	`gh-pages`	`gh-pages` / `main`（用户页）
学习曲线	低	中（Go 模板）	低 ~ 中

注意最后一行的「部署分支」：引擎不决定分支，仓库类型才决定（见第七节）。

六、怎么选：一张决策清单¶

内容是文档 / 知识库，且用 Obsidian 写？ → 选 MkDocs。
内容是导航 / 作品集 / 目录（结构化数据），或想复刻某 Hugo 主题观感？ → 选 Hugo。
内容是时间线博客，想要成熟博客主题与体验？ → 选 Hexo（或 Hugo）。
一个仓库里混了多种内容？ → 别硬塞，拆成多站、各自选引擎（我就是这么干的： wiki/digest 用 MkDocs，nav/works 用 Hugo，用户页博客用 Hexo）。

反例提醒：别因为「Hugo 很火」就把知识库也迁过去——除非你真的想要某个 Hugo 文档主题的样子，否则 MkDocs 的 Obsidian 友好度是 Hugo 比不了的。迁过去纯属增加维护成本。

七、部署分支的真相（澄清我之前说漏的一点）¶

我前面在别处写过「不管哪个引擎，成品都落到 gh-pages」——这句话只对了一半，这里纠正：

决定走 main 还是 gh-pages 的，是「仓库类型」，不是「引擎」。

用户页（User Pages）：仓库名恰好是 <用户名>.github.io（如 wild-civil.github.io）。 GitHub 默认直接从 main/master 分支根目录 serve，不经过 gh-pages。所以 Hexo 博客「就是 main」——它的 public/ 直接推到 main 根。
项目页（Project Pages）：其他任意仓库名（如 civil_wiki、civil_nav）。 默认从 gh-pages 分支 serve。我的 MkDocs / Hugo 站都属此类，成品落 gh-pages。

所以：

「项目页的成品最终落在 gh-pages」——这句话是对的。 它是项目页的默认行为，也是 MkDocs gh-deploy、Hugo actions-gh-pages 等部署工具的默认推送目标。但要补一句前提：GitHub 也允许项目页改从 main（root 或 /docs）serve；我坚持用 gh-pages，是因为它能把「源码（main）」和「成品（gh-pages）」干净分开，且部署工具默认就推那里。

详细对照见 GitHub Pages 的 main 与 gh-pages 分支区别 →。

八、局限与提醒（平衡视角）¶

没有「万能引擎」：选引擎看内容模型，别为了统一而统一。一个站一种引擎，反而每站都趁手。
多站拆分有维护成本：多个仓库、多套 CI、多份配置。换来的是每个站都「对味」，值不值看你的站点数。
静态站无在线编辑器：需要本地编辑器（VS Code / Typora / Obsidian），但用 GitHub Actions 自动部署能把「更新负担」降到最低——push 即上线。
流量不如第三方平台：自建站天然读者少。可「一文多发」把流量导回个人站（参考文作者也提到）。
Hexo/Hugo 做 Wiki 不灵：参考文作者原话——Hexo「没有比较好看的 Wiki 主题」、Hugo「没有比较好看的 Wiki 主题」。这正印证了我的分工：Wiki 交给 MkDocs。

九、我目前的分工（小结）¶

站点	引擎	内容模型	部署分支
wiki（知识库）	MkDocs Material	文档 / Obsidian	`gh-pages`（项目页）
digest（书摘）	MkDocs Material	文档	`gh-pages`（项目页）
nav（导航）	Hugo	数据驱动（链接卡片）	`gh-pages`（项目页）
works（作品集）	Hugo	数据驱动（带分类）	`gh-pages`（项目页）
用户页博客	Hexo	时间线文章	`main` 根（用户页）

一句话总结：先看内容「是文档、是数据、还是文章流」，再对应选 MkDocs / Hugo / Hexo；分支怎么设，看仓库是「用户页」还是「项目页」，与引擎无关。