Halo 和 Hexo 对比:动态 CMS 还是静态博客?

3 阅读

如果你在中国互联网圈子里提到「搭建个人博客」,Halo 和 Hexo 可能是最常被推荐的两个选项。 一个是现代化的动态 CMS(Java + Docker),另一个是 Node.js 静态博客生成器。两者在国内都有极高的知名度,但面向的完全是两种不同的用户群体和工作方式;如果你更关注 Go 生态的静态站点生成器,也可以参考 Halo 和 Hugo 对比


两个产品,两个时代

Hexo

2012 年诞生,Node.js 编写,MIT 协议。Hexo 是很多中国开发者的第一个静态博客工具——它见证了 GitHub Pages + 个人博客的黄金时代。核心工作流:本地写 Markdown → hexo generate 生成静态文件 → hexo deploy 一键部署到 GitHub Pages 或其他平台。拥有 400+ 主题和丰富的插件生态(RSS、Sitemap、搜索等),通过 NPM 安装插件。

Halo

2018 年诞生,Java(Spring Boot)编写,GPL-3.0 协议。动态 CMS,提供 Web 后台管理界面,内置全文搜索、备份恢复、插件化架构和应用市场

选 Halo,如果你:

  • 需要通过浏览器在线写作和管理内容,不想依赖本地环境
  • 需要多用户协作和权限管理
  • 需要动态功能(在线搜索、评论,以及视插件或版本能力而定的 AI 能力)
  • 需要博客之外的场景(知识库、企业官网、商城)
  • 偏好 Java + Docker 技术栈

选 Hexo,如果你:

  • 习惯用 Markdown + Git 管理内容
  • 想用免费静态托管(GitHub Pages 等)
  • 需要丰富的主题选择(400+ 主题)
  • 偏好 Node.js 生态和 NPM 工作流
  • 希望有一个成熟的插件系统来扩展静态站点功能
  • 对命令行有基本使用经验

功能逐项对比

维度 Halo Hexo
类型 动态 CMS 静态博客生成器
许可证 GPL-3.0 MIT
后端技术栈 Java / Spring Boot Node.js
数据库 PostgreSQL、MySQL、MariaDB、H2 无(Markdown 文件)
后台管理界面 ✅ Web 管理后台 ❌ 无原生后台
在线编辑器 ✅ 富文本编辑器 ❌ 本地编辑器
多用户 ✅ 原生 RBAC 权限体系 ❌ 无用户系统
内容存储 数据库 Markdown 文件(Git 友好)
页面渲染 服务端实时渲染 预构建静态 HTML
构建速度 N/A 快(数百文件数秒)
页面加载速度 快(需优化) 极快(纯静态)
全文搜索 内置 Lucene 搜索引擎 ❌ 需第三方服务或插件(如 hexo-generator-search)
评论系统 可通过评论组件添加 ❌ 需第三方服务(Disqus、Giscus 等)
SEO 基础 SEO 支持 + SEO 工具集(需专业版/商业版) / Sitemap 插件增强(hexo-generator-seo 等)
多语言 管理端原生多语言 主题支持 + i18n 插件
动态功能 ✅ 搜索、登录/权限;表单/会员视插件或版本能力而定 ❌ 需第三方服务
主题数量 应用市场(主题和插件) 400+(社区贡献)
插件 应用市场 + 动态加载/卸载 NPM 安装 + 配置文件注册
AI 能力 官方 AI Foundation 插件 ❌ 无
部署 Docker / Docker Compose hexo deploy 一键部署(GitHub Pages、Coding Pages、VPS 等)
托管成本 需要服务器(约 ¥50-200/月) 免费(GitHub Pages 等)或极低成本
备份 内置一键备份 Git 版本管理
适用场景 博客、知识库、企业官网、商城 博客、个人站点

核心差异:工作流

Halo 的工作流

打开浏览器 → 登录后台 → 在线写文章 → 点击发布 → 生效

Hexo 的工作流

打开终端 → hexo new "文章标题" → 用编辑器写 Markdown → hexo generate → hexo deploy → 生效

Halo 适合「随时随地写作」——出差途中用 iPad 打开浏览器就能改文章。Hexo 适合「本地深度写作」——在 VS Code 中沉浸式书写,通过 Git 管理版本,最后一次性生成部署。


