静态站点部署入门
托管一个静态网站或前端应用，传统方式要自己租服务器、配 Nginx、申请 HTTPS 证书、接 CDN，环节繁琐。Cloudflare Pages 把这些事打包成一套自动化流程，你只要把代码推到 Git 仓库，构建、部署、分发、证书全部由平台接管。这一篇从它的定位讲起，用 Git 集成完成第一次自动构建部署。
Pages 是什么
Cloudflare Pages 是一个面向静态站点和前端全栈应用的托管平台。它把构建、部署、CDN 分发、HTTPS 证书这四件事打包成一套自动化流程，你只需要把代码推到 Git 仓库，剩下的事平台全部接管。
它的核心能力有四点
| 能力 | 说明 |
|---|---|
| Git 自动构建 | 连接 GitHub 或 GitLab 后，每次推送自动触发构建和部署 |
| 全球 CDN | 静态资源分发到 Cloudflare 全球节点，访问延迟极低 |
| 自动 HTTPS | 默认域名和自定义域名都自动签发并续期证书 |
| 预览部署 | 每个分支、每次合并请求都会生成独立的预览地址 |
Pages 与 Workers 的定位区别
Cloudflare 平台上还有一个叫 Workers 的服务，也跑在边缘网络上，初次接触很容易和 Pages 混淆。两者定位完全不同。
| 维度 | Cloudflare Pages | Cloudflare Workers |
|---|---|---|
| 主要用途 | 静态站点和前端应用托管 | 边缘计算函数和 API 服务 |
| 部署方式 | Git 集成为主，推送即部署 | Wrangler 命令行为主，代码即部署 |
| 资源模型 | 静态文件优先，可附加 Functions | 函数优先，静态资源靠 Assets 绑定 |
| 构建能力 | 内置 CI，支持框架预设和构建命令 | 无内置构建，代码直接上线 |
| 路由方式 | 静态文件路由加 Functions 文件路由 | 完全由代码控制 |
| 适用场景 | 博客、文档站、营销页、前端 SPA | API 网关、代理服务、边缘逻辑处理 |
一句话概括，Pages 适合”有大量静态资源要分发”的场景，Workers 适合”每个请求都要算一下”的场景。但两者不是非此即彼，Pages 内置的 Functions 功能本身就跑在 Workers 运行时上，这部分后面会专门讲。
连接 Git 仓库
Pages 推荐的部署方式是 Git 集成，先在 GitHub 或 GitLab 准备一个仓库。以 GitHub 为例，按以下步骤操作。
- 登录 Cloudflare 仪表盘，进入 Workers 和 Pages
- 点击 创建 按钮，选择 Pages 标签页
- 点击 连接到 Git 按钮
- 授权 Cloudflare 访问你的 GitHub 账号
- 选择要连接的仓库，点击 开始设置
授权环节可以只授权指定仓库，避免给整个账号开权限。连接完成后会进入构建配置页面，这一篇先用默认配置跑通流程，详细配置下一篇再讲。
框架预设
Pages 内置了常见前端框架的构建预设，能自动识别并填好构建命令和输出目录。常见的预设如下。
| 框架 | 构建命令 | 输出目录 |
|---|---|---|
| Create React App | npm run build |
build |
| Vite | npm run build |
dist |
| Next.js | npm run build |
.next 或静态导出 |
| Vue CLI | npm run build |
dist |
| Hugo | hugo |
public |
| Hexo | npx hexo generate |
public |
| Gatsby | npm run build |
public |
如果仓库根目录有框架的标识文件，比如 package.json 里写了 vite 依赖，或者有 config.toml 这种 Hugo 配置，Pages 会自动选中对应预设。识别错了也能手动改，预设只是帮你填默认值，不影响实际构建行为。
需要特别说明的是 Next.js。它默认是 SSR 模式，输出目录 .next 包含服务端逻辑，纯静态部署需要配置 next export 或在 next.config.js 里开启静态导出。如果项目依赖服务端渲染，建议直接用 Pages 的 Next.js 适配器，而不是当纯静态站点处理。
自动构建部署流程
设置完成后点击 保存并部署，第一次构建就会跑起来。整个流程是这样的。
- 你向仓库推送代码，或者点一次部署按钮
- Pages 拉取仓库代码到构建环境
- 按预设或自定义命令安装依赖并执行构建
- 把输出目录里的文件上传到 Cloudflare 存储
- 在全球 CDN 节点刷新缓存
- 为本次部署生成一个唯一的预览地址
构建日志在仪表盘的 部署 详情页能看到，包括依赖安装、构建命令、上传文件数等每一步的输出。如果构建失败，日志会标红报错行，照着修就行。
成功部署后会得到一个生产域名，格式为 https://你的项目名.pages.dev。pages.dev 是 Cloudflare 给 Pages 项目分配的免费子域名，和 Workers 的 workers.dev 类似。访问这个地址就能看到你的站点。
之后每次往生产分支（默认是 main 或 master）推送代码，都会自动触发一次新的构建部署。部署成功后生产域名会立刻指向新版本，旧的部署记录依然保留，可以随时回滚。
部署预览
预览部署是 Pages 最实用的功能之一。除了生产分支，其他分支的每次推送也会被构建，并生成独立的预览地址。
| 部署类型 | 触发条件 | 访问地址 |
|---|---|---|
| 生产部署 | 推送到 main 或 master | 项目名.pages.dev |
| 预览部署 | 推送到其他任意分支 | 随机哈希.项目名.pages.dev |
| 合并请求 | 在 GitHub 发起 PR | 同样生成预览地址，并在 PR 里评论 |
预览地址是独立的，每次部署都有不同的哈希前缀，可以发给同事或客户预览而不影响线上版本。合并请求的预览地址会自动评论到 PR 里，评审人点开就能看到效果。
预览部署和生产部署走的是同一套构建配置，所以预览通过就基本等于生产没问题。这个流程对团队协作特别有用，前端改完推到功能分支，后端或设计在预览地址上验收，确认无误再合并到主分支自动上线。
到这里你已经能用 Git 集成跑通一个静态站点的完整部署流程。下一篇讲构建配置的细节，包括构建命令、环境变量、Node 版本控制，以及不依赖 Git 的直接上传部署方式。
下一篇 构建配置与预览部署