TECH

AI时代个人建站实战指南：我怎样把网站跑在 Cloudflare Workers 上

从对象存储到 Cloudflare Workers 的真实迁移复盘，包含选型取舍、域名切换、自动部署、Umami 统计与 FAQ。

修订记录

先看结论

如果你只想先抄作业，这里是结论：

1. 我最后选 Cloudflare Workers + GitHub Actions + Umami，核心原因是稳定、简单、预算可控。
2. 我一开始用的是对象存储，后来发现访问成本和维护心智负担都比预期高，所以切换了方案。
3. 最终发布链路是：

Markdown -> push main -> GitHub Actions (npm ci + test + build) -> wrangler deploy ->
Cloudflare Workers (Assets) -> DNS www.flume.cn -> 浏览器访问

4. 这篇文章适合：已经有站点雏形，想把发布流程一次性走顺的人。

我为什么折腾这个站

我一开始的目标其实很朴素：做一个能长期维护下去的 AI 原生网站福禄门 flume-cn，这个网站可以落地我的很多想法，详见本网站“关于”部分。

当时给自己定了 3 个硬约束：

1. 稳定：不要隔三差五出奇怪问题。
2. 简单：我希望写内容，而不是天天运维。这一点在过去是不可能的，但是AI让它变成了可能。
3. 省钱：现阶段没打算为“基础访问”投入太多预算。

技术上，我选择了底层框架自己搭，而不是直接套文档框架。
以前我会觉得这件事很重，但现在有 AI 协助，很多页面和配置可以快速迭代，个性化空间也更大。

前提条件

开干之前，先把下面几件事确认好：

1. 我已经有一个域名：flume.cn。
   你也可以用自己的域名；如果暂时没有，也可以先用 *.workers.dev 跑通。
2. 本地站点已可构建（我这边是 Astro 项目，npm run build 能出 dist/）。
3. 默认在 WSL/Linux 环境执行命令（Node 版本满足项目要求）。
4. 本文以 www 作为主域名，canonical 统一到 https://www.flume.cn/。

我的真实选择过程：先上对象存储，再切 Cloudflare

我第一版是对象存储方案。
它的优点是上手快，但我后面实际用下来有两个问题：

1. 对“每次访问都会产生费用”这件事，我心理上不够踏实。
2. 手工和平台配置细节较多，长期维护不够轻量。

中间确实折腾了半天，NS、DNS 记录、workers.dev 子域名这些点都踩了一遍。
跑通那一刻我是真开心，之前那点焦虑基本没了。
有 AI 在旁边协助排错和补文档，效率确实提升明显。

我最后为什么换到 Cloudflare Workers

我最后选它，就一个原因：更贴合我当下这三个约束。

1. 发布路径统一：本地和 CI 都是 wrangler deploy，不用来回点控制台。
2. 扩展顺滑：后面要加 API 或定时任务，直接在 Workers 体系内演进。
3. 成本心智更稳：静态站阶段足够轻量，先把内容体系跑起来。
4. 配套成熟：Astro 构建产物 dist/ 直接上 Workers 静态资源。

关键决策表

最终落地结构

1. wrangler.jsonc
2. .github/workflows/deploy-cloudflare-workers.yml
3. scripts/rollback-cloudflare.sh
4. docs/spec/06-部署与运维-CloudflareWorkers.md

详细实施步骤

Step 1：域名接入 Cloudflare，并切换 NS

1. 在 Cloudflare 添加 flume.cn，选择 Free 计划。
2. DNS 导入页保留必要记录（尤其邮箱 MX/TXT），清理无效旧记录。
3. 到域名注册商（West.cn）修改域名服务器为 Cloudflare 提供的两条 NS。
4. 等待状态从 Pending 变为 Active。 验证命令（WSL）：

dig NS flume.cn +short

预期结果：返回 Cloudflare 分配的两条 NS（例如 carol.ns.cloudflare.com、mitchell.ns.cloudflare.com）。

Step 2：配置 Workers 静态资源部署

wrangler.jsonc 核心配置：

