3.1 你部署的东西不同#

• Workers：部署的是代码（服务端程序）
  • 你发布的是一个 worker 脚本。
  • 它接收请求（HTTP）、处理逻辑、返回响应。
• Pages：部署的是网站产物（静态资源）
  • 你发布的是构建后的文件，例如 index.html、assets/xxx.js、style.css。
  • Pages 会把这些文件分发到边缘节点，像 CDN 一样给用户就近返回。

3.2 “动态能力”的来源不同#

• Workers 的动态能力：天生就是写代码处理请求。
• Pages 的动态能力：主要来自 Pages Functions。
  • 你可以在 Pages 项目里写一些函数，处理 /api/* 或者某些路由。
  • 但它的定位仍然是“网站为主，函数为辅”。

3.3 典型使用场景不同#

• Workers 更适合
  • API 网关：统一鉴权、限流、日志、灰度。
  • BFF（给前端服务的后端）：把多个后端接口聚合成一个接口。
  • 轻量后端：表单提交、邮件通知、Webhook 处理。
  • 边缘计算：图像处理、文本处理、内容改写。
  • 反向代理与请求改写：把请求转发到第三方服务，并做签名、注入 header。
• Pages 更适合
  • 企业官网、产品落地页。
  • 文档站（Docusaurus、VitePress、Next.js 导出静态等）。
  • 博客（Hugo、Hexo、Astro）。
  • 单页应用（React/Vue/Svelte）部署。
  • 需要预览环境的前端项目（每个 PR 自动生成预览链接）。

3.4 开发体验不同#

• Pages 的体验更像“托管平台”
  • 连接 Git 仓库。
  • 自动构建与部署。
  • 有 Preview 环境（PR 预览）。
  • 适合前端团队的工作流。
• Workers 的体验更像“云函数/Serverless”
  • 用 wrangler 初始化、开发、发布。
  • 更关注路由、请求处理、绑定环境变量、访问 KV/D1/R2。
  • 适合后端/全栈的工作流。

5.1 用 Pages 免费上线一个站点#

你可以在免费套餐里：

• 绑定 GitHub 仓库，push 自动部署。
• 生成 Preview 预览链接（对协作非常实用）。
• 绑定自定义域名，自动 HTTPS。
• 托管静态站点资源。

适合的例子：

• 个人博客。
• 产品介绍页。
• 开源项目文档站。
• 前端 Demo。

5.2 用 Workers 免费写一个轻量 API#

你可以在免费套餐里做：

• 一个 GET /api/hello 的接口。
• 表单提交接口：POST /api/feedback。
• Webhook 接收器（例如接收支付成功回调）。
• 反向代理：把请求转发到另一个服务并做鉴权。

再配合 KV、D1、R2 等产品的免费额度（各产品策略不同，通常都有免费层），就能搭出一个可用的“小后端”。

说明：免费套餐的具体额度会随 Cloudflare 调整而变化。选择前建议以 Cloudflare 官方页面的最新说明为准。

7.1 Workers 的优点#

1. “想怎么处理请求就怎么处理”
   • 你可以读 header、改 URL、查数据库、做签名校验。
   • 适合复杂业务逻辑。
2. 边缘执行，速度和稳定性好
   • 用户在各地访问都能就近处理。
   • 适合对延迟敏感的 API。
3. 很适合做“中间层”
   • 把多个服务整合成一个对前端友好的接口。
   • 例如把用户信息、订单信息、推荐信息聚合成一次请求。
4. 和 Cloudflare 的生态配合顺手
   • KV：配置、会话、缓存。
   • D1：结构化数据。
   • R2：对象存储。
   • Durable Objects：需要强一致或单点状态的场景。

7.2 Workers 的缺点#

1. “后端能力强”意味着你要承担更多后端设计工作
   • 鉴权怎么做？
   • 错误码怎么定义？
   • 数据怎么存？
   • 日志怎么打？
2. 并不是传统意义上的“完整服务器”
   • 运行时、限制、请求处理模型与传统 Node/VM 不完全一样。
   • 一些依赖本地文件系统或长连接的场景，需要换思路。
3. 项目规模变大后，需要更系统的工程化
   • 多环境、灰度、监控、告警、回滚。
   • 虽然都能做，但需要你搭建规范。

8.1 Pages 的优点#

1. 部署网站非常省心
   • 连上仓库。
   • 配好构建命令。
   • push 就上线。
2. 静态站点性能非常好
   • 静态资源天然适合 CDN 分发。
   • 对 SEO、首屏速度通常更友好。
3. 预览环境（Preview）对协作很强
   • 每个 PR 都能生成一个可访问的预览链接。
   • 设计、产品、测试可以直接点开看效果。
4. 对常见前端框架友好
   • React/Vue/Svelte/Next/Astro 等都能找到成熟的部署方式。

8.2 Pages 的缺点#

1. 它的核心还是“网站托管”
   • 一旦你的需求变成“我要一个复杂后端”，Pages 就不是主战场。
   • Pages Functions 能做，但更适合轻量 API。
2. 动态能力与状态管理的复杂度会快速上升
   • 例如要做登录、会话、权限、订单等。
   • 如果全塞在 Pages Functions，会让项目结构变得不清晰。
3. 对某些完全动态的站点不如纯 Workers 自然
   • 如果每个页面都要实时拼装、强依赖数据接口，Workers 往往更顺手。

9.1 你的产物主要是“网页文件”还是“接口逻辑”？#

• 主要是网页：选 Pages。
• 主要是 API：选 Workers。

9.2 你是否需要 Git 驱动的预览与发布流程？#

• 需要非常标准的前端 CI/CD：优先 Pages。
• 你更关注服务端逻辑与路由：优先 Workers。

9.3 你是否需要复杂的鉴权、限流、数据处理？#

• 需要：更偏 Workers。
• 只要简单表单、简单接口：Pages Functions 或 Workers 都可以。

9.4 推荐组合（最常见、也最稳妥）#

• Pages 托管前端 + Workers 提供 API
  • 域名示例：
    • www.example.com → Pages
    • api.example.com → Workers
  • 好处是职责清晰：
    • Pages 专注“展示”。
    • Workers 专注“逻辑”。

例子 A：个人博客 + 评论提交#

• 博客页面：用 Pages
  • Hugo/Hexo/VitePress 构建后直接发布。
• 评论提交 API：用 Workers（或 Pages Functions）
  • POST /api/comment
  • 校验参数。
  • 写入 D1。
  • 返回评论 ID。

你会发现：博客内容是静态的，适合 Pages；评论是动态写入的，适合 Workers。

例子 B：把第三方 API“包一层”做鉴权与缓存#

假设你要调用一个第三方天气 API：

• 你不想把第三方密钥直接放在前端。
• 你还想做缓存，减少调用次数。

这时用 Workers 最合适：

1. 前端请求你的接口：GET /api/weather?city=shanghai
2. Workers 检查缓存（KV）。
3. 没有缓存就去请求第三方服务。
4. 把结果写入 KV，设置过期时间。
5. 返回给前端。

Pages 也能“放前端页面”，但这个“中间层”逻辑明显是 Workers 的优势场景。