建站实践
为什么用 Hugo 与 Cloudflare Pages 搭建技术博客
从内容所有权、维护成本和简历展示三个角度，记录这套博客技术栈的选择依据。
搭建技术博客时，真正困难的不是把页面放到互联网上，而是找到一套几年后仍愿意继续使用的写作流程。我的核心需求有三个：文章归自己所有、维护成本足够低、网站本身能够成为技术能力的补充证明。
选择标准
我把需求拆成了四项可以检查的标准：
| 标准 | 具体要求 |
|---|---|
| 内容所有权 | 原稿保存在本地，并能完整进入 Git 版本管理 |
| 写作体验 | 使用 Markdown，不依赖在线编辑器 |
| 部署成本 | 不维护服务器，推送后自动发布 |
| 可迁移性 | 域名、托管平台或主题变化时，不必重写文章 |
这套标准排除了需要长期维护数据库的动态博客，也排除了文章只能保存在平台后台的封闭方案。
Hugo 负责什么
Hugo 把 Markdown、模板和配置编译成普通静态 HTML。文章的元数据集中在文件开头：
1+++
2title = '一次性能问题的完整排查记录'
3date = 2026-08-17T20:00:00+08:00
4tags = ['性能分析', '复盘']
5+++
这意味着每篇文章都是一个可以复制、搜索、比较和长期保存的文本文件。即使以后不再使用 Hugo，正文也仍然可以迁移到其他系统。
Cloudflare Pages 负责什么
Cloudflare Pages 连接 Git 仓库，在检测到新的提交后执行 Hugo 构建，然后把生成的静态文件发布到公开地址。日常流程因此只剩下四步：
1写 Markdown → 本地预览 → 提交 Git → 自动发布
托管平台不参与文章创作，也不是内容的唯一存储位置。即使更换平台，仓库里的源码和历史记录仍然完整。
为什么适合作为简历补充
一篇有效的技术文章应当证明至少一种能力：问题拆解、证据收集、工程实现或者复盘总结。相比只写“熟悉某项技术”，公开文章可以让读者看到判断是如何形成的。
网站本身也提供了另一层证据：信息架构、响应式设计、可访问性、自动部署和持续维护记录都可以被直接检查。
保留的边界
静态博客不是万能方案。它不适合需要复杂账户系统、实时数据或大量用户生成内容的网站。评论、搜索等功能应优先使用静态或第三方方案，避免为了边缘功能重新引入一整套后端。
最终选择不是因为这套组合功能最多，而是因为它的边界与个人技术博客最匹配。
END / 2026.08