为什么用 Hugo 与 Cloudflare Pages 搭建技术博客

Mon, 17 Aug 2026 20:00:00 +0800

搭建技术博客时，真正困难的不是把页面放到互联网上，而是找到一套几年后仍愿意继续使用的写作流程。我的核心需求有三个：文章归自己所有、维护成本足够低、网站本身能够成为技术能力的补充证明。

选择标准

我把需求拆成了四项可以检查的标准：

这套标准排除了需要长期维护数据库的动态博客，也排除了文章只能保存在平台后台的封闭方案。

Hugo 把 Markdown、模板和配置编译成普通静态 HTML。文章的元数据集中在文件开头：

1+++
2title = '一次性能问题的完整排查记录'
3date = 2026-08-17T20:00:00+08:00
4tags = ['性能分析', '复盘']
5+++

这意味着每篇文章都是一个可以复制、搜索、比较和长期保存的文本文件。即使以后不再使用 Hugo，正文也仍然可以迁移到其他系统。

Cloudflare Pages 连接 Git 仓库，在检测到新的提交后执行 Hugo 构建，然后把生成的静态文件发布到公开地址。日常流程因此只剩下四步：

Sun, 16 Aug 2026 20:00:00 +0800

很多技术文章描述了最终答案，却省略了答案成立的条件。读者可以照着复制代码，却无法判断自己的环境为什么得到不同结果。可复现记录需要把“做了什么”扩展成“在什么条件下做、如何知道它成功”。

避免从“最近学习了某工具”开始。更有价值的起点是一个能够判断成败的问题：

在固定数据和配置下，怎样确认一次训练任务真正完成，而不是进程仍然存活？

这个问题自然带出输入、约束、检查方法和完成标准。

环境信息不需要罗列整台电脑上的所有软件，只保留会改变结果的部分：

如果某个版本没有影响结果，就不必把它放进主要叙事，可以留在附录或锁文件中。

失败记录不是流水账。每次尝试只回答四个问题：

这样写可以保留真正的推理路径，也能防止同一个无效方案以后被重复尝试。

“没有报错”通常不是完成标准。以一个自动化任务为例，可以分层验证：

1进程层：任务是否仍然运行
2日志层：是否存在未处理异常
3产物层：预期文件是否完整生成
4指标层：关键数值是否满足约束
5评估层：产物是否通过独立验证

只有最接近真实目标的那一层，才能支持最终结论。

文章结尾应包含一段最短复现路径：从哪里取得代码、执行什么命令、预期看到什么，以及常见失败时先检查哪里。它不需要代替完整文档，但应该让几个月后的自己能够快速重新进入问题。

好的实践记录不是把过程写得更长，而是把关键判断写得更清楚。