把你写好的网站
部署到 Cloudflare Pages

预览部署（Preview）

任何非生产分支的 push，都会得到一个独立的预览网址，格式是 https://<commit>.项目名.pages.dev，或 https://<分支名>.项目名.pages.dev。PR 可以自动在评论里贴出预览链接。

用法：做完一个新功能，先推到 feature/xxx 分支看看效果，确认没问题再合并到 main。不用担心把生产环境搞坏。

自动注入的环境变量

CF_PAGES=1                # 在 Pages 环境里恒为 1
CI=true                    # CI 环境标志
CF_PAGES_BRANCH=main         # 当前分支名
CF_PAGES_COMMIT_SHA=a1b2c3d   # 提交哈希
CF_PAGES_URL=https://xxx.pages.dev   # 生产环境地址

判断环境的小技巧：代码里写 if (process.env.CI === "true") { /* 预览环境 */ } 就能在预览地址上展示调试信息，不影响生产。

方案 A：把域名接入 Cloudflare（推荐）

1. 在 Cloudflare 控制台点 Add a domain，输入你的域名（如 example.com）
2. 选择 Free 套餐
3. Cloudflare 扫描出你原来的 DNS 记录，确认无误后点击继续
4. Cloudflare 给你两个 nameserver，去原 registrar 把域名的 NS 改成这两个
5. 等待 DNS 生效（通常几分钟到 48 小时）
6. 生效后进 Pages 项目 → Custom domains → 添加域名，全部自动配置完成

额外好处：享受 Cloudflare 全套防护、缓存、分析，且不受下节提到的 Workers 域名限制。

方案 B：DNS 留在原服务商

1. 先在 Pages 项目里添加域名（先做这步，Cloudflare 需要先验证归属）
2. Cloudflare 会给你一条 CNAME 记录
3. 去 DNS 服务商把 www 或子域名指向 你的项目名.pages.dev

# 在你的 DNS 服务商添加
www    CNAME    你的项目名.pages.dev

限制：裸域名（example.com，不带任何前缀）在非 Cloudflare DNS 下需要 A 记录指向 IP，目前不支持。改用 www.example.com 或任意子域名都可以。

给你的实际建议

• 纯静态展示站 / 个人博客 / 作品集 → Pages 完全够用，别折腾。拖拽 3 分钟上线。
• 要跑边缘函数、SSR、写 API → 直接考虑 Workers，别从 Pages 起步。
• 已经在 Pages 上跑着的项目 → 不用急着迁，功能都能用。等有 Workers 独有能力（Durable Objects、Cron）再迁。
• 迁移命令很简单：npx wrangler pages deploy → npx wrangler deploy，主要工作量在改配置（pages_build_output_dir → assets.directory）。

顺便解释一下这些奇怪的名字

Cloudflare 的产品命名都很有梗，了解一下能省掉不少困惑：

• D1 —— Cloudflare 的第一个 SQL 数据库（官方原话 "our first SQL database"）。底层是 SQLite，所以你可以理解成「SQLite as a Service」：不用装数据库、不用管备份、不用选机房，在 Worker 里 env.DB.query() 就能查。注：Cloudflare 官方从未正式说明过这个名字的确切含义，"D = Database，1 = 第一个" 是社区最通行的解读。
• KV —— Key-Value，最直白的命名，键值对存储。
• R2 —— 官方给了四个并列解释：Really Requestable、Repositioning Records、Ridiculously Reliable、Radically Reprogrammable。还暗含 R2-D2 和"S3 减去最烦的出站费"两个梗。
• Pages —— 网页，最朴素的一个。

D1 的时间线：2022 年 5 月发布公告 → 11 月 alpha → 2024 年 4 月正式 GA。

方案一：自建（Workers + D1 + JWT）—— 最灵活，完全免费

自己写注册/登录接口，密码用 PBKDF2 或 Argon2 加盐哈希（注意：Workers 运行时没有 Node 的 bcrypt 原生模块，要用 Web Crypto API），签发 JWT 存进 HttpOnly Cookie。

my-app/
├── functions/                 # Pages Functions（边缘）
│   ├── api/
│   │   ├── login.ts           # POST /api/login
│   │   ├── register.ts        # POST /api/register
│   │   └── me.ts              # GET  /api/me（读 cookie 验签）
│   └── _middleware.ts         # 全局鉴权中间件
├── src/                       # 前端源码
├── wrangler.jsonc
└── schema.sql                 # D1 建表脚本

成本：0 元。D1 的 10 万行/天写入意味着每天可以支撑上万次注册+登录。

方案二：第三方 Auth（Clerk / Auth0 / Supabase Auth）

不自建，直接用现成的登录服务。前端几行代码就有登录 UI、社交登录、密码重置、邮箱验证。

• 免费额度：Clerk 和 Supabase 都有慷慨的免费档（通常几千到一万 MAU）
• 优点：省时间，安全做得比自己写靠谱
• 缺点：超出额度要付费；数据在第三方；国内访问速度需要实测

方案三：Cloudflare Access —— 给后台加"大门"

如果你的"登录"只是保护一个管理后台（不对外开放注册），根本不用写代码。

在 Zero Trust 控制台配一条 Access 策略，绑你的 Google / GitHub 邮箱账号，只有白名单内的人能进。零代码、零数据库、无限用户。

方案四：小程序 / 移动端 App 的登录

如果是微信小程序（你的场景应该有），用户身份本来就来自 wx.login 拿到的 code。

正确姿势是：用 code 换 openid 存到 D1，而不是自己写密码登录。整个流程后端只做一次 code2session 转发，Cloudflare 完全免费。

注意：微信小程序的 wx.request 需要在后台配置合法域名（把你的 .pages.dev 或自定义域名加进「服务器域名」白名单），且必须用 HTTPS。