平台文档倾向于从最佳角度单独描述每个产品。这造成了一种阅读方式，即 Workers 似乎比 Pages 更强大，而 Pages 似乎比 Workers 更简单。两种读法都不正确。它们在每个方向上都具有真正独特的功能，并且有广泛的重叠区域，其中的差异仅在于部署模型。
只有工人才有的东西
Cron 触发器是 Pages 中不存在的最相关的原语。在1中：
0
这会记录两个 cron：一个每天凌晨 3 点，另一个每 15 分钟一次。对应的handler是Worker导出的对象的方法2。 Pages 没有这个原语。这不是运行时间限制——而是产品决定。如果您需要定期执行，那就是自由职业者。
队列消费者以类似的方式操作。 Cloudflare Queues 允许您对消息进行排队并异步处理它们。消费者（从队列中读取的工作线程）配置为 3 和 4。页面函数不能是队列消费者；只能通过绑定将消息发布到队列。
电子邮件工作人员直接接收电子邮件。您在 Cloudflare 中配置电子邮件路由以指向 Worker，Worker 将电子邮件作为包含发件人、收件人、标头和正文的对象接收。这使您可以处理退回邮件、解析发票收据或将电子邮件路由到不同的队列 - 所有这些都无需您自己的电子邮件服务器。 Pages 不支持此触发器。
Workers for Platforms 是一种多租户机制，SaaS 用户可以在运营商的帐户中部署自己的 Workers。操作员使用 Dispatch Worker 接收请求并将其转发到正确的租户脚本。它是需要在保证隔离的情况下执行任意用户代码的平台的基础设施原语。工人专属。
TCP 套接字（测试版）允许来自 Worker 的直接 TCP 连接 - 对于连接到没有 HTTP API 的数据库非常有用，例如没有 Upstash 的 PostgreSQL 或 Redis。仍在不断发展，但 Pages 中没有同等功能。
一般而言，耐用对象警报值得与耐用对象分开提及。 DO 在这两种情况下都可以工作，但警报（在定义的时间唤醒特定 DO 的计时器）是一种调度原语，它补充了每个实体都有状态的情况下的 cron 触发器（例如，为每个用户安排提醒）。在两个运行时中都可用，但编排通常从具有 cron 或队列触发器的 Worker 开始。
只有 Pages 才有的内容
以每个请求零成本托管静态资产是 Pages 最被低估的功能，也是 Pages 之外复制成本最高的功能。当您部署 Pages 项目时，静态文件（HTML、CSS、JavaScript、图像、字体）将通过 Cloudflare 的全球 CDN 分发。对这些资产的请求不会经过 Workers 运行时 - 它们直接从 CDN 边缘提供服务，不会触发任何计算逻辑，不会算作调用，每个请求的成本不会超出 Pages 计划。
Pages 的免费计划包括无限的 CDN 请求。付费计划的费用为 20 美元/月，每月增加 5,000 个构建以及最多 5 个并发构建。对于每月浏览量数千万的网站来说，与任何基于纯 Workers 的架构相比，每个静态请求成本的降低是一个显着的计费优势。
第二个区别是每个分支的预览自动部署。每次推送到非主分支都会生成一个格式为 5 的唯一 URL，其中资产和功能一起运行。无需额外配置，无需编写 CI 脚本。 Workers 不会在本地复制此内容 - 您需要在 CI 中手动设置“分支部署”流程。
集成的构建管道也是独一无二的。 Pages 会检测框架（Next.js、Astro、SvelteKit、Nuxt、Hugo、Gatsby）、配置构建默认值，并在每次推送时在隔离环境中运行构建过程。对于 Workers 来说，构建是 CI 的责任——这更灵活，但意味着需要维护更多的配置。
约定 6 和 7 允许您通过项目根目录中的纯文本文件为静态资产配置重定向和 HTTP 标头，无需代码。对于 URL、HSTS、内容安全策略和缓存标头迁移很有用。工作人员可以用代码实现相同的功能，但它更冗长。
两者有什么共同点
V8 运行时是相同的。限制是相同的：128MB 内存（硬）、付费计划上的 10MB 压缩脚本、每个请求 30 秒的 CPU、每次调用 1,000 个子请求。在 Workers 中运行的任何代码都在 Pages Functions 中运行，无需更改。
数据绑定是共享的：D1（边缘的 SQLite）、KV（分布式键值）、R2（对象存储）、持久对象（协调一致状态）、AI（边缘的模型推理）。您可以让 D1 数据库由两个页面函数访问，并在同一个 8 上配置一个自治工作器，并绑定指向相同的数据库 ID。
服务绑定有两种工作方式：页面函数可以通过内部绑定直接调用独立的 Worker，而不会产生公共网络延迟。一个Worker可以调用另一个Worker。该呼叫是针对绑定的正常 9 号呼叫，但在 Cloudflare 网络内部路由。
在正确的位置使用每一个的架构
正确使用 Workers 和 Pages 的项目中出现的模式具有三层。第一个是 Pages 项目：它为 SPA 或构建生成的网站提供服务，并在 CDN 上提供静态资产，每个请求无需付费。 API 路径位于 10 — 页面功能与前端位于同一位置，包含分支预览，访问 D1 和 KV 以获取应用程序数据。
第二层是用于异步作业的 Workers：带有 cron 触发器的独立脚本用于计划处理，用于与 HTTP 关键路径解耦的异步工作的队列消费者，用于电子邮件处理的电子邮件 Workers。这些 Workers 访问与 Pages 项目相同的数据绑定 - 相同的 D1 数据库、相同的 KV 命名空间。
第三层是它们之间通过服务绑定进行通信。需要大量处理的 Pages Function 直接调用专门的 Worker，无需外部 HTTP。需要触发通知的 Cron Worker 可以通过 Service Binding 调用发送 Pages 函数。
这种架构不是理论上的。这就是当您使用每个原语以较低的运营成本解决问题时会发生的情况：Pages 为资产提供免费 CDN，为同地 API 提供相同的运行时，为 Pages 不支持的触发器提供独立的 Workers。
决策图
组织决策的问题是：什么触发了这个代码？如果它是一个 HTTP 请求并且代码与前端、Pages Functions 一起存在。如果是 HTTP 请求，但项目没有前端 — 纯 API 服务 — Workers 的配置在11中。如果是 HTTP 以外的任何内容（计划时间、队列消息、传入电子邮件），工作人员别无选择。
表的双方都具有对方无法在不增加成本或复杂性的情况下复制的功能。忽略这一点的决定——只使用 Workers 因为你认为它更“严肃”，或者只使用 Pages 因为你认为它更简单——将会达到需要尽早重构的限制。
另请阅读
- [Cloudflare Workers 与 Pages：选择之前最重要的区别13
- [从 Pages 迁移到 Workers：何时有意义以及变革的实际成本14
- [Workers 和 Pages：部署、路由以及每个模型隐藏的内容15
- [页面功能：何时使用而不是纯粹的 Workers16
- [速率限制、功能标志和分布式配置的 KV：它在哪里起作用以及在哪里失效17
- [Cloudflare KV：当你需要写时，全球分布式意味着什么18