静态站点生成器（SSG）这个品类存在很久了，但它的内涵一直在变。早年大家比的很简单：能不能把 Markdown 变成 HTML，构建快不快，模板好不好写。

这几年看下来，竞争的重点已经换了地方。

老几位的现状

Jekyll 是这类工具的鼻祖之一。它的历史包袱也很明显：Ruby 环境在 Windows 上不好装，插件质量的方差很大，构建速度在大站点上会很难受。新项目选它的人已经很少了。

Hugo 的卖点一直没变：构建速度。Go 写的东西，几千篇文章秒级出结果，这在需要频繁构建的场景里是硬优势。代价是模板语法（Go template）的学习曲线陡，改主题的门槛比别的工具高。

Hexo 在中文技术圈里很流行，Node 生态，EJS 模板对前端出身的人友好，插件也算齐全。它的构建速度属于中等，站点规模上去之后需要做优化。

Eleventy 走的是另一条路：不绑定框架、不预设目录结构、把选择权交给你。灵活度最高，代价是”什么都要自己定”，对新手不友好。

Astro 是这几年的新势力，它抓住的点是”内容站不需要把整个框架塞进浏览器”——默认输出零 JavaScript，需要交互的组件按岛屿（island）的方式单独加载。这个思路对内容站非常契合。

三个真正的趋势

第一，构建速度变成了营销战场。

Rust 和 Go 重写前端工具链是这个大趋势的一部分。对内容站来说，构建速度的意义不在于”省那几秒”，而在于它决定了你能接受多高的构建频率。构建要十分钟的站点，你不会想每改一个错别字就重新部署；构建只要十秒的站点，提交即部署就不会让人犹豫。

第二，内容工作流被提到了一等位置。

早年的 SSG 把内容当输入，现在很多工具开始管内容的结构：类型化 front-matter、集合（collection）定义、内容关系（引用、系列、分类）的建模。

这一层做得好不好，直接决定”写一个月之后还管不管得动”。文章到几十篇的时候，靠手写 front-matter 还能撑；到几百篇，字段名拼错、分类不一致、链接失效就会变成日常。

第三，部署链路的成熟反而降低了工具选择的重要性。

Cloudflare Pages、Vercel、Netlify 这类平台把 CI、CDN、预览环境打包成了一体：推代码就构建，每个 PR 有独立预览地址，回滚是一次点击。这带来的一个副作用是，换生成器的成本被大幅降低了——反正输出都是静态文件，部署层不认识你的工具。

所以现在纠结”选哪个生成器”，收益比五年前小得多。

反面观察：复杂度从需求长出来，从插件长出来

有个现象值得说：很多内容站点的复杂度，并不来自它的需求，而来自它攒下的插件。

装一个搜索插件、一个图片优化插件、一个评论插件、一个统计插件，每个都带走一部分构建时间和一份维护责任。半年后站点坏了，排查起来是一场灾难，因为你不知道是哪层的问题。

我的判断标准很简单：这个插件解决的问题，我用十分钟手工做一次能不能接受？ 能接受就不装。

怎么选

如果非要给个判断顺序，我会这么排：

  1. 内容规模——几十篇和几千篇，需要的东西完全不同
  2. 团队技能栈——模板语法跟人熟悉的技术是不是一路，这决定了改主题的成本
  3. 需要多少动态能力——纯内容站和需要评论、搜索、表单的站点，选型会分叉
  4. 构建时间能不能接受——这条会影响你的写作节奏，不是纯粹的技术指标

至于生态大小、星标数量这类指标，参考价值有限。内容站是长期项目，工具停更了也能跑——最坏的情况是自己接手维护那部分。

一个常被忽略的成本：内容迁移

选型的时候大家算的是构建速度和功能，很少有人算迁移成本。

内容站的核心资产是内容本身和它的结构：front-matter 的字段、目录组织、内部链接、图片路径、永久链接规则。换生成器的时候这些全都要跟着动，而且特别容易出错。

永久链接尤其危险。搜索引擎收录的是绝对 URL，规则一变老链接全部失效，除非逐条做重定向。如果哪天要换工具，第一件事就是把永久链接规则定死并写进配置，让 URL 跟生成器解耦——这件事越早做越省事。

另一个隐藏成本是积累下来的适配代码。站点跑久了，总会有一些为特定需求写的自定义脚本、标签插件、模板补丁。换工具时它们全部作废，重写一遍的代价通常被低估。

结论有点反直觉：内容越多、写得越久，越不该换工具——除非现在的工具真的卡住了你的手脚。换工具带来的新鲜感，通常撑不过第一轮迁移踩的坑；而踩坑的成本，是实打实要还的。

选型的收益在变小

SSG 这个品类未来会越来越”隐形”。它不会消失，但会变成内容工作流里不显眼的一环，就像现在我们不会去讨论某个网站的模板引擎是什么一样。

真正值得投入的地方，其实是内容模型和部署链路：前者决定你能写多久，后者决定你写完之后多久能到达读者。生成器只是中间那段。