从 GitHub 到 Cloudflare Pages：搭建并维护一个个人博客

做个人网站时，很容易一开始就被框架、数据库、构建工具和各种部署选项弄得复杂。其实，如果网站主要由个人介绍、文章页面和少量交互组成，先从静态 HTML 开始，往往更容易理解每个文件的作用，也更方便逐步扩展。

本文以一个常见的个人博客工作流为例：网页文件放在 GitHub 仓库中，由 Cloudflare Pages 连接仓库并负责发布。文章仍然是独立的 HTML 文件，文章列表和首页预览通过普通链接指向它们。这个方式不依赖专门的内容管理系统，适合希望直接掌握文件和发布过程的个人站点。

一、先选择适合自己的网站结构

如果网站内容以个人介绍、联系信息和文章为主，静态 HTML 可以覆盖大部分需求。每个页面由浏览器直接读取，页面之间使用相对路径链接，不需要为每篇文章搭建数据库或后台编辑器。

首页：展示个人介绍、导航、联系方式和最新文章预览。
博客列表：集中展示文章标题、分类、日期和摘要。
文章页面：每篇文章单独保存，便于编辑、备份和分享。
独立功能：留言板等需要数据写入或验证的功能，可以继续交给 Pages Functions 和数据库处理。

静态页面并不意味着网站不能有动态功能。页面本身可以保持简单，而需要服务端处理的请求交给后端函数。关键是把网页内容、后端逻辑和机密配置分开管理。

二、把仓库目录整理清楚

目录不需要很复杂，但文件名和链接路径要保持一致。一个小型个人博客可以采用这样的结构：

bolg/
├── index.html                 # 个人主页
├── blog.html                  # 文章列表
├── blog_first_post.html       # 第一篇文章
├── blog_second_post.html      # 第二篇文章
├── guestbook.html             # 留言板页面
├── aladdin_moore_portrait.png # 头像图片
├── Telegram.png               # 联系二维码图片
└── functions/
    └── api/
        └── messages.js        # 留言板 API

以上是目录示意，具体文件以自己的 GitHub 仓库为准。对于现有网站，新增文章时可以继续沿用根目录的命名方式，不必为了追求整齐而随意移动已经被链接引用的文件。

文件名大小写也要保持一致。例如链接写成 blog_second_post.html，仓库中的文件也必须使用完全相同的大小写；图片路径同样如此。

三、每次写新文章，按三个位置更新

1. 新建独立文章文件

先复制一份现有文章页面作为模板，再修改页面标题、描述、分类、发布日期、预计阅读时间和正文。沿用同一套 CSS，可以让新文章自然继承网站的深色背景、蓝色强调色、目录和移动端排版。

例如，第二篇文章可以命名为 blog_second_post.html。文章中的导航链接、返回博客链接和目录锚点要检查一遍，确保指向真实存在的页面或标题。

2. 更新博客列表

打开 blog.html，在“全部文章”区域增加一张文章卡片。卡片至少包含标题链接、分类、摘要、作者、日期和阅读时间。新文章通常放在最上方，让读者先看到最新内容。

3. 更新首页最新文章预览

如果首页有“最新文章”区域，也要把标题、摘要、日期和阅读全文链接更新为新文章。这样读者从首页就能发现新内容，同时仍然可以通过博客入口查看全部文章。

只创建文章 HTML 文件，并不会自动让它出现在博客列表里。文章文件、博客列表和首页预览是三个独立位置，需要分别确认链接。

四、通过 GitHub 提交文章

打开 GitHub 仓库，确认当前分支和文件目录。
上传新的文章 HTML 文件到网站现有页面所在目录。
上传更新后的 blog.html 和 index.html。
检查文件名、扩展名和链接拼写，避免把 HTML 文件误存成 .txt。
填写清晰的提交说明，例如“Add second blog post”，然后提交到网站使用的分支。

使用 GitHub 管理文章的好处，是每次修改都会留下提交记录。若后来发现某次改动有问题，可以查看差异，必要时恢复到之前的版本，而不是只能依赖本地文件。

五、Cloudflare Pages 如何发布更新

当 Cloudflare Pages 项目通过 Git 集成连接到 GitHub 后，向已连接的分支推送变更会触发对应部署。对于不使用框架的静态 HTML 网站，Pages 可以直接部署 HTML、CSS、JavaScript 和图片等静态资源，不必为了发布一篇文章额外引入复杂构建步骤。

如果生产分支设置为 main，向 main 提交的变更会按项目配置进入生产部署流程。Git 集成还支持预览部署；在项目启用相应分支预览设置时，可以先检查预览版本，再把确认后的内容合并到生产分支。

在 Cloudflare 控制台打开 Workers & Pages，进入对应 Pages 项目。
打开部署记录，确认最新一次提交是否成功。
部署成功后，访问首页和文章地址，检查是否已更新。
如果部署失败，先查看构建日志和最近的文件改动，不要连续重复提交相同内容。

Cloudflare 官方文档：Git 集成与自动部署；部署静态 HTML 网站。

六、上线后检查哪些内容

检查项	检查方式	常见问题
首页	打开域名根路径	首页导航或最新文章没有更新
文章列表	打开 blog.html	文章数量、标题或链接遗漏
文章详情	直接打开新文章网址	文件名错误、返回链接失效
图片与样式	检查桌面和手机显示	相对路径错误、文件大小写不一致
留言板	打开页面并检查原有功能	误覆盖了函数文件或配置

测试时不要只从首页点击一次。建议分别直接打开首页、博客列表和文章详情页，确认每个地址都能单独访问。再用手机宽度检查导航、标题、表格和文章目录是否出现横向溢出。

七、把内容、后端和密钥分开

网站的公开 HTML 可以包含公开信息，例如页面文字、图片路径和 Turnstile 的 Sitekey；但私密密钥、管理员令牌和访问凭证不应该写在前端 HTML 或提交到公开仓库。

前端页面：负责显示内容和收集用户输入，不保存服务端私密凭证。
Pages Functions：负责需要服务端处理的 API 请求。
Secrets：在 Cloudflare 项目的 Variables and Secrets 设置中管理需要保密的值。
D1 绑定：让后端函数通过绑定访问数据库，不要把数据库管理凭证放进网页。

留言板使用 Turnstile 时，浏览器中的小组件只是产生验证令牌的一部分；后端仍需要通过 Siteverify 验证令牌。不能因为页面能够显示验证组件，就省略服务器端验证。

可进一步阅读 Cloudflare 官方说明：Pages Functions 绑定与 Secrets；Turnstile 服务端验证。

八、建立一个简单、可重复的更新习惯

发布前先备份当前版本，尤其是首页和留言板相关文件。
一次提交尽量只处理一类改动，例如一篇文章及其列表入口。
提交说明写清楚改了什么，方便日后查找。
保留现有文件路径；确实需要移动文件时，同步更新所有引用。
上线后检查部署状态和页面链接，再开始下一次改动。

个人博客最重要的不是一开始就拥有复杂的编辑系统，而是建立一套自己能理解、能检查、能恢复的发布流程。只要目录清楚、链接准确、密钥妥善保管，静态 HTML 也能成为一个长期维护的个人空间。

总结

从 GitHub 到 Cloudflare Pages 的个人博客工作流，可以归纳为：写好独立文章页面、更新博客列表和首页预览、提交到正确分支、检查部署结果、验证页面和功能。将公开内容与后端逻辑分开，并把密钥放在安全配置中，就能在保持简单的同时，逐步扩展网站能力。

参考资料

↑ 返回文章顶部