从动态 CMS 到静态站点：一次克制的技术选择

最初的想法是使用 Halo。它有成熟的管理后台、主题市场和插件系统，写作体验也更接近一套完整 CMS。但目标托管平台是 GitHub Pages，这让选择发生了变化。

Halo 与 GitHub Pages 的边界

Halo 是一个运行在服务端的 Java 应用。它需要 JVM、持续运行的进程，以及用于保存文章和配置的数据库。浏览器访问站点时，服务器会根据内容和主题生成页面。

GitHub Pages 的能力不同：它只负责分发已经生成好的 HTML、CSS、JavaScript 和图片，不提供 Java 进程或数据库。因此，Halo 不能直接“安装”在 GitHub Pages 上。

这不是 Halo 的缺点，而是两种部署模型的边界：

方案	运行方式	适合场景
Halo	动态服务 + 数据库	有云服务器、需要在线后台和插件
Astro	构建时生成静态文件	GitHub Pages、内容以 Git 管理

为什么选择 Astro

Astro 对内容型网站很友好。文章使用 Markdown 保存，构建时被转换为静态页面；只有主题切换、移动导航和复制链接这类交互需要少量 JavaScript。

最终得到的目录很简单：

src/content/blog/   # Markdown 文章
src/pages/          # 页面与路由
src/components/     # 可复用界面
dist/               # 构建后的静态网站

这种结构带来三个直接收益：

1. 部署简单。 GitHub Actions 构建以后，把 dist 上传到 Pages 即可。
2. 访问稳定。 页面不依赖运行中的数据库，CDN 可以直接缓存。
3. 迁移容易。 Markdown 文章不会被特定后台的数据结构锁定。

保留 Halo 值得学习的部分

没有使用 Halo 运行时，不代表要放弃它成熟的设计经验。

这个站点仍然保留了主题系统常见的优点：全局设计变量、文章元数据、归档、RSS、暗色模式，以及统一的文章排版。区别只是这些能力在构建阶段完成，而不是由动态服务器实时生成。

如果未来需要多人编辑、网页后台、评论审核或复杂插件，可以把 Halo 部署到云服务器，再把域名指向它。内容使用 Markdown 保存，也让迁移有清晰的起点。

技术选择是对约束的回应

框架不是越完整越好。目标平台、维护成本和真正需要的功能，才决定什么是合适的。

对于一个由个人维护、主要发布长文章、部署在 GitHub Pages 的博客，静态生成不是退而求其次，而是一种更克制也更可靠的设计。