为什么要把博客搬到 Cloudflare？

长期以来，GitHub Pages 一直是搭建个人数字花园的首选，但随着内容和高清图片的积累，文档里那个「1GB 存储 / 100GB 月流量」的限制逐渐成为创作的枷锁。为了释放空间、提升访问速度，并实现“源码私有、内容公开”的安全诉求，我决定让 GitHub 继续充当代码冷库，而把线上发布交给 Cloudflare Pages。

Cloudflare 对私有仓库的支持极其友好：仓库可以保持 Private，Cloudflare 通过 OAuth 授权读取代码并在他们的全球节点上构建静态页。这样既能隐藏 Markdown 原稿和草稿，又能享受不限流量的 CDN 分发。

Cloudflare Pages 实战步骤

1. 连接 GitHub 仓库

在 Cloudflare Pages 新建项目，选择 Connect to Git，指定博客仓库（无论 Public 还是 Private）。建议授予“只读”权限，以减少安全暴露面。

2. 配置构建指令

在 “Set up builds and deployments” 页面中：

• Framework preset 选择 Jekyll（会自动填充默认命令）。
• 将 Build command 改为 bundle exec jekyll build，确保使用项目锁定的依赖版本。
• Build output directory 填写 _site。
• 新增环境变量：

JEKYLL_ENV=production
BUNDLE_WITHOUT=development

第一项保证生产模式下会启用 SEO/压缩逻辑，第二项能避免安装多余的开发依赖。

3. 执行首次部署

点击 Save and Deploy 后，Cloudflare 会立即拉取仓库并构建。如果构建失败，优先在“View build logs”中确认 Bundler、Gem 版本。多数情况下是缺少 Gemfile.lock 或没有执行 bundle exec 导致。

4. 管理与回滚

部署成功后，项目会出现在 Workers & Pages 控制台，可查看每次构建的 commit、耗时及流量使用情况。需要回滚时只要点选旧版本即可。

迁移过程中遇到的坑

1. 依赖冲突：Cloudflare 的默认 Ruby 与我本地 Gemfile.lock 不一致，初次构建直接报错。改用 bundle exec jekyll build 并提交 Gemfile.lock 后问题解决。
2. 环境变量缺失：未设置 JEKYLL_ENV=production 时，SEO 标签和资源压缩不会生效，最终页面与本地不同。
3. 私有仓库授权：若在 OAuth 授权时没有勾选仓库，后续将无法同步，需要在 Cloudflare 仪表盘重新授权。

本地到云端的写作闭环

为了让发布体验更顺滑，我配了一个 START_BLOG.bat 脚本，核心命令是：

chcp 65001
bundle exec jekyll serve --livereload

UTF-8 代码页解决了中文输出乱码，--livereload 则带来了“保存即刷新”的预览体验。流程如下：

1. 本地写作 → .bat 启动本地预览验证排版。
2. git push 到私有仓库。
3. Cloudflare 自动触发构建，几十秒内推送到全球节点。

迁移成果

这次迁移不仅消除了 GitHub Pages 的容量焦虑，也让源码隐匿于私有仓库、访问速度依靠 Cloudflare 全球加速。对我而言，最重要的收益是获得了创作的“确定性”：写好内容、推送一次即可，不再受限于平台的审查或配额。希望这份经历能为同样想要升级博客基础设施的你提供可复刻的范例。