Cloudflare Pages + GitHub 最省心的时候，体验大概是：改代码、推送、等几十秒、网站更新。
最折腾的时候则是：构建失败后去改 DNS，域名打不开后又重装依赖，最后三个问题叠在一起，谁也说不清网站为什么突然好了。
先把四个东西认清
- 源码仓库：真正保存代码和版本历史的地方。
- 生产分支：通常是
main，只有它的成功部署会更新正式站。 - Pages 项目：Cloudflare 里接收构建产物的目标。
- 自定义域名：把访客带到该 Pages 项目的入口。
它们彼此有关，但不是同一个东西。仓库推送成功不等于构建成功；构建成功不等于自定义域名一定配置正确；DNS 正常也救不了一份根本没生成的 index.html。
小站最重要的是隔离
一个独立站点尽量使用独立仓库或至少独立、明确的目录，并对应唯一的 Pages 项目。不要为了省一个名字，把文章站的构建产物上传到游戏站项目，更不要顺手复用别人的 Worker、KV 或数据库绑定。
Git 集成和工作流部署怎么选
Cloudflare Pages 可以直接连接 GitHub：推送生产分支后自动构建，其他分支通常产生预览部署。这适合结构简单、密钥少的小站。
也可以由 GitHub Actions 构建，再使用 Wrangler 把确定的输出目录部署到指定 Pages 项目。这样更容易加入目标保护、内容指纹和部署后验证，但工作流本身也需要维护。
两种方式没有谁天生更高级。重点是选定一条生产路径并写清楚，不要一会儿让 Pages 自己构建，一会儿又从本地直接上传，最后线上版本和仓库对不上。
部署前先制造一个能回去的点
低风险改动也应该知道当前正常版本的提交 SHA。可以创建回滚分支或标签，至少保证“出问题时回到哪里”不是靠记忆。
提交信息别全写 update。像“扩充 EXIF 指南并增加 404”这种描述，半年后还能看懂；连续十二个“fix”只会让提交历史像事故现场。
构建命令和输出目录必须成对
假设构建命令是 npm run build，项目生成文件到 dist，那么 Pages 或部署命令就必须上传 dist。构建日志说成功，但部署的是另一个空目录，正式站照样什么都没有。
静态站至少应在部署前检查：
- 根目录是否有可访问的首页。
- 站内链接指向的文件是否存在。
- sitemap、robots.txt 和 404 是否生成。
- 资源路径在自定义域名下是否正确。
- 构建产物中有没有误带密钥、源映射或本地配置。
失败时按阶段看，不要跨层乱修
依赖安装失败
看 Node 版本、锁文件和包源。不要先碰 DNS。
构建失败
看第一条编译错误、缺失文件和环境变量。旧版本通常仍在线，先别为了“抢救”把生产域名删掉。
上传失败
检查 API Token 权限、账户 ID、项目名和输出目录。权限不足与网页代码无关。
部署成功但自定义域名异常
先访问本次部署生成的 pages.dev 地址。如果它正常，再检查自定义域名、证书和 DNS；如果它也不正常，问题还在构建产物或项目配置。
DNS 记录的含义不熟时，先看DNS 查询到底在查什么，别把 CNAME 当 301 跳转。
回滚不是重新上传一份“差不多的旧代码”
Cloudflare Pages 的成功生产部署可以作为回滚目标。真正的回滚应该指向一个已知正常的部署或 Git 提交，而不是从电脑某个“最终版2真的最终.zip”里凭感觉找。
回滚完成后还要验证正式域名，而不只是后台出现绿色状态。检查首页、至少一个深层链接、静态资源、404 和关键功能，再决定是否继续修新版本。
缓存会制造“我明明改了”的错觉
HTML 通常不适合长期 immutable 缓存；带内容哈希或明确版本号的 CSS、JS 才适合长缓存。修改资源却沿用旧 URL 时，浏览器和边缘缓存都可能继续给你旧文件。
解决办法是合理设置缓存头、让构建产生带哈希文件名，或在确实需要时更新资源版本参数。不要每次都全站清缓存，那会掩盖真正的缓存策略问题。
一套安静但可靠的发布顺序
确认目标 → 建回滚点 → 本地构建和检查 → 推送生产分支 → 确认部署成功 → 检查正式域名。
这套流程看起来没有“直接上线”刺激，但网站运维最理想的状态，本来就应该有点无聊。
官方说明：Pages Git 集成 · Pages 生产回滚