{
  "name": "flume-cn",
  "compatibility_date": "2026-02-12",
  "workers_dev": true,
  "assets": {
    "directory": "./dist",
    "not_found_handling": "404-page"
  },
  "routes": [
    { "pattern": "www.flume.cn", "custom_domain": true }
  ]
}

首次本地部署：

npm run build
npx wrangler login
npx wrangler deploy

预期结果：终端出现 Success! Uploaded ... files 以及部署成功提示。

如果提示注册 workers.dev 子域名：

1. 可以注册一个唯一子域名用于调试。
2. 不想用 workers.dev 的话，把 workers_dev 设为 false 后重新部署。

Step 3：接入 GitHub Actions 自动发布

触发策略：push main 自动构建并部署。

流水线步骤：

1. actions/checkout@v4
2. actions/setup-node@v4（读取 .nvmrc）
3. npm ci
4. npm run build
5. cloudflare/wrangler-action@v3 执行 deploy

仓库 Secrets：

1. CLOUDFLARE_API_TOKEN
2. CLOUDFLARE_ACCOUNT_ID 在这之前，需要去Cloudflare上配置相关的API Tokens，可以按我的思路配置： 预期结果：每次 push main 后，Actions 运行绿色通过并完成部署。

Step 4：接入 Umami 统计

目标是保留最小可观测能力，不引入重型埋点系统。

操作步骤：

1. 在 Umami 创建站点，拿到 website-id。
2. 在站点布局统一注入脚本（通过环境变量控制）。
3. 生产环境配置 SITE_ANALYTICS_WEBSITE_ID。
4. 发布后验证实时访问是否入库。 可以看到哪些地方的人，访问了你的网站：

我踩过的坑

1. 把 Cloudflare nameserver 当成 DNS 记录添加。 正确做法是去注册商修改域名 NS，不是在“解析记录”里新增 NS。
2. 删除 DNS 记录时误删邮箱相关 MX/TXT。 切换前要确认邮件服务是否仍在使用。
3. workers_dev 触发子域名注册流程。 若只想用正式域名，可设为 false；若保留调试域名，子域名需全局唯一。
4. 本地环境 Node 版本不一致。 统一以 WSL + .nvmrc 为准，减少 CI 偏差。
5. 如果你担心上线后出错，直接让 AI 先帮你生成一份“可执行的回滚脚本 + 使用说明”，再发布。

FAQ

Q1：我不想把代码放 GitHub，可以用这套吗？

可以。你可以本地 npx wrangler deploy 直接发布。
只是不走 GitHub Actions 的自动化链路。

Q2：workers.dev 是必须的吗？

不是。它是可选调试域名。
如果你只想用正式域名，workers_dev 设为 false 即可。

Q3：Cloudflare 给的 nameserver 为什么不能加在“解析记录”里？

因为它不是普通解析记录，而是“域名托管入口”。
要去域名注册商改 NS，而不是在 DNS 记录列表里新增一条 NS 解析。

Q4：我没有自己的域名，可以先跑通吗？

可以。先用 *.workers.dev 跑通功能，后面再绑定正式域名。

Q5：为什么我还要写 robots.txt 和 llms.txt？

因为我的网站本身就是 AI 原生网站，我就是希望 AI Agent 友好访问。 因为这两个文件直接影响搜索引擎和 AI 抓取策略。
它们和内容质量一样，都是可见性的一部分。

适用边界

这套方案更适合：

1. 个人网站、知识库、内容站。
2. 希望快速上线并持续更新的人。
3. 想先低成本起步，后续再渐进升级的人。

这套方案暂时不适合：

1. 一开始就有复杂后端事务系统。
2. 对本地化节点、专线、合规链路有强约束的企业级场景。

最后一句感受

这次给我最大的收获不是“换了一个云”，而是把建站流程变成了可复用的工程系统。
从“写完还要手工上线”变成“写完 push 就能发”，心态差很多。
AI 在这个过程中非常关键，没有AI，我无法在半天就完成这些，未来已来。 最后，欢迎访问我的成果，AI原生网站福禄门 https://www.flume.cn/ ，这是一个AI原生产品，我将用很少的时间，让我的AI小福，飞速迭代它： 在我改这篇文章的这段时间，小福已经帮我自动提了2个PR了，嘻嘻