技术 · 2026年10月21日
把博客安放在云上：我的 Cloudflare Pages 工作流
没有服务器、没有数据库，也没有需要半夜重启的进程。一个静态博客如何做到打开浏览器就能写，点下发布就上线。
这个博客现在运行在 Cloudflare Pages 上。它的全部基础设施，是一份 Git 仓库、一个构建命令，以及一张绑定好的域名。没有服务器需要维护，也没有数据库需要备份。
但“静态”并不意味着“不能写”。相反，我现在的写作体验比过去用 WordPress 时更轻：打开 /admin，用 GitHub 登录，写 Markdown，插入图片，点发布。几分钟后，Cloudflare 会自动完成构建，文章出现在首页。
这篇文章记录这套工作流的来龙去脉，以及我在选择它时的一些取舍。
为什么是静态
动态博客的魅力在于“什么都能做”：插件、评论、统计、主题市场。但对我这样的个人写作者来说，大部分功能其实用不上，而它们带来的维护成本却是真实的。
静态博客的逻辑简单得多：
Markdown 文件 → 构建生成 HTML → 上传到全球边缘节点 → 读者访问没有请求时的数据库查询，没有服务端渲染，也没有因为某个插件更新而突然白屏的夜晚。页面就是文件，文件放在 CDN 上，访问速度快，安全面也小。
代价是：内容必须在构建之前存在。这对日报类网站不友好，但对一个更新频率以“周”为单位的个人博客来说，完全不是问题。
Git 就是内容数据库
所有文章都存放在 src/content/posts/ 目录下，每篇是一个 Markdown 文件：
---
title: 在清晨，重新开始记录
description: 当生活被切成越来越小的片段……
pubDate: 2026-10-28
tags:
- 随笔
- 生活
cover: /images/covers/dawn.svg
draft: false
---这样做的好处，在很多年后才会显现：
- 可迁移。 内容就是纯文本，随时可以换一个生成器，甚至直接用
cat阅读。 - 可版本化。 每一次修改都有 commit，写错了可以回滚，改了什么一目了然。
- 可离线。 没有网络的时候，依然可以在本地编辑、预览。
- 可自动化。 RSS、站点地图、阅读时长、相关推荐，都可以在构建时计算出来。
Git 仓库既是内容的存储，也是发布流程的触发器。一次 push，就是一次部署。
后台为什么还要有
如果只有 Git，写作流程会变成：打开编辑器 → 新建文件 → 填写 frontmatter → 提交 → push。对熟悉命令行的人不算难，但它把“写作”和“工程操作”绑在了一起。
我希望写作时只面对文字。所以这个博客附带了一个轻量的管理后台：
- 浏览器打开
/admin/，用 GitHub 账号登录。 - 在列表里选择一篇文章，或者新建一篇。
- 编辑标题、摘要、日期、标签、封面和正文。
- 保存草稿，或者直接发布。
后台并不直接操作服务器，它通过 GitHub API 把改动提交到仓库。Cloudflare Pages 监听到新的 commit，自动重新构建。整个链路里没有任何自建的持久化服务。
浏览器后台 → Cloudflare Pages Functions → GitHub API → 自动构建 → 新版本上线登录态保存在一个加密的 HttpOnly Cookie 里，GitHub Token 不会出现在浏览器 JavaScript 中。后台代码和 API 都在同一个 Pages 项目里，不需要额外部署一个 Worker。
一次发布发生了什么
假设我刚刚写完一篇新文章，点击“发布”：
| 步骤 | 发生的事 | 耗时 |
|---|---|---|
| 1 | 后台调用 /api/posts，提交 Markdown 到 GitHub | 约 1 秒 |
| 2 | GitHub 生成新的 commit | 即时 |
| 3 | Cloudflare Pages 收到 push 事件 | 数秒 |
| 4 | 安装依赖并执行 astro build | 约 1 分钟 |
| 5 | 新版本原子切换，旧版本保留可回滚 | 数秒 |
从点击到访客看到新文章，通常在两分钟以内。对于个人博客，这是一个很舒服的节奏：不会快到让人反复刷新数据，也不会慢到打断写作的心流。
我喜欢的几个细节
草稿是真正的草稿。 设置 draft: true 的文章会在构建时被过滤掉，即使它已经存在于仓库里，访客也看不到。发布只需要把开关关掉。
图片和文章在同一个仓库。 后台上传的图片会按年月归档到 public/images/uploads/，Markdown 里留下一个相对路径。没有对象存储的密钥，也没有外链失效的问题。
构建失败不会影响线上版本。 如果某次提交有语法错误，Cloudflare 会保留上一个成功的部署。我可以慢慢修，而不必担心网站突然打不开。
成本几乎为零。 静态请求不消耗太多资源，Pages 的免费额度对一个个人博客来说绰绰有余。
它不是万能的
我也想说清楚这套方案的边界：
- 它不适合需要实时互动、用户系统或复杂搜索的场景。
- 评论需要借助 Giscus 这样的第三方服务，数据不在自己手里。
- 构建时间会随着文章数量增长，但几千篇文章之内都还可以接受。
- 后台依赖 GitHub 的可用性。GitHub 出问题时，仍然可以本地编辑并 push。
技术选型从来不是选“最好的”，而是选“和你的生活匹配的”。我不需要一台永远在线的服务器，我需要的是一个能安静存放文字、并且在我按下发布后可靠上线的地方。
目前看来，Cloudflare Pages 很好地承担了这个角色。
