GitHub Pages 和 Cloudflare Pages，我为什么同时用？

我的网站全部是静态前端：没有数据库，没有登录，没有自己的服务器。

部署这件事，我同时用了 GitHub Pages 和 Cloudflare Pages。不是因为喜欢折腾，而是因为一开始就是这么做起来的，后来发现两者各有合适的位置。

如果你正在选静态托管，这篇写的是我实际踩过的差别，不是平台参数复读。

GitHub Pages 适合什么

GitHub Pages 最大的好处是简单：代码在 GitHub，开一个仓库，推上去就能发布。

它适合：

我的很多早期小站都放在 GitHub Pages；Hub 和这个博客后来放在 Cloudflare Pages。自定义域名在 GitHub Pages 上只需要在仓库里放一个 CNAME 文件，再去 DNS 加一条记录。

但它有几个需要提前知道的限制：

我遇到过最典型的情况，是 git push 一直失败，但 GitHub Contents API 还能用。最后是通过 API 把构建产物提交上去的。

这不是一个优雅的方案，但它说明了一件事：静态部署的“发布”不一定要绑死在 git push 上。

Cloudflare Pages 的心智模型更像一个前端托管平台：

对于有构建步骤的项目，它比 GitHub Pages 顺手。尤其是预览部署：改一个页面，先看预览链接，再决定要不要合并。

我的「不烧心鉴定所」就放在 Cloudflare Pages。它更适合那种“构建产物和源站分开、需要一点边缘能力”的场景。

但 Cloudflare Pages 也不是没有成本：

这张表不是绝对的。真正的决定因素通常是：你以后会不会经常改它。

一个一年不动一次的静态页，放哪里都行。一个每周都要发文章、改样式、看预览的博客，构建体验就很重要。

一半是历史原因。

早期站点都在 GitHub Pages，迁移的成本大于收益。后来新项目需要预览和更灵活的静态配置，才开始用 Cloudflare Pages。

另一半是风险分散。

两个平台都免费，都支持自定义域名。把全部站点绑在一个平台上，遇到构建故障或账号问题时没有退路。分开之后，至少不会同时全挂。

但我不建议为了“分散风险”把同一个站点部署两份。那会带来重复内容、canonical 混乱和双倍维护成本。分散的是不同站点，不是同一个页面的多个副本。

我会选：

原因不是 Cloudflare 一定比 GitHub Pages 快，而是博客会持续更新，预览部署和构建配置的体验更重要。

Astro 的好处是默认输出静态 HTML，客户端 JavaScript 很少；内容用 Markdown 管理，不需要数据库和后台。对一个人维护的博客来说，这比“功能齐全的 CMS”更可持续。

不管选哪个平台，上线前至少检查这些：

绝对路径。 部署在子目录时，/assets/app.js 会指向域名根目录，而不是项目目录。Vite/Astro 项目要正确设置 base，或者用相对路径。

SPA 回退。 单页应用把所有路径都重写到 index.html，静态博客不需要这个。配错了会让 404 页面失效，也会让搜索引擎抓到重复内容。

缓存。 静态资源可以长缓存，HTML 不要长缓存。改完标题却发现线上还是旧页面，通常不是没部署，而是缓存。

canonical。 同一篇文章不要同时挂在两个域名或两个路径下。选一个主版本，其他版本重定向。

平台不是备份。 代码在 GitHub，构建产物在平台，文章源文件也要在本地或仓库里。不要把唯一副本放在某个后台编辑器里。

GitHub Pages 和 Cloudflare Pages 都能把静态网站跑起来。真正要选的是工作流：

工具不是身份。能稳定发布、能持续维护、出问题时有备用路径，比“用了哪个平台”重要得多。

参考：