静态网站只有 HTML、CSS、JavaScript 和构建后的资源，不需要数据库或常驻后端。把这类网站放到 Cloudflare Pages，可以省去 VPS、Nginx、端口和证书的日常维护。代码由 GitHub 保存，Pages 负责构建和托管，DNS 服务商负责把自定义域名指向网站。
上线前需要准备什么
- 一个能够正常构建或直接打开的静态网站
- 一个 GitHub 仓库
- 一个 Cloudflare 账号
- 一个可以修改 DNS 记录的域名
先确认项目的发布目录。纯 HTML 项目可能直接发布仓库根目录；Astro、Vite
等项目通常需要执行构建命令，再发布
dist。目录填错时，部署可能显示成功，打开后却没有目标页面。
理清两条链路
部署时，代码沿着下面的方向流动。
本地项目 → GitHub 仓库 → Cloudflare Pages → 线上文件访客打开网站时，浏览器走的是另一条路。
浏览器 → DNS 查询 → Cloudflare Pages → HTTPS 响应 → 页面渲染这两条链路分开以后，排错会简单很多。Pages 提供的 pages.dev
地址异常，应先检查代码、构建命令和输出目录。pages.dev
正常而自定义域名异常，检查范围就能收窄到 DNS、域名验证和证书。
连接 GitHub 与 Pages
先把网站推送到 GitHub，并确定用于生产发布的分支。随后在 Cloudflare Pages 中导入仓库，填写生产分支、构建命令和输出目录。
常见配置如下。
| 项目类型 | 构建命令 | 输出目录 |
|---|---|---|
| 纯 HTML、CSS、JavaScript | 留空或使用平台允许的空构建配置 | 文件所在目录 |
| Astro | npm run build |
dist |
| Vite | npm run build |
dist |
首次部署完成后，先打开平台生成的 *.pages.dev
地址。确认状态码、页面标题、样式和主要交互均正常，再继续绑定域名。
curl -I https://项目名.pages.dev/预期结果包含成功的 HTTP 状态码和正确的内容类型。浏览器检查仍然不可省略，因为
curl -I 看不到布局和前端交互。
绑定自定义域名
在 Pages 项目中添加自定义域名。若域名的权威 DNS 仍由其他服务商管理，需要在该服务商处增加 CNAME。
类型 CNAME
名称 knowledge
目标 项目名.pages.dev.部分 DNS 控制台会自动处理目标末尾的点，部分控制台会把没有末尾点的目标当成相对域名。保存后要检查最终记录，确保目标没有被拼成下面这种形式。
项目名.pages.dev.你的域名.可以通过公共 DNS 查询验证记录。
curl -fsS \
'https://dns.google/resolve?name=你的完整域名&type=CNAME'DNS 返回正确结果后，等待 Pages 将自定义域名标记为可用，并确认 HTTPS 已生效。DNS 缓存受 TTL 影响，刚修改记录时，不同网络可能在一段时间内得到不同结果。
按层验收
按固定顺序检查，可以避免同时追查多个无关问题。
本地构建
↓
GitHub 生产分支
↓
Pages 临时域名
↓
公共 DNS
↓
自定义域名与 HTTPS
↓
页面内容- 本地构建成功，预览页面正常。
- GitHub 的生产分支包含目标提交。
pages.dev地址能够返回目标页面。- 公共 DNS 返回正确的 CNAME。
- Pages 中的自定义域名处于可用状态。
- 正式域名通过 HTTPS 返回目标页面。
curl -I https://项目名.pages.dev/
curl -I https://你的完整域名/
curl -sS https://你的完整域名/ \
| rg -o '<title>[^<]+</title>' \
| head -1最后一条命令可以确认服务器返回的页面标题，避免只看到 200
就误以为内容已经更新。
| 层级 | 检查方法 | 成功标志 |
|---|---|---|
| 本地 | 运行项目构建 | 成功生成目标路由 |
| GitHub | 查看生产分支 | 最新提交与待发布版本一致 |
| Pages | 打开临时域名 | 返回目标页面 |
| DNS | 查询 CNAME | 指向正确的 pages.dev. 地址 |
| HTTPS | 请求正式域名 | 返回成功状态码 |
| 内容 | 检查标题和关键页面 | 页面属于目标版本 |
常见故障
| 现象 | 先检查 | 问题通常所在的位置 |
|---|---|---|
| 本地构建失败 | 终端错误和依赖版本 | 代码、依赖或构建配置 |
| Pages 部署失败 | Deployment 日志 | 构建命令或输出目录 |
pages.dev 返回 404 |
发布目录和静态路由 | 部署产物 |
| 临时域名正常，正式域名失败 | 公共 DNS | CNAME、缓存或域名验证 |
| 正式域名返回 200，内容不对 | 页面标题和提交号 | 旧部署、缓存或生产分支 |
pages.dev 无法访问
查看 Pages 的部署日志，核对生产分支、构建命令和输出目录。纯静态项目不需要虚构一套构建流程，有构建工具的项目则必须发布生成后的目录。
自定义域名无法访问
先确认 pages.dev 正常，再查询公共 DNS。CNAME 目标错误、记录尚未传播或 Pages
域名验证失败，都只影响自定义域名这一段。
CNAME 被追加当前域名
DNS
服务商把目标识别成了相对域名。按照该服务商的规则，将目标改为完整域名，必要时补上末尾的
.，保存后重新查询公共 DNS。
Pages 一直显示域名验证失败
先保证公共 DNS 已经返回正确记录，再重试验证。若控制台保留了旧的失败任务，可以移除失败的域名绑定后重新添加。删除绑定前保留正确的 DNS 记录，避免再次引入变量。
GitHub CLI 登录出现网络错误
检查终端中的代理变量和本机代理端口是否一致。代理变量存在，但对应程序没有运行时，请求也会失败。
env | rg -i '^(http|https|all)_proxy='
ss -lntup
gh auth status日常发布与恢复
网站上线后，不需要每次重新配置域名。日常更新完成本地验证、提交和推送后，生产分支会触发下一次 Pages 部署。
git status --short --branch
npm run build
git diff --check
git add 计划发布的文件
git commit -m "Update website content"
git push具体的分支安排、Preview 验收和回滚方法见《用 Git 维护个人网站》。部署侧继续确认生产部署对应目标提交，并检查临时域名、正式域名和页面内容。域名、Pages 项目或平台目标没有变化时，不要改动 DNS。