Cloudflare Workers 和 Pages 怎么选：给工具站、内容站与全球上线场景的实用判断

如果你准备把项目放到 Cloudflare 上，最早遇到的架构问题之一，往往不是“用哪个框架”，而是“这个项目到底应该放在 Workers 还是 Pages 上”。

这个问题看起来不大，但它会直接影响你的发布方式、逻辑运行位置，以及你在早期要背多少复杂度。

对开发者、独立产品团队和跨境卖家来说，更好的选择通常不是“功能最多”的那个，而是最符合当前工作形态的那个。

1. 如果站点主要是内容和展示层，优先考虑 Pages

当一个站点的主要任务是发布和承载前端内容时，Cloudflare Pages 往往更合适：

• 产品页
• 博客内容
• 落地页
• 文档站
• 轻量营销站

如果你的大多数工作集中在 React、静态输出、MDX、页面设计和内容更新上，Pages 会让发布模型保持更简单。

这种简单本身就是价值。对小团队来说，通常“一个清晰稳定的内容发布路径”比“第一天就把每个路由都做成可编程边缘服务”更重要。

这和 MVP 上线前的轻量级基础设施检查清单 是一个思路：在产品还没证明自己需要更多复杂度之前，先把可变部分压到最少。

2. 如果请求时逻辑本身就是产品核心，优先考虑 Workers

Cloudflare Workers 更适合下面这类场景：真正的产品价值，发生在“请求到达之后”的那一段逻辑里：

• 数据转换
• API 请求处理
• 输入校验
• 根据请求头、地区或元数据做判断
• 在边缘层做路由、重写或保护

如果你的产品更像 API、网关、自动化层，或者轻量服务运行时，那么 Workers 往往是更自然的归宿。

这一点对工具类产品尤其明显：如果用户提交内容后，期待的是实时计算、转换结果或边缘响应，而不是单纯打开一个页面，那么 Workers 的价值会更直接。

3. 很多时候，Pages 是前门，Workers 是逻辑层

一个很好用的理解方式是：

• Pages 负责站点
• Workers 负责动态边缘逻辑

这意味着真正实用的答案，很多时候并不是“二选一”。不少产品最后都会同时使用它们：

• 用 Pages 承载营销、产品说明和内容外壳
• 用 Workers 处理 API、转换、校验和边缘策略

对 GhostNode 这样的工具体系来说，这种分层就很自然：内容站保持清晰可发布，请求时工具逻辑则放在更适合编程的边缘运行时里。

4. 先看“哪一层变化更频繁”

还有一个很实用的判断方式：先问自己，项目里变化最频繁的到底是什么。

• 如果改得最多的是文案、设计、博客和产品页，那么 Pages 通常更适合作为主轴
• 如果改得最多的是请求处理、转换逻辑或边缘行为，那么 Workers 应该占更高权重

这个判断能帮你避开一个早期常见错误：不是按维护模式选架构，而是按“听起来更厉害”来选。

如果你每周做的大多数工作其实都是内容和前端表达，那主站就没必要一开始就长得像一个 API 平台。

5. Pages 更适合内容发布流，Workers 更适合工具逻辑流

Pages 和内容型发布工作流天然更贴近：

• 写内容
• 构建前端
• 发布静态或前端输出
• 验证公网页面

Workers 则更贴近工具和边缘逻辑工作流：

• 接收输入
• 在请求时执行逻辑
• 返回转换结果或决策
• 在更靠近用户的位置执行规则

这也是为什么很多浏览器工具型产品，最后会把“工具逻辑”逐渐倾向于 Workers，而把外围站点继续留给 Pages 或类似的内容承载层。

6. 面向全球上线时，两者都可能有用，但不必一开始全上

对于要面向全球用户的产品来说，这两个平台都可能有用：

• Pages 负责快速上线内容站和产品说明
• Workers 负责边缘校验、API 和区域感知逻辑

但“两个都能用”不等于“第一天就要一起上”。

早期更合理的做法，是先选最贴近真实工作流的最小组合。如果你还在验证定位，像 不买域名也能先上线网站的几种方式 这种 Pages 优先路径往往就够了。反过来，如果核心价值本来就是一个边缘工具或在线检查 API，那么 Workers 反而应该优先。

7. 放到工具站、博客和上线操作里，怎么拆更顺手

一个比较实用的拆法通常是：

• 博客、文档、产品说明：Pages
• 请求时工具和 API：Workers
• 最后一公里发布检查：像 GhostTools 这样的工具入口

这样做的好处是，公开站点保持清晰，真正依赖请求时行为的逻辑则放在更接近边缘网络的位置。

同时，出了问题也更容易分层判断：如果是内容页不对，就查发布链路；如果是转换结果或边缘响应不对，就查 Worker 逻辑。

结论

Cloudflare Pages 更适合内容优先的站点，Cloudflare Workers 更适合请求时逻辑优先的产品。

如果你的项目两个都需要，那就按“职责分工”来拆，而不是强行让一个平台去假装另一个平台。这样上线路径会更简单，维护边界会更清楚，也能少做很多过早的架构决定。