用 GitHub 和 Cloudflare 搭建网站：从第一张网页到自动部署

想搭一个个人网站，最容易卡住的往往不是写页面，而是后面的几个问题：代码放在哪里？怎么让别人访问？修改之后，是不是每次都要重新上传？域名又该接到哪儿？

这篇从一个只有首页的小网站开始，把流程完整走一遍。做完后，你会得到一个可以访问的地址，并建立一条固定的更新路径：修改代码 → 提交到 GitHub → Cloudflare 自动部署 → 网站更新。

本文以 Cloudflare Workers 的静态资源托管与 Git 集成为例，操作说明核对于 2026 年 10 月 12 日。控制台入口名称可能调整，以对应功能和官方文档为准。

一、先弄清 GitHub 和 Cloudflare 分别做什么

可以把 GitHub 理解为网站的代码仓库：页面、样式、脚本和配置放在这里，每次修改也有记录。Cloudflare 则负责把仓库中的项目部署出去，提供读者能打开的网页。

流程很简单：

1. 你在 GitHub 保存网站源码。
2. Cloudflare 连接这个仓库，读取指定分支。
3. Cloudflare 按配置部署网站。
4. 读者通过网站地址访问部署后的内容。

这里使用 GitHub 存代码，不需要另外启用 GitHub Pages。Cloudflare Pages 也是一种托管方案，但它的项目设置与 Workers 不完全相同；下面统一使用 Workers，避免把两套步骤混在一起。

第一次建站，先完成“网页能打开、修改能上线”这两件事。后台管理、评论和图片上传可以以后再加。

二、准备一个最小的网站仓库

你需要 GitHub 账号和 Cloudflare 账号。自定义域名可以稍后购买，第一次上线先使用 Cloudflare 提供的地址。

在 GitHub 新建一个仓库，例如 my-website。公开或私有都可以，之后要让 Cloudflare 获得这个仓库的访问权限。可以先添加 README，方便创建文件。

下面这个示例不使用前端框架，也不需要数据库。仓库只要包含这两个文件：

my-website/
├── public/
│   └── index.html
└── wrangler.jsonc

你可以直接在 GitHub 的文件创建页面填写 public/index.html；文件名里的斜杠会表示目录。小项目这样操作就够了，后续再换成本地编辑器和 Git 也不迟。GitHub 的新建文件说明介绍了具体操作。

1. 写一个能直接打开的首页

把下面的内容放进 public/index.html：

