Cloudflare Pages 部署静态站完整指南：从域名解析到自动构建

如果你正在找一个免费、速度快、自带全球 CDN、且支持自动构建的静态网站托管方案，Cloudflare Pages 几乎是 2026 年最值得优先考虑的选项之一。

我自己从 2025 年开始把多个工具站（包括单页 HTML 工具、Vite 构建的博客、以及基于 npm 的聚合导航站）陆续迁移到 Cloudflare Pages 上，整体体验是：部署流程比 Vercel 更简洁，国内访问速度比 GitHub Pages 稳定，而且自定义域名 + 自动 HTTPS 都是开箱即用。

这篇文章会把从零开始的完整流程拆清楚：从 GitHub 仓库准备、Cloudflare Pages 项目创建、自定义域名解析，到每次 git push 后的自动构建与部署。全程不需要写服务器代码，也不需要配置 CI/CD 脚本。

一、为什么选 Cloudflare Pages？（不只是因为免费）

在正式进入操作之前，先快速对齐一下选择逻辑。Cloudflare Pages 的核心优势可以总结为四点：

维度	Cloudflare Pages 表现
构建触发	绑定 Git 仓库后，每次 push 自动构建，无需手动上传
全球加速	依托 Cloudflare 的 Anycast 网络，静态资源边缘缓存
HTTPS	自动签发并续期 SSL 证书，支持强制 HTTPS 跳转
自定义域名	支持根域名和 www 子域名，CNAME 或 A 记录均可

对于个人站长、独立开发者、或者搭建工具站矩阵的场景来说，这些特性意味着你可以把精力完全放在写代码和做内容上，运维层面的工作几乎为零。

二、前置准备：你需要提前准备好什么

开始之前，确保以下三项已经就绪：

1. 一个 GitHub 账号（GitLab/google 也支持，但本文以 GitHub 为例）
2. 一个 Cloudflare 账号（免费版即可，注册地址：dash.cloudflare.com）
3. 一个已注册的域名（推荐在 Cloudflare 注册，解析设置最省事，相比其他也较便宜；如果在其他平台注册也可以，后面需要修改 DNS）

三、步骤一：在 GitHub 上准备好你的静态站点代码

Cloudflare Pages 的自动构建依赖于你的 Git 仓库结构。根据项目类型不同，仓库根目录的组织方式略有区别：

场景 A：纯静态 HTML（无构建工具）

适合单页工具站、简单的 HTML/CSS/JS 页面。仓库结构示例：

my-static-site/
├── index.html
├── css/
│   └── style.css
├── js/
│   └── app.js
└── images/
    └── logo.png

这种情况下，Cloudflare Pages 会直接部署根目录下的文件，不需要额外的构建命令。

场景 B：使用构建工具（Vite、Webpack、Hugo、Hexo 等）

以 Vite 项目为例，典型的仓库结构如下：

my-vite-blog/
├── public/
├── src/
├── index.html
├── package.json
├── vite.config.js
└── dist/          # 构建输出目录（通常不提交到 Git）

关键点：你需要在 Cloudflare Pages 的构建设置里指定：

• 构建命令：npm run build（或 pnpm build、yarn build）
• 输出目录：dist（或 build、public，根据你的工具配置）

四、步骤二：在 Cloudflare Pages 创建项目并连接仓库

登录 Cloudflare Dashboard，按以下流程操作：

1. 进入 Pages 面板

左侧导航栏找到 "Workers & Pages"，点击 "创建"，选择 "Pages" 标签页，然后点击 "连接到 Git"。

2. 授权 GitHub 访问

首次使用需要授权 Cloudflare 访问你的 GitHub 仓库。建议只授权特定仓库，而不是所有仓库，安全性更好。

3. 选择仓库并配置构建设置

选择你要部署的仓库后，进入构建设置页面。这里有几个关键字段需要填写：

设置项	说明	示例
项目名称	用于生成默认的 *.pages.dev 子域名	my-vite-blog
生产分支	触发构建的分支，通常是 main 或 master	main
构建命令	执行构建的 shell 命令	npm run build
构建输出目录	构建完成后，Cloudflare 要部署的文件夹	dist

根目录一般保持默认（/）即可，除非你的项目放在仓库的子文件夹里。

4. 保存并首次部署

点击 "保存并部署"，Cloudflare 会开始第一次构建。你可以在构建日志里实时看到进度，包括依赖安装、构建命令执行、以及文件上传过程。

构建成功后，你会得到一个类似 https://my-vite-blog.pages.dev 的临时域名，可以直接访问验证效果。

五、步骤三：配置自定义域名解析

*.pages.dev 的域名虽然能用，但对 SEO 和品牌来说不够专业。接下来我们把自定义域名绑定上去。

情况 A：域名在 Cloudflare 注册（最省事）

如果你的域名已经在 Cloudflare 管理，绑定过程是全自动的：

1. 进入你的 Pages 项目，点击 "自定义域" 标签
2. 点击 "设置自定义域"，输入你的域名（如 www.zyftools.com）
3. Cloudflare 会自动添加所需的 DNS 记录，并签发 SSL 证书
4. 等待几分钟，状态变为 "有效" 即可

