前言

我的博客之前一直部署在个人购买的服务器上。由于前端和后端都是自己实现的，为了让前后端能够交互，确实需要一台暴露在外网的服务器。然而，个人维护服务器需要处理很多事情：代码更新后的 CI/CD、HTTPS 证书续签（从 2025 年开始每三个月就要操作一次，非常麻烦）、CDN 配置等等。最近服务器刚好到期，我便开始思考：个人博客真的需要这么复杂吗？答案是否定的。只要我接受无后端架构，市面上就有很多成熟且免费的解决方案。经过一番调研，我决定采用以下关键词来搭建新的博客：Hexo、GitHub、CloudFlare。

静态博客框架 - Hexo

程序员的文章通常以 Markdown 语法为基础，市面上有很多支持 Markdown 的静态博客框架。我选择 Hexo 主要是因为其主题 Butterfly 比较符合我的审美。本文并非从零开始的部署教程，Hexo 和 Butterfly 的官方文档已经非常详细，建议直接参考它们来了解如何使用。

托管仓库 - GitHub

这一点无需多言。为了实现 CI/CD，自然需要将代码和配置托管在公网上。由于后续会依赖 CloudFlare，GitHub 便成为了自然的选择。值得注意的是，很多教程建议将构建后的产物托管在 GitHub 上，但这并没有充分利用完整的 CI/CD 流程。我猜测这是因为 GitHub 提供了 GitHub Pages 功能，可以通过托管构建产物并支持 ${username}.github.io 域名访问，所以这种方式一直被沿用下来。

部署 - CloudFlare Pages

请注意，本教程建议在 GitHub 上托管源码，而非构建后的产物。，至于要怎么样使用这个源码，Netlify、GitHub Pages 和 CloudFlare Pages 都可以。

Netlify

网上有很多相关教程。授权 GitHub 仓库后，即可获得一个访问链接（通常是 *.netlify.app）。唯一需要注意的一点是，构建输出目录应填写 /public。这种方式的好处是，一旦源码仓库更新，便会通过 Webhook 自动触发构建和发布，推送后稍等片刻即可完成发布，非常省心。

GitHub Pages

这个网上也有很多教程，Hexo 和 GitHub 官方都提供了指南，结合两者按步骤操作即可。需要注意的是，这会创建两个仓库：一个是源码仓库，另一个是 ${username}.github.io 仓库（用于存放构建后的产物）。

CloudFlare Pages

CloudFlare Pages 的作用与 Netlify 类似。我选择 CloudFlare Pages 的原因在于，我会同时使用 CloudFlare 的对象存储和 CDN 服务，而 CloudFlare 提供了统一的管理控制台，集中管理更加方便。对于个人用户来说，其免费额度足够且资源丰富。虽然网上也有相关教程，但大多已不是最新版本，我在部署过程中遇到了一些坑，因此在这里详细说明一下。