生态对比

主题:Hexo 的先发优势

Hexo 拥有 400+ 社区主题,是中文静态博客领域主题最多的项目之一。很多主题(如 NexT、Butterfly、Yilia)已经成为一代开发者的共同记忆。而且 Hexo 主题通常高度可定制,通过 _config.yml 配置即可调整布局、颜色、社交链接等。

Halo 的主题数量在快速增长,但历史积累不及 Hexo。优势在于安装体验:在 Halo 后台一键安装和预览,Hexo 则需要 npm install + 手动编辑配置文件。

插件:两个成熟的方向

Hexo 有一个成熟的插件生态——通过 NPM 安装,_config.yml 中注册。标签插件(Tag Plugins)允许在 Markdown 中嵌入丰富内容(代码块、引用、视频等)。但 Hexo 的插件安装和管理是「手动的」——你需要在终端运行 npm install,手动编辑配置文件。

Halo 的插件通过应用市场安装,支持动态加载/卸载(不需要重启服务),管理体验更现代。但从插件绝对数量来看,Hexo 可能更多(得益于其更早的起步时间和 NPM 生态的广度)。


内容创作体验

两种写作哲学

Hexo 的核心创作工具是你的本地编辑器(VS Code、Sublime、Typora 等)和 Markdown。所有内容以 .md 文件存在 source/_posts/ 目录下,使用 Markdown frontmatter 声明标题、日期、分类、标签。这意味着:

  • 写作体验完全取决于你选择的编辑器(而非 Hexo)
  • 你可以使用任何 Markdown 编辑器的高级功能(多光标、正则替换、Vim 模式等)
  • 离线写作,不受网络限制
  • 批量处理(全局替换、格式转换)非常高效

Halo 的核心创作工具是浏览器中的富文本编辑器。这意味着:

  • 不需要安装任何本地软件
  • 支持表格、图片、嵌入等复杂排版
  • 草稿自动保存
  • 但对于需要批量编辑文章的场景,不如直接操作 Markdown 文件高效

如果你习惯了 Typora 或 Obsidian 的 Markdown 写作体验,Hexo 更自然。如果你习惯了 WordPress 或 Notion 的富文本写作体验,Halo 更自然。


部署与运维

Halo Hexo
部署命令 docker compose up -d hexo deploy
部署目标 VPS(最低约 ¥50/月) GitHub Pages(免费)、VPS、虚拟主机
自动部署 需手动或 CI/CD 配置 配合 GitHub Actions 可实现推送即部署
SSL 证书 手动或通过反向代理 GitHub Pages 自动提供
CDN 需额外配置 静态托管通常自带 HTTPS/缓存能力,可叠加 CDN
宕机风险 服务器故障 取决于静态托管平台,通常更低
运维投入 中等 极低

Hexo 的部署成本优势非常直接:如果你用 GitHub Pages,完全免费并且自带 HTTPS。Halo 需要至少一台 VPS,但换来的是动态能力(搜索、评论、API 等)。


客观而言:各自的三项不足

Halo 的三项短板

  1. 需要运行动态服务。 相比 Hexo「免费 + 近乎零运维」的静态托管方案,Halo 需要 VPS、容器环境或类似服务器资源,并需要维护 Docker / Java 运行环境。对于学生和个人博主,这是一个需要认真考虑的差异。

  2. 编辑场景侧重桌面端。 Halo 的编辑器运行在浏览器中,桌面端编辑体验最为完整,适合在线管理和发布。如果你经常离线写作,Hexo 的本地 Markdown 模式更匹配这类场景。

  3. 内容管理方式不同。 批量替换分类、全局查找替换这类操作,在 Hexo 的文件系统中用脚本或编辑器就能高效完成。Halo 则通过后台可视化管理界面操作,可通过 Markdown 文档迁移批量导入 Markdown + Front Matter 内容目录;两种路径各有适用场景。

