关于 Pages Functions 有一个常见的误解：它们是 Workers 的简化或有限版本，适合琐碎的情况，不足以用于严肃的生产。那不是真的。页面函数与 Workers 运行在相同的 V8 运行时上，访问相同的绑定，遵守相同的限制。两种部署形式之间的区别不在于容量，而在于操作环境。
从技术上讲，页面功能是什么
Pages Functions 是通过 Pages 项目中的文件系统约定部署的 Worker。您在存储库的根目录中创建一个目录 3，其中的每个 [TypeScript20 或 JavaScript 文件都会成为一条路径。文件4 在5 中响应。文件6在7中响应。
执行此代码的运行时与独立 Worker 的运行时相同：V8 隔离、低于 1 毫秒的冷启动、每次调用 128MB 内存（硬限制）、付费计划中每个请求 30 秒的 CPU、每次调用 1,000 个子请求。可用的绑定是相同的：D1 用于边缘的 SQLite 数据库，KV 用于键值存储，R2 用于对象，持久对象用于一致状态，AI 用于推理，服务绑定用于直接调用其他 Worker。
区别在于部署：页面函数是作为也具有静态资产的页面项目的一部分创建的。如果没有 Pages 项目，则无法部署 Pages Function。这不是技术限制——它是一种产品选择，定义了何时使用其中一种有意义。
当页面函数获胜时
Pages Functions 最有力的案例是共置：前端和后端位于同一存储库中，具有相同的部署周期。具有 API 路由的 Next.js、Astro 或 SvelteKit 项目自然是位于同一位置的 - 您可以在同一提交、同一拉取请求、同一预览部署中更改组件及其使用的 API 路由。
每个分支的预览是最具体的操作差异化因素。每次推送到任何分支都会生成一个格式为 8 的预览 URL，其中静态资产和函数都在运行。这意味着 PR 审核者可以测试完整的功能（界面和 API），而无需将其部署到任何单独的环境。 Pure Workers 本身不具备这种流程。
如果您的 API 路由自然地映射到 URL 路径，并且您不需要目录结构之外的复杂路由逻辑，则 Pages Functions 无需在 9 中配置具有自己的路由的单独 Worker。
目录结构和中间件模式
具有功能的真实页面项目结构：
0
10文件是很多人忽视的一种组合机制。它在执行特定于路径的函数之前接收请求，并可以用自己的响应将其短路或通过11将其传递到下一个处理程序。这是为了[身份验证22]、集中式日志记录和 CORS，而无需在每个函数中重复逻辑：
1
根目录12中的中间件涵盖了所有功能。 13中的中间件仅涵盖API路线。您可以将两者堆叠起来——父目录中的那个首先运行。
当纯粹的 Workers 是正确的选择时
页面函数不支持 cron 触发器。如果您需要一个在凌晨 3 点运行的作业来处理计费、同步外部源或清理过期的会话，则该作业需要是一个独立的 Worker，并且在 15 上的 14 上运行。 Pages 模型中没有其他选择。
队列消费者（异步处理 Cloudflare 队列消息的工作人员）也不存在于 Pages 中。如果您的架构使用队列将繁重的处理与请求的关键路径分离，则使用者需要是一个单独的 Worker。
Workers for Platforms 是用户部署脚本的调度机制（在多租户 SaaS 的情况下，每个客户都有自己的代码），是 Workers 独有的。电子邮件工作者，负责接收和处理传入的电子邮件，同上。
经验法则：如果触发器不是 HTTP 请求，则它是纯 Worker。页面功能仅是 HTTP。
在单独的页面函数和 Workers 之间共享代码
常见的架构同时使用：用于前端的 Pages 项目和 16 中的主要 API，以及用于后台作业的单独 Workers。问题是业务代码可能需要共享——数据验证、D1 数据库访问、授权逻辑。
解决方案是内部 npm 包（使用 npm/pnpm 工作区）或专用 Worker 作为“服务层”，由其他人通过服务绑定访问。服务绑定允许页面函数在同一内部 Cloudflare 网络上直接调用 Worker，无需网络成本且无需通过公共互联网：
2
这里的 17 是一个独立的 Worker，它可以访问队列、cron 以及 Pages Functions 不支持的任何其他原语。页面函数位于HTTP层；自主工作人员坐在异步触发器中。两者共享指向相同资源的 D1 和 KV 绑定。
决策标准
如果您正在构建一个带有前端的项目（任何在构建时生成静态资产的项目），请从 Pages 开始。您在 18 中添加的函数与 HTTP 情况下的独立 Worker 具有完全相同的功能。您无需支付任何额外的运营成本即可获得分支预览和集成构建管道。
如果您正在构建一个没有前端、具有非 HTTP 触发器的服务，或者需要具有不同绑定的命名环境来进行暂存和生产，那么 Workers 是最直接的路径。 19中的显式配置更具可审计性，并且对于纯后端服务来说部署模型更加灵活。
两者并不相互排斥。大多数严肃的项目最终都会有这两种情况：用于 HTTP 并与前端位于同一位置的页面，用于异步或计划的工作人员。
另请阅读
- [Cloudflare Workers 与 Pages：选择之前最重要的区别23
- [从 Pages 迁移到 Workers：何时有意义以及变革的实际成本24
- [只有工人才能做的事情，只有页面才能做的事情以及两者相遇的地方25
- [Workers 和 Pages：部署、路由以及每个模型隐藏的内容26
- [Cloudflare KV：当你需要写时，全球分布式意味着什么27
- [电子邮件路由+工作人员：在边缘以编程方式处理电子邮件28