ranl's website

新闻

把个人博客从 localhost 搬到 Cloudflare：上线之后，写作流程才刚开始

从本地 Kite 写作到 Cloudflare Pages 自动部署，记录站点地址、构建配置、主题修改和域名选择中遇到的问题。

约 5 分钟读完 工程实践博客CloudflareKite部署

这次折腾部署，最先让我停下来想一想的，其实是一个很基础的问题：博客在自己电脑上已经能打开了，为什么别人还是看不到？

当时我通过 Kite 的本地后台写文章，浏览器里的地址是 http://localhost:1717/admin/。预览能看，样式正常，文章也能保存，很容易产生一种“网站已经做好了”的感觉。

但这个地址只是在访问自己电脑上的服务。要让别人访问，还需要把内容构建出来，放到一个持续对外提供访问的地方。

从这里开始，我才逐渐把本地写作、代码仓库和线上网站这几件事分清楚。

1. 先弄清楚，自己到底在运行什么

这次博客的结构可以画成这样：

本机 Kite 后台写作
        ↓ 保存
文章 Markdown、图片、主题与配置
        ↓ 构建
HTML、CSS、JavaScript 等静态文件
        ↓ 发布
Cloudflare Pages 上的公开网站

本地后台承担编辑和预览，线上站点负责给读者展示内容。

localhost 和 127.0.0.1 都指向访问者自己的设备。把这样的地址发给别人，并不会让对方访问到我的电脑。即使配置成局域网可访问，也还没有解决公网发布的问题。

我的博客最终采用了静态发布，所以线上读者访问页面时，不需要我的电脑继续开着，也不需要在 Cloudflare 上常驻运行本地的 Kite 编辑后台。

这也解释了另一个很容易混淆的问题：线上网站可以一直访问，不等于本地编辑后台也已经搬到了云端。

2. 第一次能部署，不代表以后更新方便

最开始考虑的是构建一个静态文件包，再上传到 Cloudflare。

这种方式适合验证第一次上线。但如果每次写完文章，都要重新构建、打包、上传，时间长了，发布本身就会变成负担。

所以后面我改成了 GitHub 和 Cloudflare Pages 联动：

本机写作并保存
    → Git 提交并推送
    → Cloudflare 构建
    → 更新线上网站

Cloudflare Pages 支持连接 Git 仓库，并根据分支变更触发构建和部署。这次我把 main 作为生产分支。Cloudflare Git 集成说明

这里有一个必须记住的边界：在 Kite 后台点击保存，只更新了本地文件。 后面的 Git 提交和推送仍然需要发生，Cloudflare 才能拿到新内容。

以后我的日常写作流程，就变成了先在本机预览，确认文章和图片没问题，再推送到仓库。

3. 云端构建要能自己跑起来

本机已经装好了工具，并不意味着 Cloudflare 的构建环境也知道怎么运行这个博客。

这次项目里保留了 kitew 和 kite.lock。前者提供项目的启动入口，后者记录所使用的 Kite 版本和相关依赖信息，避免只依赖本机某个碰巧已经安装好的版本。

Cloudflare Pages 的主要配置是：

配置项 本次设置
Git 生产分支 main
框架预设 None
构建命令 sh ./build-cloudflare.sh
构建输出目录 public
正式站点地址变量 KITE_SITE_BASEURL

构建脚本的核心内容如下，这是这次项目自己的脚本：

#!/bin/sh
set -eu
cd "$(dirname "$0")"

: "${KITE_SITE_BASEURL:=${CF_PAGES_URL:-}}"
if [ -z "$KITE_SITE_BASEURL" ]; then
  echo 'Set KITE_SITE_BASEURL to the public HTTPS site URL.' >&2
  exit 1
fi

export KITE_SITE_BASEURL
exec sh ./kitew build --verify

我把正式地址作为显式配置；没有设置时，才用 Cloudflare 提供的部署地址兜底。CF_PAGES_URL 表示当前部署的 URL，生产站点最好明确填写自己的正式地址，避免把临时预览地址当成长期站点地址。Cloudflare 构建配置与环境变量

这一步不只是为了让首页能打开。站点地址还可能影响文章链接、RSS 和 sitemap，因此构建时就应该使用线上地址，而不是留下本地的 localhost。

4. 想改线上样式，要改源文件

这次我还删掉了页脚里“由 Kite 驱动”的展示。

这件事提醒了我：线上展示出来的一小块内容，背后可能来自主题模板，而不在文章正文里。

我的处理顺序是先定位主题中的页脚模板，再修改源文件，最后重新构建检查。只改生成出来的 HTML，即使当时有效，下次构建也可能被原来的模板覆盖。

文章、图片、主题模板和配置都应进入同一套版本管理流程。以后哪次样式改坏了，也能找到对应的提交，而不是靠记忆猜自己动过哪里。

5. GitHub Pages 和 Cloudflare Pages，先看发布方式

我中途也问过：这和 GitHub Pages 有什么区别？

对这次需求来说，先弄懂共同点更有帮助：它们都可以承担静态站点的公开托管。真正影响我日常使用的，是代码放在哪里、在哪里构建、哪一步触发发布，以及后续如何绑定域名。

这次我最终采用的是 GitHub 保存源码、Cloudflare Pages 构建和托管的组合。它能满足当前的写作习惯，所以没有为了比较平台而反复迁移。

6. 域名可以晚一点再决定

网站能访问以后，我又开始纠结默认的 pages.dev 地址不好记。

我看过 .com，也考虑过 .space 等后缀。这里最容易误会的是：打开一个域名看到“正在出售”，不意味着它还可以按普通新注册的价格购买；那可能是已经被持有人注册后的转售。

另外，买域名时，首年价格和之后的续费安排需要分开看。具体价格会变，不能把当时看到的促销当成长期成本。

我这次暂时没有购买域名，先把网站和更新流程跑通。后面有了合适的名字，再绑定自己的域名。

如果将来换域名，除了重新绑定访问入口，还要检查站点地址配置、站内链接、RSS 和旧链接的处理。现在能随时换一个地址，并不代表积累了读者和外部链接之后，迁移仍然没有成本。

7. 这次上线之后，我固定下来的写作流程

目前的操作可以压缩成几步：

  1. 启动本机 Kite，在后台编辑文章。
  2. 检查文章状态、图片和本地预览。
  3. 查看 Git 变更，确认没有混入不应公开的文件。
  4. 提交并推送到生产分支。
  5. 等待 Cloudflare 构建成功，再打开线上文章检查。

不是每次保存都适合直接上线。草稿仍然应该作为草稿，确认好之后再发布。

这次最有价值的收获，是把“我能在自己电脑上看到它”和“别人能持续访问它”之间的流程补齐了。博客上线之后，我终于可以把注意力逐渐放回文章本身，而不用每次写完都重新研究一次怎么发布。