“赛博大佛” Cloudflare（简称 CF）
“赛博大佛” Cloudflare（简称 CF）
cf提供的Workers和Pages是构建全栈应用的“双剑合璧”
一、 角色分工：谁负责“貌美如花”，谁负责“赚钱养家”？
在 CF 的生态里，Pages 和 Workers 的关系就像是**“前端静态资源”与“后端动态逻辑”**的关系。
1. Cloudflare Pages：前端托管的“王者”
- 适用场景：静态网站、个人博客、文档中心、单页应用（SPA）的前端部分。
- 核心优势：
- Git 驱动：你只需要
git push，CF 就会自动构建并分发到全球边缘节点。 - 无限流量：Pages 托管静态资源不限带宽，非常适合大流量的静态展示。
- 全栈功能：通过
/functions目录，Pages 也可以运行简单的后端代码（其实底层也是 Workers）。
- Git 驱动：你只需要
2. Cloudflare Workers：边缘计算的“引擎”
- 适用场景：API 后端、中转代理、数据转换、身份认证、轻量级计算任务。
- 核心优势：
- 极速响应：直接在离用户最近的边缘节点运行，没有传统容器的“冷启动”延迟。
- 算力灵活：可以控制请求头、重定向流量、甚至直接运行 AI 推理模型。
- 资源集成：能直接读写 KV 数据库、D1 数据库或 R2 存储。
二、 场景对比：我该选哪一个？
| 需求 | 推荐方案 | 理由 |
|---|---|---|
| 纯 HTML/Vue/React 项目 | Pages | 部署最简单，无限流量，自带 CI/CD。 |
| 纯 API 接口 / 代理服务 | Workers | 逻辑掌控力最强，适合处理请求转发和加解密。 |
| 全栈应用（前后端分离） | Pages + Workers | Pages 负责 UI 展现，Workers 负责 API 逻辑。 |
| 轻量级 Full-stack（如 Next.js） | Pages | Pages 深度适配全栈框架，前端和 API 可以在同一个仓库里自动部署。 |
三、 为什么很多开源项目提供“一键部署” (Deploy to CF)？
你在 GitHub 经常看到的那个橙色按钮（Deploy to Cloudflare），对开源作者和用户来说是**“双赢”**：
- 零基建门槛：用户不需要购买 VPS、配置 Nginx、安装 SSL 证书。点一下按钮，项目就直接上线了。
- 资源自动配齐：部署脚本会自动识别项目需要的数据库（D1）、缓存（KV）或存储（R2），并一键在用户的 CF 账号下创建好，无需手动配置。
- 自托管（Self-hosted）最简化：作者可以将复杂的部署逻辑封装在
wrangler.toml里，让普通用户也能像用 App Store 一样拥有自己的私有服务。 - 自动持续更新：部署过程会把代码 Clone 到用户自己的 GitHub，后续作者更新代码，用户同步仓库即可触发自动重新部署。
💡 深度避坑指南
- 别在 Workers 跑重型 Java：Workers 适合轻量级任务，免费版有 10ms CPU 时间限制。
- 优先用 Pages 托管静态页：虽然 Workers 也能读 KV 模拟静态托管，但 Pages 是原生优化的，且不占 Workers 的请求限额。