Hexo 的三项短板

  1. 对非技术用户不友好。 安装 Node.js、配置 NPM、理解命令行、管理 _config.yml、调试依赖冲突——这套流程对纯内容创作者来说太复杂了。Halo 的「Docker 一条命令启动 + 浏览器后台操作」明显更简单。

  2. 没有在线管理能力。 你无法在朋友家用他的电脑登录后台修改文章,也无法在手机上快速更正一个拼写错误。每次修改都需要:编辑文件 → 重新生成 → 重新部署。这个循环在需要频繁更新时效率低下。

  3. 动态功能缺失。 站内搜索需要 hexo-generator-search 生成静态索引(大站点效率低),评论需要外挂 Disqus/Giscus,没有表单处理能力。这些都是 Halo 通过核心功能、插件或付费版能力可以覆盖的。


谁通常更适合哪一款?

Halo 更适合:

  • 需要通过浏览器在线管理内容的用户(非技术向)
  • 团队协作需要多用户和权限管理
  • 需要内置搜索、在线评论等动态功能
  • 需要博客之外的场景(知识库、企业官网、商城)
  • 偏好 Java + Docker 技术栈
  • 对后台管理界面的现代交互体验有要求

Hexo 更适合:

  • 习惯 Markdown + Git 工作流的开发者
  • 想在 GitHub Pages 上免费托管个人博客
  • 需要丰富的主题选择(400+)
  • 偏好 Node.js + NPM 生态
  • 内容更新频率低,可以接受本地编辑 → 生成 → 部署的流程
  • 需要「博客只是静态文件」的简单性和可迁移性

常见问题

我应该从 Hexo 迁移到 Halo 吗?

如果你对 Hexo 的现状满意——博客正常运行、更新频率合理、不觉得缺少动态功能——继续使用就好。考虑迁移的理由通常是:想要在线编辑而不再想每次都开终端、需要多用户协作、想要内置搜索而不想外挂第三方服务、或者想扩展为知识库或企业官网。实际迁移时,可以通过 Halo 的 Markdown 文档迁移导入 Hexo 的 Markdown + Front Matter 内容目录。

Hexo 的构建速度如何?

对于个人博客(几百篇文章),Hexo 的构建通常在几秒内完成。但随着文章数量增长(特别是大量标签和分类页面),构建时间会显著增加。这是所有静态站点生成器的共性——每个页面都要预生成。Hugo(Go 编写)在这方面比 Hexo(Node.js 编写)快得多,但 Halo 作为动态 CMS 没有「构建」这一步。

Halo 能不能也部署到 GitHub Pages?

不支持。Halo 是动态 CMS,需要 Java 运行时和数据库,GitHub Pages 仅托管静态文件。如果你需要纯静态托管方案,Hexo、Hugo 或 Jekyll 是更匹配的选择。

Hexo 有类似 Halo 应用市场的机制吗?

没有。Hexo 的主题和插件通过 NPM 和 GitHub 仓库分发,没有统一的应用市场。你需要自己搜索、安装、配置。相比 Halo 应用市场的一键安装体验,这方面 Hexo 的体验更「工程师化」。

如果我不懂命令行,能玩得转 Hexo 吗?

很困难。Hexo 的核心操作(创建文章、生成站点、部署)全部通过命令行完成。虽然命令本身不难(hexo newhexo serverhexo deploy),但前提是你需要配置好 Node.js 环境和 Git。如果你不想接触命令行,Halo 是更合适的选择。


总结

Halo 和 Hexo 的对比,是两个时代的对话。

Hexo 代表了「静态博客」的黄金时代:一个 Node.js 环境、一个 GitHub 仓库、一个 Markdown 编辑器——有了这三样,你就拥有了一个由自己掌控、可以免费托管、性能很高的博客。它是开发者写博客的「默认选择」之一,400+ 主题的丰富生态承载了一代人的博客记忆。

Halo 代表了「现代 CMS」的新方向:浏览器就是你的工作台,应用市场是你扩展功能的入口,Docker 是你部署的方式。它把博客从「技术人员的事情」变成了「所有人的事情」——不需要命令行、不需要 Git、不需要 NPM。

如果你是一个享受命令行、Git 和 Markdown 的开发者,Hexo 是让你感到自在的工具。如果你想要一个「打开浏览器就完事」的现代建站体验,Halo 准备好了。


本文基于截至 2026 年 7 月的公开信息编写。产品功能和生态数据可能随时间变化。


评论