Hexo 与 Halo：别只看“流行度”，要看你在解决什么问题

很多人讨论 Hexo 与 Halo 的流行度，会用“谁的教程多、谁的主题多、谁的 Star 多”来下结论。但如果你真正把它们用在自己的博客里，就会发现：流行不流行，往往取决于你的写作流程和你愿意承担的运维成本。Hexo 属于静态站点生成器（SSG），写作内容之后需要本地构建，再发布到静态托管（GitHub Pages、Vercel、Netlify、Nginx 等都行）。Halo 更像传统博客系统或轻量 CMS：你部署一个服务，带后台管理，文章、草稿、分类、标签、媒体资源都在后台里直接维护。

因此，“流行度”的两极化其实很正常：工程师群体更容易喜欢 Hexo，因为它符合 Git 工作流，内容就是一堆 Markdown 文件，版本可追踪、可回滚、可批量处理；而更偏内容运营的人往往更需要 Halo，因为它省掉了很多命令行与构建步骤，后台写作、编辑、发布、管理素材，体验像“装好就能用”。你会发现，Hexo 的优势更多体现在发布后的稳定与性能，Halo 的优势更多体现在持续维护与管理体验。

如果用一个简单的成本模型表达，把一次发布的总成本写成：

$C = C_{write} + C_{build} + C_{deploy} + C_{maintain}$

在 Hexo 上，$C_{deploy}$ 往往很低（静态文件直接托管），但对新手来说 $C_{build}$ 可能更高（依赖 Node、主题配置、构建命令、CI 等）；在 Halo 上，$C_{write}$ 低（后台即写即管），但 $C_{maintain}$ 更高（你要管服务、数据库、备份、升级）。这不是谁更强，而是你愿意把成本放在哪里。

另外还有一个容易被忽略的点：长期迁移与数据掌控。Hexo 的内容“天然可移植”，迁移基本就是拷贝 Markdown 与主题；Halo 的迁移更像传统网站，需要导出内容、迁移数据库、处理附件与插件配置。但反过来，Halo 也更适合做权限、评论、媒体库、在线编辑这些“动态能力”，它的“像系统一样管理内容”就是价值所在。

下面给一个很贴近 Hexo 思路的示例：用 Node 解析 Markdown 的 front-matter（很多 SSG 生态都会这样做），把文件变成可索引、可渲染的数据。

import matter from "gray-matter";

const md = `---
title: Hexo vs Halo
tags:
  - hexo
  - halo
category: tech
---
# 正文
这里是内容...`;

const { data, content } = matter(md);
console.log("title:", data.title);
console.log("tags:", data.tags);
console.log("content head:", content.slice(0, 20));

结论：比较流行度时，不如先问自己——我需要的是“写完就发布、快、稳、好迁移”的静态方案，还是“带后台、在线管理、像 CMS 一样运营”的动态方案。选对工具，你的博客才会更省心、更能长期更新。