浏览 AI使用教程
Vercel、Netlify、Cloudflare Pages 怎么选
Vercel、Netlify 和 Cloudflare Pages 的选择，要从项目需要的运行时、后台任务、网络和团队流程出发。免费额度只是其中一个条件。
先比较关键条件，再作选择
把自己的条件代入判断项；没有证据的维度保留未知，不用印象替代结论。
前端能上线，不代表你的 API 也有地方运行
团队只比较免费额度，把需要长连接和后台任务的应用放到纯静态托管；前端上线了，核心 API 根本没有运行位置。
- 静态与动态需求已分开
- 限制来自当前官方资料
- 退出和迁移路径可接受
三家按相同需求比较
| 维度 | Vercel | Netlify | Cloudflare Pages/Workers |
|---|---|---|---|
| 动态入口 | Functions有Node、Python等运行时 | Functions可写JS/TS请求处理 | Workers以请求处理和Web APIs为核心 |
| Node依赖 | 核对运行时、打包和原生依赖 | 核对函数打包和依赖支持 | Node兼容是子集，能import不等于能调用 |
| 首轮验证 | 现有短API与框架构建 | 同一API与构建 | 同一API的Worker兼容 |
| 持久状态 | 不用临时文件作为唯一存储 | 不依赖实例内存长期保存 | 使用适当存储绑定 |
| 账号限制 | 时长、区域、权限、费用 | 时长、区域、权限、费用 | 兼容日期、CPU/请求限制、绑定、费用 |
无虚构额度或永久排名。静态站部署成功不能证明动态接口可用。
决定前补实际结果
| 检查 | 固定输入 | 通过标准 | 状态 |
|---|---|---|---|
| 短API | 相同JSON与依赖 | 状态、字段、超时一致 | 三家均未实测 |
| 数据 | 新部署后读取 | 独立存储数据仍在 | 待实测 |
| 回退 | 切回旧版本 | 代码与数据契约兼容 | 待实测 |
先把本例的条件、限制和目标摆出来
| 需要确认 | 本例内容 |
|---|---|
| 现有材料 | 项目为静态前端 + 短时 Serverless API，无长任务；已有 GitHub；需要自定义域名和预览环境。 |
| 不能越过的边界 | 按构建、运行时、函数限制、边缘能力、数据与团队运维比较；价格和配额查当前官方文档。 |
| 要交付的结果 | 项目条件—平台对比表 |
Vercel Netlify Cloudflare Pages 区别，哪些条件会改变最后选择
| 判断条件 | 本例怎么核对 | 本例归类 |
|---|---|---|
| 前端与框架适配 | 框架是否有官方适配，SSR、静态生成、重写和图片处理怎样支持。 | 构建模型 |
| 后端与运行限制 | 函数运行时、区域、超时、文件系统、队列和长连接是否满足业务。 | 动态能力 |
| 数据与网络 | 数据库位置、出口、缓存、边缘一致性和私网需求会不会增加延迟或复杂度。 | 架构匹配 |
| 团队与运维 | 预览、日志、监控、权限、域名、回滚和现有账号流程谁更顺。 | 操作成本 |
| 当前费用和限额 | 按真实流量、构建、带宽、函数和团队席位到官方定价页重算。 | 时效条件 |
Vercel Netlify Cloudflare Pages 区别：按本例条件得到的结论
项目条件—平台对比表
现有标准Node依赖先验证Vercel/Netlify函数适配；已有Workers代码与Cloudflare资源先验证Workers兼容。最终依据同题预览、区域、权限和账户限制；本文没有三家部署实测。
边界变化后需要重新判断
免费额度、限制和产品名称会变化；正式上线前必须重新核对官方定价与运行时支持。
为什么“平台满足技术条件，部署体验仍很差”还不能交付
平台满足技术条件，部署体验仍很差
- 原因
- 忽略团队已有账号、DNS 和调试工具
- 怎么改
- 把迁移、权限和日常排错纳入决策，而不是只看运行时参数