<!doctype html>
<html lang="zh-CN">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>我的第一个网站</title>
  <style>
    body { margin: 0; padding: 24px; background: #f5f4ee;
      color: #20372e; font-family: system-ui, sans-serif; }
    main { max-width: 720px; margin: 60px auto;
      padding: 28px; background: white; border-radius: 16px; }
    h1 { font-size: clamp(28px, 6vw, 44px); }
    p { line-height: 1.8; }
  </style>
</head>
<body>
  <main>
    <h1>你好，这是我的网站。</h1>
    <p>我会在这里记录学习、项目和日常思考。</p>
  </main>
</body>
</html>

这就是一张完整网页。index.html 是首页，viewport 这一行让页面按手机的实际宽度排版。先保持页面简单，方便判断部署是否成功。

2. 告诉 Cloudflare 要部署哪个目录

在仓库根目录创建 wrangler.jsonc：

{
  "name": "my-website",
  "compatibility_date": "2026-10-12",
  "assets": {
    "directory": "./public"
  }
}

name 是 Worker 的名称，后面在 Cloudflare 创建项目时也使用 my-website。assets.directory 指向要公开的网站文件目录；这里是 public，而不是整个仓库。

这个配置只托管静态文件，没有后端程序，因此没有 main 入口。后续如果使用框架，通常要先构建，再把目录改为该项目实际生成的 dist 或其他输出目录。静态资源配置文档说明了这些字段的用途。

不要把 .env、密码或 API Token 放到 public 里；这个目录中的文件会成为网站资源。

三、把 GitHub 仓库连接到 Cloudflare

登录 Cloudflare，进入 Workers & Pages，创建一个 Worker，并选择连接 Git 仓库的方式。如果界面先让你创建 Worker，也可以创建后到它的 Settings → Builds 中连接仓库。

按提示连接 GitHub，授权所需仓库，然后选择刚才的 my-website。对多个仓库的账号，只授权这个网站需要的仓库即可。

第一次配置，关注这几项：

“根目录”是执行部署命令、读取配置的位置；“静态资源目录”是要公开的网页文件夹。本文中，前者是仓库根目录，后者由 assets.directory 指向 public，两者用途不同。

确认后发起部署。Workers Builds负责 Git 集成，构建设置文档说明了构建与部署命令。示例中的命令由 Cloudflare 构建环境执行，不要求你先在本机运行。

怎么判断真的上线了？

部署过程中先看日志：仓库是否读取成功、配置是否找到、资源是否上传、部署是否完成。看到部署成功后，打开控制台显示的 workers.dev 地址。

如果出现“你好，这是我的网站。”，就完成了第一次上线。再用手机或窄屏打开一次，确认文字没有被截断。

如果打不开，先检查：

• 仓库里有没有 public/index.html，文件名大小写是否一致。
• wrangler.jsonc 是否在所选根目录中。
• 配置中的 name 是否与 Cloudflare 的 Worker 名称一致。
• 部署日志是否报错，而不是只看到构建已经开始。

不要一失败就同时修改多个设置。先解决日志中的第一个错误，再重新部署，更容易知道问题在哪里。

四、做一次更新，确认自动部署生效

网站能打开后，回到 GitHub，把首页中的一句话改成：

<p>这是我通过 GitHub 提交的第一次更新。</p>

提交到刚才设置的生产分支，然后观察 Cloudflare 的新构建。部署成功后，再打开网站，检查文字是否已经更新。

这次小测试很重要：它证明你建立的不只是一个网页地址，还有一条能持续维护网站的流程。

以后调整样式、增加页面，也沿用这条路径。简单网站可以直接在 GitHub 编辑；改动多时，使用本地编辑器、Git 分支和 Pull Request 会更方便。只有修改进入生产分支并完成部署，线上网站才会更新。

如果刷新后仍是旧内容，先确认最新提交是否部署成功，再检查浏览器缓存；不要只因为 GitHub 已经出现新代码，就认为线上一定更新了。

五、给网站绑定自己的域名

workers.dev 地址可以用于初步验证。准备长期使用时，再绑定自己的域名，例如 example.com 或 www.example.com。

域名在其他注册商购买也可以。采用本文的 Worker 自定义域名方式，需要对应域名已经作为有效区域接入 Cloudflare。

通常按这个顺序操作：

1. 在 Cloudflare 添加域名，检查导入的 DNS 记录。
2. 在域名注册商处，把名称服务器改为 Cloudflare 分配的服务器，并等待区域激活。
3. 打开 Worker 的 Settings → Domains & Routes，添加 Custom Domain。
4. 填写准备使用的域名，检查创建的 DNS 记录和 HTTPS 状态。
5. 用完整的 https 地址打开首页，确认显示的是刚部署的网站。

接入前保留已有邮箱等 DNS 记录。域名续费仍由注册商负责，更换名称服务器不等于转移域名所有权。

example.com 和 www.example.com 是两个主机名，不要假设配置一个后另一个也会自动可用。只选一个作为主入口时，另一个可以按需要配置跳转。

Cloudflare 的 Custom Domains 文档给出了前提和设置步骤。配置文件中的 routes 也可以声明自定义域名；以后维护部署配置时，要一并检查域名设置，避免新部署改变访问入口。

六、网站做大之后，再加哪些东西？

上面的示例适合个人介绍、项目展示和少量静态页面。如果你只是想先拥有一个独立网站，这已经是一个可以继续扩展的起点。

当你希望“登录后台写文章、访客留言、上传图片”时，就需要处理服务器端功能和数据保存。以这个博客为例：

• GitHub 保存程序源码和配置。
• Workers 处理登录、文章读取与保存等请求。
• D1 保存文章、草稿和其他结构化数据。
• R2 保存上传的图片文件。

这时有两种更新：改网站程序，需要提交代码并部署；在后台写文章，则由应用保存到数据库，不必每篇文章都重新构建程序。

添加数据库和图片桶并不会自动出现一个管理后台。你还需要相应的程序、资源绑定、数据库迁移和身份验证。可以从支持 Workers 的现成项目开始，但应先读清它的部署说明，再填写配置。

至于费用，先查看所用产品的套餐和实际用量。静态资源、程序请求、数据库和对象存储有各自的规则；不要把“能使用免费套餐”理解成所有功能都没有限制。

七、上线以后怎么维护？

第一次上线之后，留住三个习惯就很有帮助：

• 源码统一放在 GitHub。 修改能追溯，也方便在出错时找回之前的版本。
• 部署后亲自打开网站。 首页、内页、手机排版和链接都看一遍，不能只依赖成功日志。
• 内容和数据分别备份。 GitHub 的代码历史不能代替数据库和上传文件的备份。

对于这个最小网站，下一步可以先添加一个关于页，或者把样式移到单独的 CSS 文件。每次只改一小部分，提交、部署、检查，你就会逐渐熟悉网站从源码到上线的全过程。

从第一张网页开始，GitHub 帮你管理每一次修改，Cloudflare 帮你把这些修改交付给读者。把这条流程走通，后面的页面和功能就有了可以持续迭代的基础。