Last updated: 2026-06-30

Last verified: 2026-06-30 for Cloudflare Pages, Pages Functions, and Workers official documentation. Cloudflare product limits, pricing, bindings, runtime behavior, and dashboard flows must be re-checked before publication updates or implementation.

OnlyPat 建站指南 is an independent guide-site project. This draft is not Cloudflare official documentation and does not imply affiliation with Cloudflare.

先说结论

Cloudflare Pages 不需要一开始就配 Workers。页面能静态生成、交互能在浏览器本地完成、没有私密数据和服务端状态时，Pages 就够了。只有当你需要服务端逻辑、API、密钥保护、表单处理、账号权限、数据库或后台任务时，再考虑 Pages Functions 或 Workers。

适合 / 不适合

判断项 先用 Cloudflare Pages 就够 需要考虑 Functions / Workers
页面内容 文章、指南、索引页、公开静态资源 按请求生成、个性化或依赖服务端数据
用户交互 搜索、转换、预览、计算都在浏览器完成 表单提交、登录、权限、私密数据处理
API 和密钥 不需要隐藏服务端 API key 需要代理 API、保护密钥或限制调用
数据状态 没有账号、订单、评论、收藏等持久状态 需要数据库、KV、队列、对象存储或会话
OnlyPat 当前状态 guide/tool/yimoo 第一版都静态优先 只有出现真实服务端需求时再扩展

30 分钟开工版

  1. 写下这个功能是不是必须由服务器处理。
  2. 判断页面能不能提前生成，还是每次请求都要动态计算。
  3. 检查是否有不能暴露到浏览器的 API key、token、账号或私密数据。
  4. 判断是否需要保存用户提交、订单、评论、偏好、文件或历史记录。
  5. 如果只是小工具，先尝试浏览器本地实现。
  6. 如果只需要某个 Pages 路由处理动态逻辑，优先研究 Pages Functions。
  7. 如果多个站点共享 API、需要独立服务、绑定存储或后台任务，再研究 Workers。
  8. 把暂不实现的后端能力写进路线图，不要为了“看起来高级”先上后端。

做到这里就可以停。不要先创建 Worker、数据库、队列、登录和 API token。先证明这个功能真的不能静态或浏览器本地完成。

详细判断

判断是否需要 Workers，本质是在判断“有没有服务端职责”。下面按静态内容、浏览器本地工具、Pages Functions、独立 Workers 和状态存储来拆。

1. 静态内容站通常不需要 Workers

如果网站主要是文章、指南、图片、索引和静态资源，Cloudflare Pages 本身就能承担第一版发布。

OnlyPat 的 guide.onlypat.com 就是这个路线：文章由 Astro 构建成静态页面，sitemap、robots、canonical 和 JSON-LD 都随构建输出。

这类站点优先考虑：

  • 内容结构；
  • 内链；
  • sitemap；
  • robots；
  • canonical；
  • AdSense 和 ads.txt；
  • 构建和部署验证。

后端不是第一优先级。

2. 浏览器本地工具也未必需要 Workers

很多工具看起来像“应用”，但仍然可以静态优先。

例如：

  • JSON 格式化；
  • URL 编码；
  • Base64 编解码；
  • 时间戳转换；
  • QR Code 生成；
  • 搜索摘要预览；
  • UTM 链接生成。

这些工具的输入、输出和计算都可以在浏览器里完成，不需要账号、数据库或服务端密钥。此时上 Worker 只会增加维护面。

3. Pages Functions 适合 Pages 站点里的动态路由

Cloudflare Pages Functions 是给 Pages 项目增加动态功能的一种方式。它适合“这个 Pages 站点里的某些路径需要服务端代码”的情况。[Official source checked 2026-06-30]

可能适合 Pages Functions 的例子：

  • 一个联系表单提交 endpoint；
  • 一个需要服务端校验的下载入口；
  • 一个轻量 API route；
  • 一个站内数据代理；
  • 一个只服务当前 Pages 项目的动态功能。

但这不代表第一版必须用 Functions。只有当需求明确落到服务端职责时，才进入实现设计。

4. 独立 Workers 适合更清晰的服务边界

Cloudflare Workers 是更通用的 serverless 运行平台。[Official source checked 2026-06-30]

更适合独立 Worker 的情况：

  • 多个站点共用同一个 API；
  • 需要独立部署、版本和路由；
  • 需要连接 Cloudflare 存储或队列类能力；
  • 需要后台任务、webhook 或跨站逻辑；
  • 需要把服务端能力和静态站点分开治理。

如果只是一个 guide 页面或 browser-only 工具，不要为了技术名词先拆 Worker。

5. 真正的分界线是状态和密钥

可以用两句话判断：

这个功能是否需要保存、读取或保护每个用户的数据？

这个功能是否需要在服务器端保存密钥或控制访问？

如果两个答案都是 no，通常先别上后端。

如果任一答案是 yes，就进入后端设计，但也要继续判断用 Pages Functions、Workers、外部服务，还是暂时不做。

常见误区

不要把 Cloudflare Pages 理解成只能放纯 HTML。

不要以为用了 JavaScript 就必须上 Workers。

不要为了 GEO、SEO 或 AdSense readiness 先加后端。

不要把 API key 写进前端代码。

不要在没有真实需求时先做账号、数据库、支付、评论或后台管理。

不要把 Pages Functions 和独立 Workers 混成一个概念。

不要把“以后可能需要”当成“今天必须实现”。

OnlyPat 实操备注

OnlyPat 当前三个站点都按静态优先推进：

  • guide.onlypat.com：文章、路线图、GEO answer pages；
  • tool.onlypat.com：浏览器本地工具；
  • yimoo.onlypat.com：静态攻略工作台。

这不是说永远不用 Workers，而是把 Workers 留给真实服务端职责。比如未来如果出现账号、私密表单、服务线索管理、跨站 API、数据库、队列或需要保护密钥的外部 API，才值得单独设计。

在那之前，更高价值的是让静态页面、工具说明、sitemap、robots、AdSense、ads.txt、结构化数据和验证链稳定。

官方来源

  • Cloudflare Pages documentation: https://developers.cloudflare.com/pages/
  • Cloudflare Pages Functions: https://developers.cloudflare.com/pages/functions/
  • Cloudflare Workers documentation: https://developers.cloudflare.com/workers/

下一步

下一步先读 静态工具站要不要后端，把具体工具需求逐项拆开。如果你只是要做 UTM、JSON、时间戳、URL 编码或 QR Code 这类工具，可以先从 https://tool.onlypat.com/ 的 browser-only 路线开始，不急着设计 Worker。

如果某个功能确实需要服务端，再写一页实现前检查清单：输入是什么、输出是什么、是否有私密数据、是否有密钥、是否需要存储、是否必须跨站复用、上线后怎么验证。