Cloudflare-first：小产品为什么不该默认买 VPS

最近看到一个观点：做个人小工具或者出海小产品，不要先买服务器、配 Nginx、养数据库，静态页面、接口、数据库、对象存储和邮件都交给 Cloudflare 这类托管平台。

方向我认同，但如果把它压缩成「Cloudflare 可以免费替代 VPS」，重点就偏了。

VPS（Virtual Private Server，虚拟专用服务器）只是其中一种运行环境。真正发生变化的是：对很多小型 Web 产品，服务器已经不必是默认起点。先用托管能力把产品跑起来，出现明确的运行时需求以后，再引入服务器，往往更省时间，也更容易扩展。

这个博客本身现在也是类似思路：Astro 产出的静态资源由 Cloudflare Workers Static Assets 承载，只有真正需要动态处理的请求才进入 Worker。服务器没有消失，只是从「默认基础设施」退到了「特殊运行时」。

先把几个容易被说大的地方校正

第一，Cloudflare 现在对新项目的推荐已经发生变化。Pages 仍然可用，但官方在 Pages 文档里明确写着：Workers 覆盖了大多数 Pages 场景、能力更广，新项目优先从 Workers 开始。静态文件也不必因此变贵，Workers Static Assets 的静态资源请求仍然免费且不限量。

第二，Workers Free 不是「每天几十万动态请求」。截至 2026-10-02，免费计划是每天 100,000 次 Worker 请求，每次 CPU 时间 10ms、内存 128MB、最多 50 个子请求。这里最容易混淆的是：静态资源请求不等于 Worker 调用。一个访问量不低的静态站，真正进入动态接口的请求可能仍然很少。

第三，D1 也不是「无限免费 SQLite」。免费计划目前包含每天 500 万行读取、10 万行写入，以及账户 5GB 存储；单个免费数据库上限 500MB。更重要的是，从 2026-09-01 起这些每日读写额度已经开始强制执行：超额后查询会失败，直到 UTC 午夜重置。

这使索引设计变成实际成本问题。一次查询返回 10 行，不代表只读取了 10 行；如果过滤条件没有索引，数据库可能扫描成千上万行。

R2 的优势则更直接。标准存储目前每月有 10GB-month、100 万次 Class A、1000 万次 Class B 的免费额度，对互联网的出网流量不收费。图片、附件、导出文件这类对象数据，放在 R2 通常比塞进一台 VPS 的磁盘更容易管理。

邮件同样需要划边界。Resend Free 目前是每月 3000 封、每天 100 封；Cloudflare 自己也已经提供 Email Sending，但向任意收件人发送事务邮件需要 Workers Paid，付费计划内含每月 3000 封。它们都适合早期产品，但都不是「无限免费邮件服务器」。

评论区真正争错了问题：请求量不等于计算负载

围绕 Serverless 和 VPS 的争论经常被压缩成一句：

流量大了以后，到底谁更扛得住？

这个问题本身就不完整。

看两个同样有 100 万次请求的接口。

第一个接口只是：

GET /api/product
→ 查一条数据
→ 返回 JSON

每次只消耗几毫秒 CPU，没有本地状态，也没有特殊依赖。这种任务很适合 Workers。请求突然放大时，平台替开发者承担了大量扩容工作。

第二个接口却是：

POST /video
→ ffmpeg 转码
→ 语音识别
→ 生成 PDF
→ Python 后处理

请求数可以完全一样，但运行环境、CPU、内存和任务持续时间已经不是一回事。

所以真正该看的不是「多少请求」，而是：

请求数量
× CPU 时间
× 内存
× 状态需求
× 任务持续时间
× 运行时依赖

这也是为什么「流量大了就该上 VPS」和「流量大了更不该上 VPS」都太绝对。

服务器便宜，不代表服务器没有成本

现在一台能跑小型商业项目的 VPS 并不贵。只比较机器价格，Serverless 甚至未必总是更便宜。

问题在于机器价格只是 TCO（Total Cost of Ownership，总拥有成本）的一部分。TCO 是把采购之外的维护、迁移、故障和人的时间一起算进去。

自己维护服务器，通常还意味着要关心：

系统和运行时更新；
Nginx、TLS 与反向代理；
Docker 与容器生命周期；
数据库备份和恢复；
磁盘、日志和监控；
SSH、防火墙和暴露端口；
宕机、扩容和迁移。

