多年来，对于"我该把这个部署到 Cloudflare 的哪里"这个问题，答案很简单：静态站点和前端放到 Pages，无服务器逻辑放到 Workers。到了 2026 年，这条界线已经模糊，因为 Workers 现在可以直接提供静态资源，这意味着单个 Worker 就能托管你的整个站点，前端和后端合二为一。这改变了 Cloudflare 自己对新项目的建议，在你选边站之前，值得先弄清楚原因。
本指南解释每个产品是什么，向静态资源的转变如何改变了 Cloudflare Pages vs Workers 的抉择，并为新项目以及任何在考虑是否迁移的人给出明确的建议。
摘要
- Pages 是面向静态站点和前端框架的 git 连接托管，内置 CI/CD 和预览部署
- Workers 是 Cloudflare 的无服务器计算平台，现在也提供静态资源，因此可以托管完整站点
- 对于 2026 年的新项目，Cloudflare 推荐使用搭配静态资源的 Workers，因为它把前端和后端统一到一次部署中
- Pages 仍然得到完整支持；没有必要急着把现有的 Pages 项目迁走
- 根据工作流来选择：纯 git-push 的静态部署用 Pages，凡是把静态内容与动态逻辑混在一起的就用 Workers
什么是 Cloudflare Pages
Cloudflare Pages 是一个直接从 git 仓库部署网站的平台。你连接一个 GitHub 或 GitLab 仓库，Cloudflare 运行你的构建命令，输出便部署到全球边缘。每次 push 都会获得一个带有独立 URL 的预览部署，而合并到生产分支会更新线上站点。这就是经典的 Jamstack 工作流：push 代码，得到一个已部署的站点。
Pages 还通过 Pages Functions 支持动态行为，它们在底层就是 Workers，因此你可以为一个原本静态的站点添加 API 路由和服务端逻辑。我正是用这种方式构建了一个完整的 Cloudflare Pages 上的用户注册与登录系统 ，它展示了一个"静态"主机能延伸到多远。
什么是 Cloudflare Workers
Cloudflare Workers 是无服务器计算与无服务器托管平台：代码运行在 Cloudflare 的网络上，靠近你的用户，无需管理服务器。Workers 起初是用于 API、中间件和边缘逻辑的纯函数，并与平台的其余部分绑定，R2 、D1 、KV、Queues 和 Workers AI 。如果你基于这些存储绑定来构建，我的免费桌面应用让它们易于管理：Easy Cloudflare R2 、Easy Cloudflare D1 和 Easy Cloudflare KV 。
2026 年的关键进展是 Static Assets。一个 Worker 现在可以直接提供一个静态文件目录（HTML、CSS、JS、图片），同时由 Worker 处理任何动态路由。这意味着单个 Worker 就能在一次部署中托管你构建好的前端和你的 API，而这在以前需要把工作拆分到 Pages 和 Workers 上。
Pages vs Workers 有什么变化：Static Assets
这个对比如今之所以重要，正是因为静态资源能力。过去，如果你有一个 React 或 Astro 前端外加一个后端 API，自然的拆分方式是前端用 Pages、API 用一个单独的 Worker。两个项目，两次部署，两样东西要彼此对接。
借助 Workers 上的静态资源，你只需部署一次。Worker 为普通请求提供你的静态构建，并为 API 路由或服务端渲染页面运行你的代码。对于把静态和动态内容混在一起的全栈框架与应用，这更易于构建、部署和理清思路。这就是 Cloudflare 现在把新的全栈项目引向 Workers 而非 Pages 的原因。
Pages vs Workers：并排对比
| 标准 | Cloudflare Pages | Cloudflare Workers |
|---|---|---|
| 主要用途 | git 连接的站点托管 | 无服务器计算 + 静态资源 |
| 静态托管 | 是（核心功能） | 是（通过静态资源） |
| 动态/服务端逻辑 | Pages Functions | 原生 |
| Git CI/CD + 预览 | 内置 | 通过 CI 集成 / Wrangler |
| 绑定（R2、D1、KV、AI） | 是 | 是，一等公民 |
| 最适合 | 纯静态/Jamstack 站点 | 全栈应用与 API |
| 2026 年对新项目的建议 | 仍受支持 | 首选 |
何时选择 Pages
在 Pages vs Workers 的抉择中，Pages 在以下情况下仍是绝佳选择：
- 你有一个纯静态站点或前端框架构建，并希望尽可能简单的 git-push 部署工作流
- 你看重无需任何配置的内置 CI/CD 和预览部署
- 你的动态需求很轻，Pages Functions 就能很好地满足
- 你已经在 Pages 上且运行良好；留下来没有任何代价
何时选择 Workers
在 Pages vs Workers 的抉择中，Workers 在以下情况下是更好的选择：
- 你正在构建一个把静态内容与大量服务端逻辑混合的全栈应用
- 你希望前端和后端在一次部署中，而不是两个需要协调的项目
- 你大量依赖 D1、R2、KV、Queues 或 Workers AI 等绑定
- 你在 2026 年启动一个新项目，并希望遵循 Cloudflare 当前推荐的路径
- 你需要对路由、缓存和请求处理进行细粒度控制
Cloudflare Pages vs Workers：你该迁移吗？
不，不要条件反射式地迁移。如果你有一个能用的 Pages 项目，它仍受完整支持，也没有任何期限逼你迁移。当你有具体理由时再迁移：你正在添加大量后端逻辑，你想把拆分的前端/后端合并为一次部署，或者你遇到了 Workers 能解决的 Pages 特有限制。
对于全新项目，在 Pages vs Workers 的选择中，从搭配静态资源的 Workers 起步。对于现有且令人满意的 Pages 部署，在出现真正需求之前就让它保持原样。迁移最糟糕的理由是图新鲜；最好的理由是统一一个否则你不得不拆分的全栈应用。
要点总结
- Pages 是面向静态和 Jamstack 站点的 git 连接托管，内置 CI/CD 和预览
- Workers 是无服务器计算，现在也提供静态资源，因此可以托管完整站点
- Static Assets 正是让单个 Worker 能把前端和后端一起托管的那个变化
- 对于 2026 年的新全栈项目，Workers 是 Cloudflare 推荐的路径
- Pages 仍受完整支持；只有在你有具体理由时才迁移
- 在 Cloudflare Pages vs Workers 的抉择中，纯静态的简洁选 Pages，凡是把静态内容与真实逻辑混合的就选 Workers
常见问题
Cloudflare Pages 和 Workers 有什么区别？ Pages 是面向静态站点和前端的 git 连接托管，内置 CI/CD 和预览部署。Workers 是 Cloudflare 的无服务器计算平台。界线在 2026 年变得模糊，因为 Workers 现在可以提供静态资源，使一个 Worker 能同时托管前端和后端。
2026 年的新项目我该用 Pages 还是 Workers？ 对于大多数新的全栈项目，搭配静态资源的 Workers 现在是 Cloudflare 推荐的选择，因为它把前端和后端统一到一次部署中。对于一个你想要最简单 git-push 工作流的纯静态站点，Pages 仍是绝佳选项。
Cloudflare Pages 会被停用吗？ 不会。Pages 仍受完整支持。Cloudflare 现在把新的全栈项目引向 Workers，但现有的 Pages 项目继续运行，并且没有强制迁移。
Workers 能托管一个静态网站吗？ 能。借助静态资源功能，一个 Worker 可以直接提供 HTML、CSS、JS 和图片等静态文件，同时在代码中处理动态路由。正是这一点让单个 Worker 能托管一个完整站点。
Pages 和 Workers 使用相同的绑定吗？ 两者都可以使用 R2、D1、KV 和 Workers AI 等 Cloudflare 绑定。Pages 通过 Pages Functions 暴露它们，而 Workers 将它们视为一等公民。在功能上，你可以从任一方触达相同的平台服务。
我该把现有的 Pages 站点迁移到 Workers 吗？ 仅当你有具体理由时，比如添加大量后端逻辑，或把拆分的前端和后端合并为一次部署。一个能用的 Pages 项目受完整支持，无需迁移。
评论