1. 从“手动搬砖”到“自动流水线”为什么我们需要自动化部署如果你和我一样是个喜欢用 Hexo 写点东西的博主那你肯定经历过下面这个熟悉的“仪式”在本地电脑上敲完一篇新的 Markdown 文章保存然后在终端里敲下hexo clean hexo g等待静态文件生成最后再执行hexo d把生成好的public文件夹推送到 GitHub Pages 或者你的服务器上。这一套流程我称之为“手动搬砖”。刚开始可能觉得没什么但时间一长问题就来了。首先它把你绑死在了你的“主力机”上。你想在公司摸鱼时更新博客不好意思你得确保公司电脑上 Node.js、Git、Hexo 环境都配好了还得把博客源码仓库拉下来。其次这个过程容易出错。你有没有遇到过hexo d推送失败或者因为网络问题卡住半天更别提有时候本地环境升级了 Node 版本或者某个插件导致生成失败还得花时间去排查。最后它打断了你“写作-发布”的心流。写东西的灵感是连续的但部署这个动作是割裂的你得从一个创作工具切换到命令行执行一系列你并不关心的构建命令。我踩过几次坑之后就一直在想有没有一种方式能让我像写日记一样简单我只需要关心 Markdown 文件本身写好保存提交到 Git然后我的博客就自动更新了。我不需要关心 Node 版本不需要关心hexo generate命令甚至不需要在本地安装 Hexo。这就是“自动化部署”要解决的核心痛点将“内容创作”和“技术部署”彻底解耦。Cloudflare Pages 的出现完美地契合了这个需求。它本质上是一个为 Jamstack 架构设计的、全球化的静态网站托管平台。你可以把它理解为一个“智能的、全自动的构建机器人”。你只需要把 Hexo 博客的源代码注意是源代码不是生成后的public文件夹推送到 GitHub 或 GitLab 这样的代码仓库。Cloudflare Pages 会监听这个仓库的变动比如你git push了一篇新文章然后自动在它的云端服务器上拉取代码按照你预设的指令比如npm run build执行构建最后将生成的静态文件发布到它的全球 CDN 网络上。整个过程你完全不用插手。你的工作流从“本地写作 - 本地构建 - 手动上传”变成了“本地/在线写作 - 提交到 Git - 自动发布”。这不仅仅是节省了几分钟时间更是将发布流程从一项“技术任务”变成了一个“自然动作”。接下来我就带你一步步搭建这条“自动化流水线”彻底告别手动部署的烦恼。2. 前期准备理清思路备好“食材”在开始动手配置之前我们得先把“食材”和“菜谱”准备好避免过程中手忙脚乱。这里有几个关键点需要你提前确认它们决定了你后续配置的路径。2.1 理解两种仓库模式这是最重要的一步很多朋友在这里会混淆。传统的 Hexo 手动部署通常涉及两个仓库源码仓库存放你的 Hexo 项目所有源文件包括_config.yml主题配置文件、source/_posts里的 Markdown 文章、主题文件等。这个仓库是私密的还是公开的都可以。部署仓库通常是username.github.io这样的仓库里面只存放 Hexo 执行hexo generate后生成的public文件夹里的静态文件HTML, CSS, JS。你通过hexo d命令将内容推送到这里。而 Cloudflare Pages 自动化部署我们只需要关心第一个仓库——源码仓库。因为 Cloudflare Pages 会扮演原来“本地构建环境”和“部署命令”的角色。所以请确保你的 Hexo 博客项目已经是一个完整的 Git 仓库并且已经推送到了 GitHub 或 GitLabCloudflare Pages 支持这两家。如果你的项目还在本地没有关联远程仓库现在就用git init,git remote add origin ...,git push三连操作把它推上去。2.2 检查你的 package.json 构建脚本Cloudflare Pages 需要知道如何构建你的项目。对于 Hexo它默认并不认识所以我们需要通过package.json文件里的scripts来告诉它。打开你 Hexo 项目根目录下的package.json文件找到scripts部分。通常一个标准的 Hexo 项目会有类似下面的配置scripts: { build: hexo generate, clean: hexo clean, deploy: hexo deploy, server: hexo server }这里有个关键点也是很多教程会踩坑的地方Cloudflare Pages 的构建环境默认不会全局安装hexo-cli。如果你直接在它的构建命令里填hexo generate它会报错 “hexo: command not found”。因此我们必须通过项目本地的node_modules来调用 Hexo。而npm run build这个命令正是执行package.json里定义的build: hexo generate脚本。npm run会确保使用项目本地依赖的 Hexo。所以请务必确认你的package.json里有build: hexo generate这一行。如果没有就手动加上。这是自动化构建能成功的关键“开关”。2.3 准备好你的自定义域名可选但推荐虽然 Cloudflare Pages 会免费提供一个xxx.pages.dev的子域名给你但用自己的域名显然更酷也更专业。你需要拥有一个自己的域名可以在任何注册商购买并且最好能将这个域名的 DNS 解析服务转移到 Cloudflare这样管理起来最方便。如果暂时不想转移Cloudflare Pages 也支持仅添加 CNAME 记录的方式这个我们后面会详细说。3. 实战开始在 Cloudflare Pages 上配置 Hexo 自动化好了理论准备完毕我们开始动手。整个过程就像搭积木一步一步来非常清晰。3.1 创建并连接你的 Git 仓库首先登录你的 Cloudflare 仪表板。在侧边栏找到并点击“Workers Pages”然后选择“Pages”选项卡。点击“Create a project”这个大按钮。接下来你会看到“Connect to Git”的界面。点击按钮授权 Cloudflare Pages 访问你的 GitHub或 GitLab账户。授权成功后页面会列出你账户下的所有仓库。在这里请务必选择你 Hexo 博客的“源码仓库”就是我前面强调的那个包含了_config.yml和source目录的仓库而不是xxx.github.io那个部署仓库。选择仓库后点击“Begin setup”就进入了核心的配置页面。3.2 填写构建配置避开官方“小坑”配置页面主要有以下几个选项我们逐一填写项目名称 (Project name)系统会自动生成一个基于你的仓库名。你可以修改成一个简短好记的名字这会成为你xxx.pages.dev免费域名的一部分。生产分支 (Production branch)通常就是main或master分支根据你仓库的默认分支来选择。你的文章更新推送到这个分支就会触发自动构建和发布。框架预设 (Framework preset)这里非常关键请在下拉菜单中选择 “None”。因为 Cloudflare Pages 的预设列表里没有 Hexo如果我们选了其他框架比如 Vue.js、React它会注入错误的默认构建命令和环境变量导致构建失败。选“None”意味着我们完全自定义。构建命令 (Build command)输入npm run build。这就是我们之前准备的“开关”。Cloudflare Pages 会在构建环境中执行npm install安装所有依赖包括hexo然后运行这个命令来生成静态文件。构建输出目录 (Build output directory)输入public。这是 Hexo 默认将生成的静态文件存放的文件夹。Cloudflare Pages 会在这个目录里寻找最终的网站文件。配置示意图如下项目名称 my-hexo-blog 生产分支 main 框架预设 None 构建命令 npm run build 输出目录 public这里我要特别提一下我踩过的坑Cloudflare 自己的官方文档里在 Hexo 示例部分写的是使用hexo generate作为构建命令。我一开始照着做结果构建日志里赫然报错hexo: not found构建直接失败。原因就是我上面说的构建环境里没有全局的hexo命令。所以请一定记住用npm run build这是经过实测最稳的方案。填写完毕后点击“Save and Deploy”。Cloudflare Pages 会立即开始第一次构建。你会看到一个实时滚动的构建日志输出界面就像你在本地终端看到的一样。你可以在这里观察npm install是否顺利主题和插件有没有报错以及最终的hexo generate是否成功。3.3 绑定自定义域名让博客拥有专属门牌第一次构建成功后你的博客就已经通过xxx.pages.dev这个域名在线了但我们的目标是使用自己的域名。进入你的 Pages 项目详情页找到“Custom domains”选项卡点击“Set up a custom domain”。输入你想绑定的域名比如blog.yourdomain.com。接下来有两种情况最佳情况你的域名使用 Cloudflare 的 DNS。如果你的域名已经在 Cloudflare 上托管了 DNS 解析即你的域名服务器是 Cloudflare 提供的那么整个过程是全自动的。Cloudflare 会自动为你添加所需的 CNAME 或 A 记录并一键部署 SSL 证书免费的你几乎不用做任何操作。常见情况域名在其他注册商。比如你的域名在阿里云、GoDaddy 等。这时你需要选择“My DNS provider”。Cloudflare 会告诉你需要添加的 DNS 记录信息通常是一条 CNAME 记录名称 (Name)blog如果你要用二级域名blog.yourdomain.com目标/内容 (Target/Content)xxx.pages.dev你的 Cloudflare Pages 子域名TTL 自动然后你登录你的域名注册商后台在 DNS 管理页面手动添加这条 CNAME 记录。添加完成后回到 Cloudflare Pages 页面点击“Check DNS records”。系统会验证记录是否生效。生效后Cloudflare 同样会自动为你配置 SSL 证书。过几分钟你就可以用https://blog.yourdomain.com访问你的自动化 Hexo 博客了全程无需你手动申请或更新证书非常省心。4. 进阶优化与问题排查让流水线更稳健基础功能跑通后我们可以做一些优化让这个自动化流程更贴合你的需求同时也能应对一些常见问题。4.1 使用环境变量管理敏感配置你的_config.yml里可能有一些敏感信息比如第三方服务的 API Key、评论系统的密钥等。把这些直接提交到公开的 Git 仓库是不安全的。Cloudflare Pages 提供了环境变量的功能。进入你的 Pages 项目设置找到“Environment variables”选项。你可以在这里添加键值对例如DEPLOY_KEY: your_secret_key_here然后在你的 Hexo 配置或主题配置中可以通过process.env.DEPLOY_KEY来引用这个变量。但请注意Hexo 配置文件是 YAML不支持直接读取 Node.js 的process.env。一个常见的做法是在_config.yml中使用一个占位符然后在构建过程中通过脚本替换。或者更优雅的方式是使用像hexo-renderer-ejs这样的插件在模板中直接使用% process.env.KEY %。这需要根据你的具体需求来调整构建流程。4.2 配置预览分支实现“草稿”功能Cloudflare Pages 不仅对生产分支如main进行构建还可以为每一个 Pull Request (GitHub) 或 Merge Request (GitLab) 生成一个独立的、带随机域名的预览版本。这个功能太有用了你可以在项目设置的“Builds deployments”里开启这个功能。开启后每当你创建一个 PRCloudflare Pages 就会基于这个 PR 的代码分支进行一次构建并生成一个唯一的预览链接。你可以把这个链接分享给朋友预览文章效果或者自己检查样式、功能是否正常确认无误后再合并到main分支触发正式发布。这相当于一个内置的、免费的“草稿/预览”环境。4.3 构建缓存加速缩短等待时间每次构建都要执行npm install如果插件多可能会比较慢。Cloudflare Pages 支持构建缓存。你可以在项目根目录下创建一个_config.yml同级的.node-version文件指定 Node.js 版本并且 Cloudflare 会自动缓存node_modules目录。在“Builds deployments”的设置中你可以看到缓存相关的选项。合理利用缓存可以将后续构建时间缩短一半以上。4.4 遇到构建失败怎么办学会看日志自动化虽好但万一构建失败了怎么办别慌Cloudflare Pages 提供了非常详细的构建日志。任何时候构建失败你都可以点进那次失败的部署详情查看完整的日志输出。常见的失败原因和解决办法npm install失败可能是网络问题或者package.json里某个包的版本不兼容。可以尝试在本地删除node_modules和package-lock.json重新npm install测试确保本地能成功。hexo generate失败通常是主题或插件错误。日志会明确报出哪个文件哪一行有问题。根据错误信息回你的源码仓库修复。内存不足虽然少见但复杂的 Hexo 站点在构建时可能超出免费计划的限制。可以考虑优化主题减少大型插件或者检查是否有死循环的生成脚本。我的经验是90%的问题都能在构建日志里找到答案。把它当成你云端的“终端输出”仔细阅读错误信息就能快速定位问题。5. 新旧流程对比与效率提升感受“科技改变生活”最后我们来直观地对比一下自动化部署究竟给我们带来了什么。传统手动流程本地写完 Markdown。打开终端切换到博客目录。执行hexo clean hexo generate。等待生成完成。执行hexo deploy。等待推送完成。可能去服务器或 GitHub 刷新页面查看是否更新。耗时2-5分钟且需要全程关注。环境依赖必须在本机且环境必须正确。出错点本地 Node 环境、Git 推送网络、部署命令配置。心理负担这是一个需要打断写作的“任务”。Cloudflare Pages 自动化流程本地或任何地方写完 Markdown。执行git add .git commit -m 新文章git push origin main。结束。耗时推送代码的几秒钟。构建和发布在云端后台自动完成无需等待。环境依赖只需要 Git。你甚至可以用 GitHub 的网页编辑器直接在线写文章、提交。出错点集中于构建配置一次配好长期受益。心理负担几乎为零。发布变成了写作流程中一个自然的保存动作。效率的提升是数量级的。更重要的是它带来了自由。你可以在任何有 Git 的设备上更新博客平板、手机通过 Termius 等 SSH 工具、甚至网吧的电脑。你不再需要维护一个复杂的本地开发环境。对于团队博客来说协作也变得异常简单每个人只需要提交 Markdown剩下的全部交给自动化流水线。实测下来这套方案非常稳定。我自己的博客已经稳定运行了一年多期间发布了上百篇文章从未因部署问题操心过。每次写完文章轻轻一推几分钟后刷新网站新内容已然在目这种丝滑的体验才是技术本该带来的幸福感。如果你还在手动部署你的 Hexo 博客真心建议花上半小时配置一下 Cloudflare Pages这份时间投资绝对物超所值。