长期以来，Hexo 因其生成速度慢而受到一些用户的诟病。但事实果真如此吗？随着版本的不断迭代，Hexo 的性能是否有所改善？为了探究这个问题，我进行了一系列的性能测试，涵盖了从 Hexo v3 到最新的 v8 版本，并与以速度著称的 Hugo 进行了对比。
测试说明
测试分两种场景：
- 冷生成 (Cold Generate)：
hexo clean && hexo g，清缓存后的首次生成，模拟初始化/修改主题配置后的场景。 - 热生成 (Hot Generate)：在已有生成基础上再次
hexo g，利用缓存做增量生成，对应日常写作更新。
Hexo 各版本性能对比
样本规模：500 ~ 4000 篇，测试文章来源于 hexojs/hexo-many-posts，tags 数量为100个，categories 数量为13个，通过复制文件以观察不同规模下的表现。
测试环境
- Node：v24.8.0
- 操作系统：Windows 11 Pro 23H2
- 主题：hexo-theme-landscape（Hexo 与主题均为默认配置）
- 依赖：除 Hexo 主包外，其余 Hexo 相关依赖在不同版本对比中保持一致版本：
1 | { |
冷生成 (Cold Generate)
从图上能看到一条很清晰的优化曲线：
- v3 -> v4: 性能有显著提升，尤其是在生成（Generate）阶段，其主要改进包括移除 cheerio 依赖和改善
Cache of Rendered HTML机制，具体可查看速度就是关键！ —— 我们是如何让 Hexo 4.2 的生成速度提升 30% 的 - v4 -> v6: 这几个版本的性能表现非常接近，但总体上保持了较低的耗时，没有出现明显的性能退化。
- v6 -> v7: 有一次明显的跃迁。v7 在生成阶段的耗时大幅缩短，曲线接近水平，对规模增长不敏感，其主要改进来自于 hexo#5145
- v7 -> v8: v8 延续 v7 的表现，在加载上继续优化，目前最快。在 4000 篇上，v8 ≈ 23s，v3 ≈ 301s，其主要改进来自于在 category 和 tag 的查找上引入了二元关系索引结构 hexo#5605
热生成 (Hot Generate)
热生成里，各版本都比冷生成更快（缓存在发挥作用），但差异仍然存在：
- v7、v8 表现最稳。在 4000 篇规模下，时间依然很低。
- v8 在热生成下同样最快，4000 篇约 16s。
Hexo 大规模 / 极端规模测试
上面的测试聚焦在“普通个人博客”常见规模（最多 4000 篇、常规数量的标签/分类）。为了验证 Hexo 在“更极端的规模”下的表现，我又做了两组压力测试：
- 文章数提升至 10,000（标签 100 / 分类 13 不变）
- 标签、分类剧增：Tags = 2,500，Categories = 500（模拟极端碎片化的信息体系）
同时比较：
- 核心主题：
landscape（更贴近 Hexo 基线） - 实际使用主题：
hexo-theme-reimu（功能更多，包含额外组件、前端资源与渲染开销） - 框架版本：v7、v8 与 dev（2025-10 开发版）
- 场景：冷生成（Cold）与热生成（Hot）
文章 10k（Tags 100 / Categories 13）
landscape 主题
reimu 主题
高标签/分类（Tags 2500 / Categories 500）
landscape 主题
reimu 主题
内存概览
单位：最低稳定 --max-old-space-size（MB 级，≈ 表示该值附近即可；> 表示低于该值会 OOM）
10k 文章（100 tags / 13 cats）冷生成
| 版本 | landscape | reimu |
|---|---|---|
| v7 | >8192 | >8192 |
| v8 | ≈4096 | ≈4096 |
| dev | ≈4096 | ≈4096 |
极端标签/分类（2500 tags / 500 cats）冷生成
| 场景 | v7 | v8 | dev |
|---|---|---|---|
| 2000 posts landscape | >8192 | >4096 | >4096 |
| 2000 posts reimu | >12288 | >4096 | >4096 |
| 5000 posts landscape | >12288 | >8192 | >8192 |
| 5000 posts reimu | >12288 | >8192 | >8192 |
Hexo vs. Hugo
为了更直观，我用 hexo-theme-reimu 的 Hexo v8 站点和 hugo-theme-reimu 的 Hugo 站点做了同规模对比。
- 两套主题在功能上尽量保持一致
- Hugo 侧通过 shortcode 覆盖 Hexo 的内置 tag，用以对齐功能
- 两侧主题配置保持一致
- 两个框架对“归档”处理存在实现差异，可能引起细微时间差，结果仅供参考
对于图表的说明：
meta_generator和external_link是 Hexo 主题里默认启用的两个功能，分别用于在页面头部插入 meta generator 标签和把外链加上rel="noopener"属性。这两个功能会对生成速度有一定影响，且 Hugo 侧没有对应功能，因此在图中单独列出以供参考。hexo-renderer-marked（Hexo 默认）和hexo-renderer-markdown-it是两种不同的 Markdown 渲染器，后者在某些场景下性能更优，因此也单独列出以供参考。Hexo dev是基于最新的开发版本（2025 年 10 月），包含一些正在评审中的性能优化。
Hugo 依旧更快。在 4000 篇上，Hugo 大约是 Hexo v8 的一半。Go 语言底层和并行优化带来很强的吞吐。但 Hexo v8 的表现也不差。以 4000 篇为例，冷生成 ~34s，配合上各种优化甚至能达到 ~22s，对多数个人站点完全可接受。
未来展望：Hexo 未来会更快吗？
要把速度再向前推一大步，几乎绕不开“并行/多线程”。但就 Hexo 现有架构而言，全面并行并不容易：核心生成流程带有明显的顺序依赖与全局状态，很多插件也默认跑在同一上下文里。
可能的方向：
- 多实例并行：启动多个 Hexo 实例，分区或分片生成（例如文章分片、标签/分类/归档拆分），最后合并输出。优点是隔离清晰；难点在路由冲突、资源锁与产物合并策略。
- 单实例内的局部多线程：把重型、可隔离的环节（如渲染/语法高亮/部分数据预计算等）下放到工作线程，主线程只做调度与汇总。需要在缓存与上下文隔离、数据序列化/传输成本之间找到平衡。
我个人做过一次尝试：使用 piscina 把“代码高亮”并行化，结果反而更慢了。原因大概率在于任务粒度较小、线程创建与跨线程传输成本抵消了收益。（也有可能是我的实现不够好）
因此，短期内 Hexo 想通过“全链路并行”获得数量级的加速并不现实，更稳妥的路线是：持续优化热点路径、在可控边界上做局部并行。
结论
结论：过去确实慢，如今不慢了。
-
老版本用户 (v6 及之前)：文章多的话，升级到 v8 的体感提升很明显。
-
新用户：v8 的速度足以覆盖绝大多数个人博客/中小型站点需求，生态与社区仍是优势。
-
极致性能：规模特别大、对秒级很敏感的项目，Hugo 会更合适。
-
如果你感觉 Hexo 仍然偏慢，常见原因多半在于“未优化的插件/主题”，或是开启了
relative_link、highlight.auto_detect等非常耗时的配置。优先排查并升级相关依赖，必要时更换实现开销大的插件或主题。
额外补充：即便在 10k 文章的压力级别下，v8 / dev 仍能把冷生成控制在 ~1 分钟以内（正常标签规模），问题真正变“难看”往往出现在标签 / 分类过度碎片化（数千级）导致内存与关系构建爆炸。若你已经逼近这个区间，请优先重构信息结构，而不是一味堆硬件或拉内存上限。
总之，性能已经不再是 Hexo 的硬伤。v7/v8 的优化是实打实的，Hexo 正在性能与生态之间取得更好的平衡。
说些什么吧！