对一个人维护的小产品，真正稀缺的经常不是每月几美元，而是注意力。

托管平台最大的价值不是把服务器费省成零，而是把一部分运维责任从开发者的脑子里移出去。

这也是为什么「如果连一台 VPS 的钱都不愿意花，说明不认真」并不是一个好的架构判断。愿不愿意付钱和应该把钱花在哪里，是两件事。

我现在更倾向的默认结构

如果从零开始一个普通 Web 小产品，我会先按下面的顺序判断：

                Cloudflare Workers
                       │
          ┌────────────┼────────────┐
          │            │            │
    Static Assets     API        定时任务
          │            │
          │       ┌────┴────┐
          │       │         │
          │      D1         R2
          │
      Email Service / Resend

大致对应：

需求	默认选择
HTML / CSS / JS / 图片等静态资源	Workers Static Assets
短时、无状态 API	Workers
轻量关系数据	D1
图片、附件、导出文件	R2
验证码、通知、事务邮件	Resend / Cloudflare Email Service
长任务、原生模块、大内存、常驻进程	Containers / VPS

这里的关键词是「默认」，不是「唯一」。

Cloudflare Containers 已经把边界继续向传统服务器推了一段：当前最大预设规格可以到 4 vCPU、12GiB 内存和 20GB 磁盘，而且空闲后可以缩到零。但它要求 Workers Paid，并按 CPU、内存和磁盘继续计费。它解决的是「偶发重任务不值得养一台常驻机器」的问题，不是把 VPS 从世界上删除。

哪些场景我仍然会直接用服务器

下面这些情况，VPS 或普通容器平台往往更自然：

需要长期常驻进程；
需要 ffmpeg、浏览器、特定 native 模块等复杂系统依赖；
单个任务持续时间长，CPU 或内存消耗明显；
已经有成熟的 PostgreSQL、Redis、消息队列体系；
业务依赖本地文件系统或特殊网络环境；
持续计算负载很稳定，固定规格机器的成本反而更可预测；
需要降低对某一家平台专有 API 的依赖。

这时服务器不是「架构倒退」，而只是更合适的运行时。

Cloudflare-first 不等于 Cloudflare-only

Cloudflare-first 可以翻译成「Cloudflare 优先」：默认先看托管能力能否解决问题，但保留退出路径。

供应商锁定真正危险的地方，不是使用了某个平台，而是业务逻辑和平台 API 完全粘死。

例如数据库层不要到处散落 D1 调用，可以留一个很薄的 Repository（仓储接口）：

interface UserRepository {
  getUser(id: string): Promise<User | null>
  saveUser(user: User): Promise<void>
}

今天底层是 D1，以后需要 PostgreSQL 时替换实现。

对象存储尽量沿用 S3 兼容接口；邮件发送通过自己的 provider 层；重要数据保证有明确的导出路径。抽象不需要做成企业级框架，只要让「换供应商」不是重写整个业务即可。

一个可以直接复用的四问

以后新建小产品，可以先问：

能不能静态化？能，就先交给 Static Assets。
动态逻辑能不能在短时间内、基本无状态地完成？能，就先用 Workers。
数据规模和访问方式是否适合 D1 / R2？适合，就不用先养数据库服务器和文件服务器。
是否出现长任务、特殊依赖、大内存或常驻进程？出现以后，再把这一部分放到 Containers 或 VPS。

这比先问「该买哪台服务器」更接近产品真正需要做的决策。

免费额度应该被当成验证产品的缓冲区，而不是长期商业模式。 产品真的跑起来以后，为托管服务付合理费用没有问题；更重要的是，在还没有用户的时候，不要提前支付复杂度。

最后

Serverless 和 VPS 并不是二选一。

更实用的结构是：

Cloudflare-first
       │
       ├── 静态页面
       ├── API
       ├── 数据库
       ├── 对象存储
       └── 邮件
              │
              └── 超出边界
                     ↓
              Container / VPS

服务器仍然重要，只是不再需要自动成为每一个项目的第一块积木。

对个人开发者和小团队来说，这个顺序的变化可能比「一年省几百块服务器费」更重要：先把时间花在产品、内容和用户上，等基础设施真的成为问题时，再解决那个已经存在的问题，而不是预先维护一个尚未发生的问题。

文中产品配额与价格核验于 2026-10-02；Cloudflare 与 Resend 的套餐会变化，实际使用前以官方文档为准。