选部署平台时，最容易被首页价格误导。一次 bot 扫描、一次循环任务、一次数据库连接泄漏，都可能比「月费 $20 还是 $25」更早决定账单。
所以先别问哪家最便宜，把产品拆成前端页面、API、后台任务、数据库、文件存储、日志和域名，再对照官方 limits。
你的产品先撞哪类限额？
表 1：四个平台适配表
| 产品形态 | 默认选择 | 为什么 | 查的后台字段 |
|---|---|---|---|
| 静态内容站、landing page、轻 API | Cloudflare Pages | 构建和全球边缘分发简单，Pages Functions 适合小接口 | Pages Builds、Workers Requests、Functions invocations |
| Next.js 全栈、营销页加订阅 | Vercel | 框架集成顺，预览部署和团队协作省时间 | Usage、Fast Data Transfer、Function Invocations、Runtime Logs |
| 长驻 Web 服务、后台 worker、cron | Render | 更像传统 PaaS，Web service、worker、cron、数据库清楚分层 | Services、Bandwidth、Build minutes、Databases |
| Auth、Postgres、Realtime、Edge Functions | Supabase | 数据库和登录体系省开发时间 | Compute、Disk、Egress、Edge Function Invocations、Spend Cap |
这不是谁替代谁。一个常见组合是：前端放 Vercel 或 Cloudflare Pages，数据库和 Auth 用 Supabase，长任务放 Render。问题出在你以为一个平台能无痛包下所有工作负载。
2026 年官方 limits，读哪几行？
表 2：限额和账单字段对照表
| 平台 | 官方限额里最该看的数字 | 容易漏掉的费用或限制 | 后台路径 |
|---|---|---|---|
| Vercel | Build Time 每次 45 分钟；Hobby 每月 1M invocations、100GB Fast Data Transfer；Pro 首 1TB Fast Data Transfer | Pro 额外 Function Invocations $0.60 / 1M；runtime logs Hobby 1 小时、Pro 1 天 | Vercel Dashboard → Usage / Billing / Runtime Logs |
| Render | Hobby 25 个服务、5GB outbound bandwidth、500 build minutes；Pro $25/月含 25GB 带宽、1000 build minutes | 超出带宽 $0.15/GB；Pro/Scale 改为 workspace flat pricing；compute 另算 | Render Dashboard → Billing / Metrics / Service Logs |
| Cloudflare Pages | Free 每月 500 builds、20 分钟 build timeout、20,000 files；Paid 可到 100,000 files | Pages Functions 请求会计入 Workers 相关配额；单文件 25MiB | Cloudflare Dashboard → Pages → Builds / Workers usage |
| Supabase | Edge Functions paid 400 秒 wall-clock、256MB memory、20MB bundle；Free 100 functions | Spend cap 不覆盖 compute、read replica compute、IPv4、PITR 等 | Supabase Dashboard → Organization Usage / Billing / Spend Cap |
Vercel 文档还有一个很实际的限制：旧项目如果没用 Fluid compute，函数默认时长 Hobby 10 秒、Pro 15 秒，最大 Hobby 60 秒、Pro 300 秒。把 AI 生成、PDF 导出、爬虫或长轮询放进去，迟早会撞墙。
哪些账单风险最容易被漏掉？
Vercel 的风险多在请求和带宽。搜索结果里能看到不少真实讨论：有人遇到 $800+ 账单，也有人因为 bot 流量拿到更夸张的 Vercel 账单。真假细节各自不同，但模式很一致：人类用户没暴涨，自动流量和函数调用先暴涨。
Supabase 的风险在 spend cap 覆盖范围。官方 cost control 文档写得很清楚，spend cap 开启后，覆盖资源超额会停用或不再产生 overage；但 compute 明确不在 spend cap 保护里。数据库负载、分支计算、IPv4 和 PITR 这类东西，不能靠一个开关兜底。
Cloudflare Pages 的风险是你把 Pages 当成无限 Workers。Pages Functions 会进入 Workers 相关配额，KV 或 Durable Object 绑定也会产生对应请求。静态站很舒服，动态接口多了就要单独看 Workers 账单。
Render 的风险更传统：服务数量、带宽、构建分钟和 compute。它适合长驻服务，但别把免费或 Hobby 的限制当生产 SLA。
上线前要填哪张容量表？
表 3：SaaS 上线前容量表
| 模块 | 你要填写的数字 | 对应平台字段 | 触发动作 |
|---|---|---|---|
| 首页和文档 | 每月 page views、静态文件总数、单文件最大体积 | Cloudflare Pages files、Vercel Fast Data Transfer | 超过文件或带宽预估时拆 CDN/R2 |
| API | 峰值 RPS、P95 时长、是否需要长连接 | Vercel Function duration、Render Web service metrics | 超 10-15 秒的请求不要放 serverless 默认路径 |
| 后台任务 | 每天任务次数、单次运行时间、失败重试次数 | Render Worker/Cron、Vercel Cron、Supabase Edge Function duration | 任务超过函数生命周期时拆 worker |
| 数据库 | 连接数、慢查询、存储增长、备份需求 | Supabase Compute、Disk、PITR、connection pool | 开启连接池，给 compute 单独预算 |
| 文件和日志 | 每月上传量、下载量、日志保留天数 | Vercel Logs、Cloudflare R2、Supabase Storage Egress | 日志和文件别和主应用混算 |
| 防滥用 | bot 访问、注册频次、失败支付频次 | WAF、rate limit、Radar、Turnstile | 先限流，再谈扩容 |
容量表不需要很精确，但要能回答一个问题：如果明天被 bot 打 10 倍请求，哪个平台先开始收费，哪个平台先停服，哪个后台能告诉你发生了什么。
四种常见组合怎么选？
纯内容站和轻工具
Cloudflare Pages 足够。看好 build 次数、20 分钟构建超时、文件数量和单文件 25MiB。需要大文件就放 R2，不要硬塞进 Pages assets。
Next.js SaaS
Vercel 上线最快。支付、账号、订阅、后台页面都能很快跑起来。但长任务、Webhook 重试、PDF 导出、批量邮件和 WebSocket 不要都放 Functions。
有后台 worker 的产品
Render 更直观。Web service、background worker、cron 和数据库分开建，日志也更像传统后端。缺点是你要自己认真看 compute 和带宽，不会像静态托管那样轻。
数据库和 Auth 优先
Supabase 很适合一个人快速做 MVP。Postgres、Auth、Storage、Edge Functions 省时间。上线前必须看 cost control，尤其是 compute 不进 spend cap 这件事。
什么时候需要拆平台？
出现这 4 个信号就该拆：函数经常接近最大时长，数据库连接池被打满，日志只保留 1 天不够排查，账单里看不懂是谁在烧钱。
部署、账单和数据库后台经常要一起打开。处理生产事故时，临时网络断一下就会丢掉关键上下文。可以把核心后台固定在一套工作环境，用海外服务跑 GitHub Actions / Cloudflare 的稳定线路承载部署、监控和账单排查。