情况 B：域名在其他平台注册（需要改 DNS）

这是大多数国内站长的实际情况。操作流程如下：

第一步：获取 Cloudflare 的 DNS 服务器地址

在 Cloudflare Dashboard 的 "网站" 列表中添加你的域名（如果还没添加）。添加完成后，Cloudflare 会给你两个 DNS 服务器地址，格式类似：

lara.ns.cloudflare.com
greg.ns.cloudflare.com

第二步：在原域名注册商处修改 DNS 服务器

登录你的域名注册商后台（如阿里云、腾讯云、Namecheap），找到 "修改 DNS 服务器" 或 "DNS 管理" 选项，把原有的 DNS 地址替换为 Cloudflare 提供的两个地址。

第三步：在 Cloudflare 添加 DNS 记录

DNS 服务器生效后，回到 Cloudflare Dashboard，进入该域名的 "DNS" 面板，添加以下记录：

类型	名称	内容	代理状态
CNAME	www	你的项目名.pages.dev	已代理（橙色云）
A	@（根域名）	192.0.2.1（占位，后续 Pages 会自动处理）	已代理

第四步：在 Pages 项目里绑定域名

回到 Pages 项目的 "自定义域" 面板，输入你要绑定的域名（如 www.zyftools.com 或 zyftools.com），按提示完成验证。验证通过后，SSL 证书会自动签发。

六、步骤四：验证自动构建流程

自定义域名配置完成后，整个自动化流水线就已经跑通了。我们来验证一下：

1. 在本地修改代码（比如改一下 index.html 里的标题）
2. git add . → git commit -m "update title" → git push origin main
3. 回到 Cloudflare Pages 的构建日志页面，你会看到一次新的构建自动触发
4. 构建完成后，访问你的自定义域名，确认修改已生效

这个流程一旦跑通，你后续的发布工作就只剩下 git push 这一件事。对于内容型博客或频繁迭代的工具站来说，这个效率提升是非常明显的。

七、进阶配置：让站点更专业、更安全

基础部署完成后，还有几个建议开启的配置项，能显著提升站点的专业度和 SEO 表现。

1. 强制 HTTPS 跳转

在 Pages 项目的 "规则" 设置里，确保 "301 - 永久重定向 HTTPS" 已开启。这会把所有 HTTP 请求 301 重定向到 HTTPS，对搜索引擎排名有正面影响。

2. 自定义 Headers（安全与缓存）

在仓库根目录创建 _headers 文件，可以控制响应头。例如：

/*
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin

/assets/*
  Cache-Control: public, max-age=31536000, immutable

这段配置做了两件事：

• 提升安全性（防止点击劫持、MIME 嗅探攻击）
• 对静态资源设置长期缓存，减少重复请求，加快页面加载

3. 404 页面

在构建输出目录里放一个 404.html，Cloudflare Pages 会自动将其作为自定义 404 页面返回。建议在这个页面里保留站点导航，降低用户流失率。

4. 构建缓存与依赖优化

如果你的构建时间比较长，可以在 package.json 里锁定依赖版本，并在 Cloudflare Pages 的构建设置里检查 "构建缓存" 是否开启。这样可以避免每次构建都重新下载全部依赖。

八、常见问题与排查思路

问题现象	可能原因	解决方案
构建失败，提示 command not found	构建命令写错或依赖未安装	检查构建命令是否与 package.json 里的 scripts 一致
页面空白，控制台报 404	输出目录配置错误	确认构建输出目录（如 dist）与实际生成路径一致
自定义域名显示 "无效"	DNS 记录未正确指向	检查 CNAME 是否指向 *.pages.dev，或根域名是否已完成验证
推送代码后没有自动构建	分支名称不匹配	确认 push 的分支与 Pages 设置里的"生产分支"一致
国内访问偶尔抽风	Cloudflare 边缘节点波动	属于 CDN 层面的正常波动，通常几分钟内恢复

九、总结：一条清晰的部署路径

把上面的流程串起来，一条标准的 Cloudflare Pages 部署路径是这样的：

准备代码仓库 → 连接 Cloudflare Pages → 配置构建命令与输出目录
      ↓
首次部署成功 → 绑定自定义域名 → 修改 DNS 服务器（如需要）
      ↓
验证自动构建 → 开启 HTTPS 强制跳转 → 配置 Headers 与缓存策略

对于个人站长和独立开发者来说，这套方案的最大价值在于把部署和运维的复杂度降到几乎为零。你只需要关心代码和内容，剩下的构建、分发、HTTPS、缓存，Cloudflare Pages 都会自动处理好。

如果你正在规划一个新的工具站、博客，或者想把现有的 GitHub Pages 站点迁移出来，Cloudflare Pages 是目前（2026 年）性价比最高的选择之一。

相关阅读

• Cloudflare Pages 官方文档（英文）
• Vite 构建配置最佳实践（如果你的项目基于 Vite）