Cloudflare Pages 部署静态博客 = 把代码推到 Git 仓库，Pages 自动跑构建、自动分发到全球 300+ 边缘节点，你在控制台只填三个字段（构建命令、输出目录、环境变量），不需要买服务器、不用装 Nginx、也不用管证书。 免费版给的是无限站点 + 无限带宽 + 每月 500 次构建，单个文件上限 25 MiB。——这个额度对一个日更博客绰绰有余。我在 2026 年 10 月把手上一个静态站从「VPS + Nginx」迁到 Pages，整个迁移花了不到 20 分钟，之后半年不用再碰服务器。它的代价是：静态站能用，需要后端就得另外接 Workers 或 Functions。
上面这段就是全文结论，可以直接拿走。下面是构建链路、逐步操作、以及三个我实际踩过的坑。
Cloudflare Pages 和 VPS 建站到底差在哪？
结论：差在「你维护什么」。VPS 建站你维护的是操作系统和 Web 服务，Pages 你维护的只有代码本身。 静态站的产物是一堆 HTML/CSS/JS 文件，理论上不需要任何服务端逻辑——既然不需要，就没有理由为它养一台机器。下面是两者的对账：
| 维度 | VPS + Nginx | Cloudflare Pages |
|---|---|---|
| 服务器 | 自己买、自己打补丁 | 无 |
| 证书 | Certbot 申请 + 续期 | 自动签发、自动续期 |
| 分发 | 单机，海外访问延迟高 | 全球边缘，就近返回 |
| 部署 | scp / rsync 上传 | git push 自动触发 |
| 成本 | 每年几十到几百元 | 免费额度内 ¥0 |
| 动态能力 | 什么都能跑 | 只有静态 + Functions |
| 维护 | 系统 / 服务 / 安全 | 基本为零 |
判断标准很简单：如果你的站是「文章 + 图片 + 样式」，没有登录、没有数据库、没有实时交互，那 Pages 是更省心的选择；一旦需要服务端逻辑，就把那部分单独放到 Workers，静态部分继续留 Pages。
怎么用 Cloudflare Pages 部署静态博客？六个步骤
第一步：本地先构建成功，再连 Pages
先把本地跑通，是整件事最省时间的一步。 很多人在 Pages 上反复失败，根因是本地就没构建成功，只是把错误带到了云端。
$ npm install
$ npm run build
$ ls dist/ # Hugo 是 public/，Astro 是 dist/，Vite 是 dist/
输出的那个目录就是后面要填的「构建输出目录」。记下它，填错这一步是白屏和 404 的头号原因。
第二步：Pages 连接 Git 仓库
进入 Cloudflare 控制台 → Workers & Pages → Create → Pages → Connect to Git，选你的 GitHub / GitLab 仓库。
构建参数按你的框架填：
| 框架 | Build command | Build output directory |
|---|---|---|
| Hugo | hugo --minify |
public |
| Astro | npm run build |
dist |
| Vite / Vue | npm run build |
dist |
| Next.js（静态导出） | npm run build |
out |
| 纯静态 | （留空） | / 或你的目录名 |
不知道填什么就选 "None" 预置，只填输出目录——它反而比选错预置更稳，因为预置会替你塞一些你不一定需要的构建参数。
第三步：等第一次构建，拿到 pages.dev 域名
保存后 Pages 立刻跑第一次构建，日志里能看到每条命令的输出。构建完成会给你一个 <项目名>.pages.dev 的域名，直接能访问。先用这个域名验证站点确实正常，再绑自定义域名——把两件事分开，出问题才知道是哪一层。
第四步：绑自定义域名
Custom domains → Set up a domain，输入 blog.example.com。如果你这个域名已经托管在 Cloudflare，它会自动写一条 CNAME 记录并签发证书。
这里是最容易卡住的地方：如果该子域名的 DNS 记录原来是一条 A 记录（指向旧服务器），必须先删掉那条 A 记录，否则 Pages 的 CNAME 记录无法写入，域名会一直卡在 "pending" 状态。我迁移时就卡了十几分钟，删掉旧 A 记录后 30 秒就绿了。
第五步：配环境变量
Settings → Environment variables，可以分别给 Production 和 Preview 两套环境设置。
SITE_URL = https://blog.example.com
API_TOKEN = 你的令牌（用 Secret 类型，别用明文）
关键认知：Pages 的环境变量对「构建过程」可见，对「浏览器里的代码」不可见。 也就是说，process.env.API_TOKEN 在构建时能被替换或读取，但纯静态产物里不会有它——把密钥写进前端代码再靠环境变量藏起来，这个思路在静态站上是行不通的。真正的运行时密钥要放到 Pages Functions 里，由函数去读。
第六步：享受预览部署
Pages 会给每个 Pull Request / 分支自动生成一条 *.pages.dev 预览链接。改版前先看预览、确认无误再合主干——这是静态站上最接近"灰度发布"的东西，值得用起来。
三个真会踩的坑
-
构建输出目录填错 → 站点空白或 404。 Pages 只会把「输出目录」里的内容发布出去。如果你填成了项目根目录，它会连
node_modules和源码一起试图发布，结果是找不到index.html。先本地ls确认产物目录名再填。 -
免费版每月 500 次构建会被频繁 push 耗尽。 用
git commit && git push调试样式的人，一晚上能烧掉几十次。调试阶段用npx wrangler pages deploy dist做直传部署，不消耗 Git 构建额度；等稳定了再走 Git 自动构建。另外每站单次构建最长约 20 分钟，超时也会算失败。 -
SPA 直接刷新子路由会 404。 单页应用的所有路由其实都由
index.html处理，但服务器并不知道。在项目根放一个_redirects文件：
text
/* /index.html 200
注意是 200 而不是 301——用 301 会变成真的重定向到首页，丢了路由。同理，如果站点原来是 WordPress 做的，记得配一批老的 301 规则把旧 URL 指到新地址，别让老页面积累的权重白白流失（这块思路和 Cache Rules 清理边缘缓存 时一样：改的是路径，保住的是收录）。
静态站也能有后端吗？
能，但要用对工具。Pages Functions 让你在同一个项目里写 /functions 目录下的服务端代码，处理表单提交、API 代理、鉴权这类逻辑。它本质就是 Workers 运行时，按请求数计费（免费额度每天 10 万次）。需要更复杂的边缘逻辑、KV 存储、定时任务时，直接上 Workers 更合适——比如我之前写的 Workers + KV 短链服务，就是纯 Workers 方案，一分钟部署好。
Cloudflare Pages 常见问题（2026）
Q：Pages 免费吗？有什么限制？
A：免费版给无限站点、无限带宽、每月 500 次构建、单站 20000 个文件、单文件 25 MiB。对个人博客足够。超出的主要代价是构建次数，不是流量。
Q：Pages 和 Workers 是什么关系？该选哪个？
A：Pages 面向静态站 + 构建流水线；Workers 面向边缘计算逻辑。新项目如果以静态内容为主就用 Pages，需要大量服务端逻辑就直接用 Workers，两者可以在同一个域名下并存。
Q：绑定自定义域名一直 pending 怎么办？
A：九成是 DNS 记录冲突。去 DNS 页面删掉该子域原有的 A / AAAA 记录，只保留 Pages 自动写入的 CNAME，然后点 Retry。证书签发通常几十秒内完成。
Q：构建失败在哪看日志？
A：控制台 → 项目 → Deployments → 点那次构建 → View build log。错误信息直接是构建命令的原样输出，和自己本地跑一遍一致，照着修即可。
Q：静态站用什么建比较好？
A：Hugo 构建最快（几百页秒级），Astro 适合内容 + 组件混合，Vite 系适合前端项目。选哪个取决于你的内容形态，不取决于 Pages——Pages 三者都支持。
一句总结
Cloudflare Pages 把「静态站运维」这件事整体删掉了：构建交给 Git 触发，分发交给全球边缘，证书交给自动化，你只需要保证代码能构建成功。判断要不要用它，就看你的站是不是纯静态——是，就没理由再养一台 VPS。