早在 2023 年底，我把一个客户的电商店铺从 Vercel 迁移了出去，原因是单个月份的账单高达 $340。中等流量的 SaaS。没什么特别的。创始人在周五下午打电话给我，听起来真的很担忧，老实说，我没有很好的辩护理由。我默认选择 Vercel 是因为这是我熟悉的东西，感觉快速上手，而且 Next.js 文档基本上假设你会用它。那次迁移到 Cloudflare Pages 花了我一个下午，月成本降到了大约 $22。从那以后，我一直更加留意。
所以这是我在 2026 年在 Seahawk 的客户工作中运行两个平台后的真实立场：Cloudflare Pages 已经成熟得非常多，Vercel 也没有停滞不前，"我应该用哪一个"这个问题与其说是关于品牌忠诚度，不如说是关于你实际上在构建什么。
定价现实（以及 Vercel 仍然令人头疼的地方）
Vercel 的免费层对于副业项目来说确实不错。爱好计划，无限部署，预览 URL，足够的构建分钟数。一旦升级到 Pro（$20/月每个席位），对于单个开发者来说就足够了。但对于机构呢？按席位计费模式增长很快。六个开发者的团队，那就是 $120/月，还没有处理过一个请求。然后你加上带宽、边缘函数调用和图像优化，账单开始看起来像 2009 年的手机套餐合同，你永远不太清楚自己在为什么付钱。
Cloudflare Pages 建立在一个根本不同的经济模型上。免费层包括无限网站、无限请求和每月 500 次构建。Pro 计划是 $20/月固定价格，不是按席位收费。对于 Seahawk 来说，这个区别很重要，因为我们从单个账户为多个客户管理构建。我在 2025 年初运行的一个典型月份的数字：14 个活跃项目，共计约 210 万个边缘请求。在 Cloudflare 上，我们支付了 $20。在 Vercel 的等效使用层上，估算大约是 $180-$220，取决于哪些附加功能处于活跃状态。
话虽如此，Vercel 的定价确实为你换来了实实在在的东西。这个我待会儿再说。
带宽和出口流量陷阱
这是个没人会提前警告你的问题，直到为时已晚。Vercel 在 Pro 计划中超过 1TB 后会对带宽收费。听起来还好。大多数项目永远达不到那个量。但返回大型响应的 Edge Functions，或者进行服务端图像处理的项目，会以不成比例的方式消耗带宽。
Cloudflare 的整个网络在其平台内提供无限制出口流量。Cloudflare 的定价页面对此明确说明。Workers 和 Pages Functions 请求在免费的每日 10 万次请求之后，按照每百万次 $0.30 定价。这是透明的。可预测的。我睡得着觉。Cloudflare's pricing page makes this explicit. Workers and Pages Functions requests are priced at $0.30 per million after the free 100k daily requests. That's transparent. Predictable. I can sleep.
边缘网络覆盖：Cloudflare 领先，但不是魔法
截至 2026 年，Cloudflare 在全球拥有超过 300 个数据中心。Vercel 运行在较小的地区集合上，主要由 AWS 基础设施支撑。对于大多数英国和欧洲项目，边缘冷启动延迟的差异是真实存在的，但幅度不大。对于同时为拉各斯、孟买或圣保罗的用户服务的 SaaS 产品？Cloudflare 的覆盖差距几乎可以忽略不计。
我在 2024 年从事过一个服务于东南亚用户的多语言 SaaS 项目。我们最初在 Vercel 上推出，从新加坡来的 p99 延迟徘徊在 380ms 左右。还不错。我们将 API 中间件迁移到 Cloudflare Workers，把它降到了 95ms。代码基本相同。只是边缘节点密度不同。
Workers 对比 Edge Functions：运行时的分化
这是真正技术性且真正重要的地方。Vercel Edge Functions 运行在 V8 isolate 模型上（与 Cloudflare Workers 的哲学相同），但它们与 Vercel 自身基础设施和 Next.js 中间件系统的耦合更紧。Cloudflare Workers 在这方面已经摸索了更久。Workers 运行时支持 Web Crypto、Streams、KV、R2、Durable Objects，以及一套 Vercel 上没有直接等价物的绑定。Workers runtime supports Web Crypto, Streams, KV, R2, Durable Objects, and a suite of bindings that have no direct equivalent on Vercel.
如果你在构建需要在边缘存储持久状态的东西（比如：在线状态指示器、带共享状态的速率限制、实时协作功能），Cloudflare Durable Objects 确实很有用，而 Vercel 目前还没有与之相匹配的东西。
也就是说，如果你要部署 Next.js 14+ 应用，使用 App Router，并且想要零配置的 ISR、Edge 流式传输，以及与 RSC 设置"开箱即用"的中间件，Vercel 仍然是更顺畅的选择。这不是观点。这只是我每次尝试使用 @cloudflare/next-on-pages adapter 在 Cloudflare Pages 上复制 Vercel 的 Next.js 集成时看到的情况。它能用。只是不够顺畅。@cloudflare/next-on-pages adapter. It works. It's just not frictionless.
开发者体验：诚实版本
我想这里要小心，因为 DX 是主观的，也是最多部落观点存在的地方。所以让我就描述一下我实际观察到的情况。
Vercel 的控制面板很漂亮。预览部署是即时的。GitHub 集成是我在任何地方用过的最好的。当你推送一个分支时，预览 URL 在暖缓存下 45 秒内就上线了，PR 上的部署评论会展示你的 Core Web Vitals、构建耗时和直接链接。这个反馈循环很快，感觉很好。这很重要，尤其是当你在引导一个非技术客户，他们想点击链接看到自己的更改时。feels good. That matters, especially when you're onboarding a non-technical client who wants to click a link and see their changes.
自 2022 年左右感觉像是附加到 Workers 上的事后想法以来，Cloudflare Pages 已经大幅改进了它的控制面板。构建系统现在更快，预览部署运行良好，Pages + Workers 集成（通过 wrangler.toml）确实不错。但 Cloudflare 产品表面的心智模型更广，因此更难。你有 Workers、Pages、R2、KV、D1、Durable Objects、Pages Functions，它们各自有略微不同的配置界面。developers.cloudflare.com 上的文档很全面但很庞杂。wrangler.toml) is genuinely nice. But the mental model of Cloudflare's product surface is broader and therefore harder. You've got Workers, Pages, R2, KV, D1, Durable Objects, Pages Functions, and they all have slightly different configuration surfaces. The documentation at developers.cloudflare.com is thorough but sprawling.
说实话，我见过 Seahawk 的初级开发者一天内就上手 Vercel。Cloudflare Pages 需要大约一周时间，才能让人停止怀疑他们的函数是 Worker 还是 Pages Function，以及哪个配置文件控制什么。
本地开发和 Wrangler
Cloudflare 的 wrangler dev CLI 不错。它运行 Workers 运行时的本地模拟并支持大多数绑定。但"模拟"是关键词。我发布过在本地运行正常、但在实际边缘网络上表现不同的代码，原因是 KV 在预览和生产中行为的细微差异。2025 年的小 bug，在预发布环境中发现，但它花了我半天时间。wrangler dev CLI is good. It runs a local simulation of the Workers runtime and supports most bindings. But "simulation" is the operative word. I've shipped code that worked locally and behaved differently on the actual edge network because of subtle differences in how KV behaves in preview versus production. Small bug in 2025, caught in staging, but it cost me half a day.
Vercel 的 vercel dev 命令在某些边界情况下功能更有限，但对于标准的 Next.js 项目，它几乎总是生产的忠实副本。这种可预测性很重要。vercel dev command is more limited in some edge cases but it's almost always a faithful replica of production for standard Next.js projects. That predictability matters.
Next.js 之外的框架支持
这是一场被低估的对话。从功能上讲，Vercel 是一家 Next.js 托管公司，同时也支持其他框架。SvelteKit、Nuxt、Astro、Remix、SolidStart 都能运行，而且运行得很好。但 Next.js 获得新功能的速度最快，默认配置也更优，显然是首要使用场景。
Cloudflare Pages 对框架没有偏好。在 Pages 上使用 Astro 是一种享受。Cloudflare 的 SvelteKit 适配器已维护且稳定。自 2024 年中期以来，我一直在 Pages 上运行多个 Astro 项目，其构建时间比同等站点的 Vercel 部署更快（根据我自己的构建日志，平均快 30-40%）。
如果你的团队要从 Next.js 迁移，或者跨项目使用多个框架，Cloudflare Pages 更加框架无关，这种中立性长期来看是有收益的。
2026 年我会选择哪个
让我直言不讳。这是我实际使用的决策逻辑：
选择 Vercel，如果：
- 你的项目是 Next.js 优先，且深度使用 App Router（RSC、流式传输、ISR，应有尽有）
- 你的客户需要看到预览部署并在上面评论，无需任何技术阻力
- 你的团队很小（1-3 个开发者），按座位计费的成本可以忽略
- 你在构建的东西中，一流的 Next.js 支持值得溢价
如果您符合以下条件，请选择 Cloudflare Pages：
- 您是正在运营超过四五个实时项目的代理商或个人运营者
- 成本可预测性比最顺畅的 Next.js 开发体验更重要
- 您需要 Workers 绑定（KV、R2、Durable Objects、D1）作为架构的一部分
- 您的用户群体分布在全球各地，非美国地区的边缘延迟很关键
- 您不受 Next.js 束缚，希望获得框架灵活性
以 Seahawk 的客户工作为例，我们采用了分割策略：Cloudflare Pages 用于营销网站、内容密集型构建和任何基于 Astro 的项目。Vercel 用于复杂的 Next.js SaaS 产品，特别是当客户的开发团队已经在该生态系统中时。
没人谈论的关键：支持
Vercel Pro 为您提供电子邮件支持。企业版提供更多支持。它反应迅速，团队对 Next.js 有深入的了解。如果在周四凌晨 2 点客户上线前您的部署管道出现故障，拥有一个真正理解 ISR 重新验证底层工作原理的支持人员会很有价值。
Cloudflare 的 Pages 特定支持模式历来一直有些不稳定。他们的 Discord 社区很活跃，Workers 团队易于接近，但 Pages 特定的支持工单解决时间可能比您希望的要长。这在 2025 年有所改善，但我仍然认为 Vercel 在这方面更胜一筹（双关语，抱歉了）。
---
常见问题
Cloudflare Pages 在 2026 年真的可用于生产环境吗？
是的，完全没问题。"Cloudflare Pages 仍在测试版" 的认知已经过时了。它正在运行严肃的生产工作负载。Pages 平台的状态一直很稳定。主要的注意事项围绕 Next.js 适配器（社区维护，不是官方支持）和 Cloudflare 更广泛产品体系的学习曲线。Pages platform status has been consistently strong. The main caveats are around the Next.js adapter (which is community-maintained, not first-party) and the learning curve around Cloudflare's broader product surface.
我能在 Cloudflare Pages 上使用 Next.js App Router 吗？
可以的，通过 @cloudflare/next-on-pages 适配器。它支持 App Router 的很大一部分功能，包括 Server Components、动态路由和中间件。但是某些依赖 Vercel 特定基础设施的功能（比如通过 Vercel API 进行按需重新验证的高级 ISR）要么不工作，要么需要解决方案。如果你在构建复杂的 Next.js 应用，在做出承诺之前要测试你的具体功能需求。@cloudflare/next-on-pages adapter. It supports a significant subset of App Router features including Server Components, dynamic routes, and middleware. But some features that rely on Vercel-specific infrastructure (like advanced ISR with on-demand revalidation via the Vercel API) either don't work or require workarounds. If you're building a complex Next.js app, test your specific feature requirements before committing.
Vercel 的免费层适合客户网站吗？
从技术角度说可以，但 Vercel 针对 Hobby 计划的服务条款限制了商业用途。如果你在为付费客户构建，应该升级到 Pro。这不是个灰色地带，他们不会长期忽视这个问题。客户项目用 Pro。
哪个平台对 SEO 性能更好？
两个平台默认都不会给你 SEO 优势。但边缘分发和 Core Web Vitals 有关联，通过好的实现，两个平台都能产出优秀的 LCP 和 CLS 分数。Vercel 的 Image Optimisation API（通过 next/image）更成熟，也更容易配置。Cloudflare 的 Image Resizing 功能（在 Pro 计划上可用）需要更多手动设置，但大规模使用时成本更低。next/image) is more mature and easier to configure. Cloudflare's Image Resizing feature (available on Pro plans) requires more manual setup but is less expensive at scale.
Netlify 呢？它还有相关性吗？
Netlify 仍然存在，仍然被使用，尤其是对于拥有深度 Netlify 特定工作流的 JAMstack 团队。但就市场关注度、采用率和 2026 年的平台投资而言，它明显落后于 Cloudflare 和 Vercel。自大约 2023 年以来，我就没有为新项目推荐过 Netlify。
---
2026 年的平台选择实际上没有 Twitter 线程说得那么戏剧化。两者都有效。两者都很可靠。真正的决策是关于成本模型与你的业务是否一致，以及框架与你的团队是否一致。有意识地做出这个决定，而不是默认选择框架文档中"部署"按钮显示的任何东西。