从 Jekyll 到 Hugo：重构我的终端风格博客

Sun, 30 Aug 2026 00:00:00 +0800

之前的博客使用 Jekyll，最初只是一个简单的 GitHub Pages 站点。随着文章、剪藏、工具文档和个人项目逐渐增加，原来的目录和模板开始变得难以维护：内容目录、静态资源、页面模板和构建脚本之间的边界并不清晰，想增加一个新页面，往往需要同时修改多个 Jekyll 文件。

这次重构的目标不是把博客换成一个现成主题，而是重新整理它的结构，并保留这个站点原本的个性：一个带有终端 TUI 气质的个人站，同时支持普通网页模式和适合电子墨水屏的阅读模式。

为什么选择 Hugo

Jekyll 仍然足够稳定，也很适合 GitHub Pages。但这次更换框架，主要是因为 Hugo 更适合当前的维护方式：

Hugo 是单一二进制程序，构建链路不依赖 Ruby、Bundler 和 Gem。
Markdown 内容、模板、数据和静态文件有清晰的默认边界。
模板语言足够直接，适合构建一组小而明确的页面组件。
构建速度快，文章和剪藏数量增加后，日常预览仍然轻量。
Hugo Pipes 可以处理 SCSS、压缩 CSS 并生成带指纹的资源文件。

这并不意味着 Hugo 在所有场景下都优于 Jekyll。对于已经稳定运行、主题和插件生态高度依赖 Jekyll 的站点，迁移的收益可能不大。但对一个准备重新设计信息架构和交互方式的个人站来说，Hugo 提供了一个更干净的起点。

先确定目录边界

迁移时最重要的决定，是先确定哪些目录属于 Hugo，哪些目录属于独立项目，哪些目录只是构建产物。

当前项目的核心结构如下：

content/ Markdown 页面和文章
layouts/ Hugo 模板和可复用 partial
assets/ 由 Hugo Pipes 处理的 SCSS 等资源
static/ 原样复制到发布站点的文件
data/ 模板使用的结构化数据
go-change-lab/独立的 Vite/React/TypeScript 项目
cloudflare/ 可选的 Cloudflare Worker
public/ Hugo 生成的最终站点
resources/ Hugo Pipes 生成的缓存

content 只负责内容，layouts 负责表现，static 负责不需要 Hugo 处理的文件。public 和 resources 都是生成目录，不能把它们当成源文件手工维护。

Hugo on elonnzhang

从 Jekyll 到 Hugo：重构我的终端风格博客

为什么选择 Hugo

先确定目录边界