早在 2021 年，我的一个伦敦时尚电商初创公司客户给了我一个简报，说"就把它放在 Vercel 上吧，那是大家都用的"。我差点就这么做了。然后我查看了他们的预期流量模式、团队的工作流程，以及他们需要带有无服务函数的表单但不想花大价钱扩展的事实。我们选择了 Netlify。六个月后，他们扩展得很顺利。但另一个客户，我为柏林一家金融科技公司构建的 SaaS 仪表板，需要 Vercel。不是因为品牌忠诚度。而是因为 Next.js App Router 在各个平台上的表现不同。needed Vercel. Not because of brand loyalty. Because of how Next.js App Router behaved on each platform.
这就是整个争议所在。不是关于哪个平台"更好"。而是关于哪个对你的特定 Next.js 项目更好。让我好好分析一下。for your specific Next.js project. So let me break this down properly.
---
Vercel 的优势：这是他们的框架
有一件事人们说得不够：Vercel 创建了 Next.js。Vercel 创建并维护 Next.js 框架，这意味着当 Next.js 的新功能发布时，Vercel 在第一天就支持它。不是第三十天。是第一天。Vercel created and maintains the Next.js framework, which means when a new Next.js feature ships, Vercel supports it on day one. Not day thirty. Day one.
当 App Router 在 Next.js 13 中推出时，Netlify 争相跟进。React Server Components、流式 SSR、新的 fetch 缓存行为，所有这些在 Vercel 上都立即开箱即用。Netlify 最终也支持了，但花了数周的社区论坛讨论和变通方案才稳定下来。fetch caching behaviour, all of it worked out of the box on Vercel immediately. Netlify got there, but it took weeks of community forum threads and workarounds before things stabilised.
去年我用 Next.js 14 重建了一个客户门户网站，大量使用了 Server Actions。部署到 Vercel 只花了约 40 分钟，包括 DNS 传播。在 Netlify 上要得到同样的结果得花我整个下午，大部分时间都在阅读他们的 Next.js 兼容性文档，试图弄清楚什么功能支持，什么不支持。Next.js compatibility docs trying to figure out what was and wasn't supported yet.
Edge Functions 和 ISR 的问题
Vercel 的增量静态再生成在他们的平台上是真正一流的。你在页面中设置 revalidate: 60，它就完全按照文档工作。在 Netlify 上，ISR 通过他们自己的适配层（称为 Netlify Next.js Runtime）处理。它能工作。但它添加了一个你没有要求的抽象层，当出现问题时调试它真的很痛苦。Incremental Static Regeneration is genuinely first-class on their platform. You set revalidate: 60 in your page and it works exactly as documented. On Netlify, ISR is handled through their own adaptation layer called the Netlify Next.js Runtime. It works. But it adds an abstraction you didn't ask for, and debugging it when something goes wrong is genuinely painful.
对于大量依赖 ISR 的项目、内容丰富的网站、新闻平台、产品目录，Vercel 就是更干净的选择。
---
Netlify 真正的优势
Netlify 不是一个退而求其次的选择。过去五年里我在 Netlify 上构建了超过 400 个网站，对于某些项目类型，它遥遥领先。
表单、身份验证和开箱即用的功能
Netlify 内置表单处理（无需无服务器函数）、Netlify Identity 用于身份验证流、开箱即用的分割测试。对于客户想要一个开箱即用的联系表单而我无需连接 Formspree 账户或编写 Lambda 的代理商项目，Netlify 是真正的时间节省者。works without me wiring up a Formspree account or writing a Lambda, Netlify is a genuine time-saver.
去年我们Seahawk的一个项目是为曼彻斯特的一家房产中介公司开发的房产列表网站。后端没什么花哨的。主要是静态页面、一个联系表单、几个用于房产查询的无服务器函数。我们在一天半内就上线了。Netlify的部署预览、表单通知发送到客户邮箱，以及他们与Sanity的CMS集成让一切变得简单得离谱。
按规模计价
这就是对话变得真实的地方。Vercel的定价增长很快。他们的Pro计划是每位成员每月$20，这听起来还不错，但当你是一个四人团队时，在考虑带宽或函数调用之前，你已经每月要花$80了。
Netlify的Pro计划也是每位成员每月$19，所以表面上看起来类似。但Netlify慷慨的免费层和构建分钟数津贴对于运营很多小型客户网站的代理商来说历来更宽松。我有过几个月，通过一个Netlify团队账户为客户部署了十五个微型网站，账单还是可以接受的。Vercel基于使用量的函数执行定价，如果你不仔细盯着，会相当疼。
---
Next.js App Router：目前真正的差异化因素
如果你还在用Pages Router，这部分基本不适用。两个平台都能很好地处理Pages Router Next.js。但如果你在用App Router构建新项目（老实说，你应该这样做），这个差距就更重要了。
Vercel本地运行App Router功能。Partial Prerendering在Next.js 15中即将正式推出，是针对Vercel基础设施设计的。他们的Edge Runtime、他们的CDN、他们的函数区域，所有这些都是与框架共同设计的。
Netlify的运行时适配是真正令人印象深刻的工程。他们的团队付出了艰苦的努力，让App Router能在他们的平台上运行。但他们总是会落后一步，因为他们是在把别人的框架适配到自己的基础设施上，而不是反过来。
这是一个具体的场景：我用嵌套布局、动态路由段和一些通过Prisma进行数据库调用的Server Components测试了一个Next.js 14应用。在Vercel上，冷启动大约是280ms。在Netlify上，类似函数大小的冷启动我看到的是420-480ms。不是灾难性的。但对于一个SaaS产品，用户坐在加载屏幕上等待时，这个差异是能感受到的。
---
开发者体验：日常现实
让我坦诚地谈论两者。
Vercel 的开发者体验打磨得很精致，甚至有点武断。他们的仪表板很漂亮。部署日志清晰。预览 URL 是自动的。CLI（vercel dev）在本地运行你的项目，环境与生产环境非常接近，包括边缘中间件。使用起来很舒服。 Their dashboard is beautiful. Deploy logs are clear. Preview URLs are automatic. The CLI (vercel dev) runs your project locally with an environment that closely mirrors production, including edge middleware. It's a joy to use.
Netlify 的开发者体验更可配置，稍微有点混乱。他们的 netlify.toml 文件让你能细粒度地控制重定向、headers、构建插件和函数配置，而 Vercel 根本没有在同样的层级上暴露这些。如果你需要在特定路由上自定义 headers，Netlify 的配置更明确、更易读。Vercel 通过 next.config.js 处理这个问题，这没问题，但它不是同样级别的基础设施控制。 Their netlify.toml file gives you fine-grained control over redirects, headers, build plugins, and function configurations that Vercel simply doesn't expose at the same level. If you need custom headers on specific routes, Netlify's config is more explicit and readable. Vercel handles this through next.config.js which is fine, but it's not the same level of infrastructure control.
我的个人工作流：对于我想快速上线、永远不用再考虑基础设施的客户站点，Vercel 更胜一筹。对于我知道会频繁调整部署配置、运行多个环境，且客户团队自己会操作仪表板的项目，Netlify 更胜一筹。他们的 UI 对非技术用户来说不那么吓人。
---
构建性能
给出数字，因为模糊的说法没用。
一个中等规模的 Next.js 项目，比如 80 个页面，TypeScript，Tailwind，几个 API 路由，从 GitHub push 构建：
- Vercel 构建时间：在标准项目上通常为 90-120 秒
- Netlify 构建时间：类似项目为 130-180 秒
Vercel 的构建基础设施更快。他们在此投入了大量资源。Netlify 提供付费构建并发升级来加快速度，但你需要额外付费才能达到相同性能。
还有一件事：如果你使用单体仓库架构，Vercel 通过 Turborepo 提供的远程缓存真正是革命性的。我去年将一个 Seahawk 项目从普通构建迁移到 Vercel 上的 Turborepo 设置，将构建时间从四分钟缩短到九十秒以下。Netlify 没有原生等效功能，虽然你可以自己设置一些缓存。
---
选择建议：我的实际推荐
不是含糊其辞的"视情况而定"答案。这是我的实际决策方式。
选择 Vercel 如果：
- 你在使用 Next.js App Router 搭配服务端组件、服务端操作或 ISR
- 你在构建一个性能一致性很重要的 SaaS 产品
- 你在使用单体仓库或者想要 Turborepo 远程缓存
- 冷启动时间是你产品感知性能的一部分
如果以下情况适用，选择 Netlify：
- 你在构建内容站点、营销站点或代理商客户项目
- 你需要内置表单、Identity 或分割测试，不想依赖第三方工具
- 你的预算紧张，需要在一个账户下管理多个小型站点
- 非技术利益相关者会接触部署仪表板
我还要补充一点：如果你已经在一个大型现有项目中使用 Netlify，迁移到 Vercel 的成本很少值得付出，除非你遇到了特定的框架兼容性问题。反过来也是一样。不要为了理论上的收益而切换平台。
---
常见问题
Vercel 对 Next.js 总是比 Netlify 快吗？
不一定。Vercel 的冷启动通常更快，其边缘网络针对 Next.js 也优化得更好。但对于没有无服务函数处于关键路径中的静态网站，两个平台都通过 CDN 提供资源，性能差异可以忽略不计。在 SSR 路由和函数密集型页面上才会显现差距。
Netlify 能完全支持 Next.js App Router 吗？
能，但有一些需要注意的地方。Netlify 的 Next.js Runtime 支持 App Router，但部分功能如 Partial Prerendering 可能跟不上 Vercel 的支持时间表。对于大多数生产级 App Router 项目，Netlify 表现不错。只是在启动依赖最新 Next.js 功能的项目前，先查一下他们的兼容性说明。Next.js Runtime supports App Router, but specific features like Partial Prerendering may lag behind Vercel's support timeline. For most production App Router projects, Netlify works fine. Just check their compatibility notes before starting a project that relies on bleeding-edge Next.js features.
Vercel 对于代理商使用来说太贵了吗？
取决于你怎么组织账户。Vercel 的按成员定价对团队来说积少成多。很多代理商是按每个客户项目用一个 Vercel 账户，而不是一个团队账户，这样算下来成本差异很大。Netlify 的模式通常对代理商更友好，可以在一张账单下管理多个客户站点。
那自建 Next.js 呢？
完全是个有效的选择，特别是对于需要完整基础设施控制的项目。DigitalOcean droplet 或 fly.io 上用 Node 服务器或 Docker 容器部署，你能获得完全的控制权。你会失去部署预览魔法和一些 DX 的完磨，但换来价格可预测性。我为一些有合规原因不能用第三方 PaaS 的企业客户做过这个。不过对大多数团队来说，这是太多运维开销了。
如果以后可能换平台的话，一开始选哪个平台重要吗？
对于大多数 Next.js 项目来说，从 Vercel 切换到 Netlify（或反过来）其实一点都不难。你的代码不会变。主要是更新环境变量，可能还要改一两个配置文件。真正难迁移的是：自定义 Netlify 插件、Netlify Identity 实现，还有任何使用 Netlify 专有表单处理的东西。如果这些在你的范围内，要提前计划。is painful to migrate: custom Netlify plugins, Netlify Identity implementations, and anything using Netlify's proprietary form handling. Plan ahead if those are in scope.
---
经过九年的网络开发经验和超过12,000次的各种项目部署，诚实的答案是这两个平台都很不错。不过它们并不能互相替代。对于那些Next.js框架最新功能至关重要的正式应用来说，Vercel是正确的选择。对于其他所有情况，Netlify是正确的选择。应该根据你的项目今天真正需要什么来选择，而不是听从本月Twitter上的共识。