大约十八个月前，一个客户给我打电话，很慌张。他们在 Vercel 上启动了一个 Node.js API，测试时一切看起来都很好，然后他们的第一波真实并发负载来了，WebSocket 连接就……掉了。无声地。仪表板上没有错误，没有告警，什么都没有。我不得不向他们解释，他们选择的平台根本无法保持一个持久连接打开。这不是一个 bug。这就是无服务器的整个要点。我们在那周末把它迁移到了 Render。
这个故事不是特例。我在 Seahawk Media 见过十来次这样的情况。开发者选择 Vercel 是因为它对它所做的事真的很出色，然后他们给它增加了一个它从未为之设计的用例，然后好奇为什么事情会崩溃。所以，这是我基于实际项目交付而非博客中的基准测试，对何时使用哪个平台的真实想法。
Vercel 实际上擅长的是什么
让我说清楚：我用 Vercel。很多。对于营销网站、Next.js 应用、API 层很薄的内容繁重的前端，Vercel 仍然是从 git push 到有 CDN 的实时 URL 的最快方式。Vercel Edge Network 对于静态和 ISR 内容真的令人印象深刻。预览部署对于客户交接来说是魔法。Vercel Edge Network is genuinely impressive for static and ISR content. Preview deployments are magic for client handoffs.
它具体的闪光点：
- 使用 ISR 或 SSG 的 Next.js 应用，其中页面是预渲染或按计划重新生成的
- 前端为主的项目，后端依赖第三方 API（Stripe、Sanity、Shopify）
- 需要频繁部署并需要分支预览用于 QA 的团队
- 任何冷启动延迟可接受的场景，因为流量是可预测且突发的
这些工作负载的价格也不错。一个小型 SaaS 在 Pro 计划上每月 $20 的费用完全合理，如果你的函数生命周期短且无状态。
你无法争辩的无服务器约束
Vercel 上的函数会超时。在 Hobby 计划上默认是 10 秒，在 Enterprise 最多 300 秒。更重要的是，每次调用都是隔离的。请求之间没有共享内存。没有持久文件系统。没有在后台运行的长期进程做工作。
对于大多数网络应用，老实说，这没问题。但有一大类东西根本无法在这些约束内工作。
无服务器开始伤害你的地方
早在 2021 年，Seahawk 有一个金融科技项目，客户需要实时交易源推送到仪表板。原来的开发人员尝试过用每两秒轮询来勉强实现。糟糕透了。我们需要 WebSocket。真正的、持久的、有状态的连接。Vercel 立即被排除了。
这是我经常看到无服务器架构达到其极限的地方:
- WebSocket 连接。任何基于 AWS Lambda 的平台都无法保持套接字连接打开。这是铁律。 Any platform built on AWS Lambda underneath cannot hold a socket open. Full stop.
- 后台任务和队列。如果你需要一个每 15 分钟唤醒一次来处理任务队列的 worker，你需要一个持久运行的进程。Vercel Functions 做不到这一点。 If you need a worker that wakes up every 15 minutes to process a job queue, you need a process that persists. Vercel Functions aren't that.
- 长时间运行的计算。PDF 生成、视频转码、大型报告导出。即便有 300 秒的限制，你也是在绕过架构而不是利用它。 PDF generation, video transcoding, large report exports. Even with the 300-second limit, you're patching around the architecture rather than working with it.
- 内存缓存。如果你使用像 node-cache 这样的工具在请求之间将数据存储在 RAM 中，该缓存会在每次函数调用后被销毁。你会无谓地耗尽数据库连接池。 If you're using something like
node-cacheto store data in RAM between requests, that cache is destroyed after every function invocation. You'll burn your database connection pool for no reason. - 数据库连接池。这个问题经常坑人。像 Prisma 这样的 ORM 会为每次函数调用打开一个新连接。在任何合理的流量水平下，你都会耗尽 Postgres 连接限制。你最终会添加 PgBouncer 或 Supabase 的连接池作为变通方案，虽然能工作，但你是在跟平台较劲。 This one bites people constantly. ORMs like Prisma open a new connection per function call. At any reasonable traffic level you'll exhaust your Postgres connection limit. You end up adding PgBouncer or Supabase's connection pooler as a workaround, which works, but you're fighting the platform.
Render 做对的地方
Render 运行真正的持久进程。Web 服务、后台 worker、cron 任务。当你的 Node 进程启动时，它会持续运行。这意味着内存状态、WebSocket 服务器、长时间运行的任务，一切都像在任何 Linux 机器上一样工作。
免费层对暂存环境很有用（虽然闲置 15 分钟后会冷启动，这很烦人）。$7/月的 Individual 计划给你一个无冷启动的持久服务，$25/月的计划增加 RAM 并给你 SSH 访问权限，我经常用它来调试。
针对后端服务的合理定价
对于不需要大规模扩展的后端API，Render具有非凡的成本可预测性。你按实例付费，而不是按调用次数付费。当你的服务执行稳定、一致的工作时，这一点很重要。在Vercel上，每小时运行数千次的函数会以你想不到的方式增加成本。在Render上，这是一笔固定的月费。
我去年为一个客户做过对比，他们的Node.js API平均每天处理约50k个请求。他们的Vercel账单已经达到180英镑/月。我们把API移到了Render的$25实例，把它连接到他们现有的Vercel前端，后端托管费用降到了25英镑。前端继续用Vercel，因为那才是Vercel该用的地方。
我现在实际使用的架构
构建了足够多的项目后，我已经确立了一个相当清晰的心智模型。这不是非此即彼的选择。
- 前端（Next.js、Astro，或其他）放在Vercel上。分支预览、边缘CDN、即时回滚。没有任何疑问。
- 任何有状态的后端、需要持久连接的API或工作进程都放在Render上。
- Postgres或MySQL放在Railway或Render自己的托管Postgres上，具体取决于预算。Railway or Render's own managed Postgres, depending on budget.
- Redis放在Upstash上（如果是无服务器兼容的使用），或Render Redis实例上（如果应用需要持久性保证）。
我花了不好意思的长时间才确定了这种分离方式。有一段时间我试图让所有东西都适应Vercel，因为它的开发体验太棒了。但与平台限制对抗花费的时间比便利带来的节省更多。
连接Vercel前端到Render后端
从机制上讲这很直接。你在 Vercel 中设置 NEXT_PUBLIC_API_URL 环境变量指向你的 Render 服务 URL，在 Render 端处理 CORS，基本上就完成了。Render 开箱即提供稳定的子域名（yourservice.onrender.com），你也可以轻松附加自定义域名。NEXT_PUBLIC_API_URL environment variable in Vercel to your Render service URL, handle CORS on the Render side, and that's basically it. Render gives you a stable subdomain out of the box ( yourservice.onrender.com) and you can attach a custom domain easily enough.
要注意一点：Render 的免费计划服务在 15 分钟无活动后会休眠。如果你的前端在 Vercel 上，后端在免费的 Render 服务上，用户偶尔会遇到 30 秒的冷启动延迟，此时 Render 容器在唤醒。用于生产环境，直接购买 $7 的计划。这种 UX 损害不值得。
具体场景和我实际会选择的方案
我直接说吧，因为大多数对比文章在这里都会含糊其辞。
场景 1：Next.js 营销网站加联系表单。选 Vercel。显而易见。内容页面用 ISR，表单用简单的 API 路由调用 SendGrid。没必要引入 Render。 Vercel. Obviously. ISR for the content pages, a simple API route for the form that calls SendGrid. No reason to introduce Render.
场景 2：SaaS 应用，配 Node/Express REST API、Postgres 和偶尔的后台任务。前端在 Vercel，后端 API 在 Render（$25 计划），Postgres 在 Render 的托管数据库。后台任务用 Render Background Workers。这大概是我现在最常用的配置。 Frontend on Vercel, backend API on Render ($25 plan), Postgres on Render's managed database. Background jobs as Render Background Workers. This is probably my most common setup right now.
场景 3：使用 Socket.io 的实时协作应用。选 Render，就这样。你需要一个持久进程。对于任何有意思的 Socket.io 应用，我其实会倾向于至少 512MB RAM 的 Render 服务。 Render, full stop. You need a persistent process. I'd actually lean toward a Render service with at least 512MB RAM for a Socket.io app doing anything interesting.
场景 4：简单的无头 WordPress 前端。选 Vercel。Next.js 配 ISR 从 WPGraphQL 拉取数据。"后端"就是 WordPress，Render 不需要。 Vercel. Next.js with ISR pulling from WPGraphQL. The "backend" is WordPress, Render doesn't enter the picture.
场景 5：Python FastAPI 或 Django 应用。选 Render。Vercel 有 Python 运行时支持，但功能有限，你会不断碰到函数时长限制。Render 就像正常服务器一样运行你的 Python 进程。 Render. Vercel has Python runtime support but it's limited and you'll constantly bump into the function duration ceiling. Render just runs your Python process like a normal server.
冷启动问题，坦白说
人们谈论 Vercel 的冷启动就像在谈论一个小烦恼。对于大多数前端工作负载来说，确实如此。但我见过 Vercel 函数在 Hobby 计划上冷启动需要 3-4 秒的情况，当你捆绑了大量依赖项时。这对用户来说是一个糟糕的首次体验。
Render 的非免费套餐根本不会冷启动。你的进程是启动的。AWS Lambda 冷启动是 Vercel 有这个问题的根本原因，因为 Vercel 的函数在 Lambda 上运行。这不完全是 Vercel 的错，而是无服务器模型的权衡。AWS Lambda cold starts are the underlying reason Vercel has this problem, since Vercel's functions run on Lambda under the hood. It's not Vercel's fault exactly, it's the serverless model's trade-off.
对于对延迟敏感的 API，尤其是任何在每个请求上运行的面向用户的东西，Render 上的持久服务器在实践中通常感觉更灵敏，尽管原始规格看起来相当。
当都不是正确的选择时
如果你需要运行按需水平扩展到几十个实例的应用，你可能需要考虑 AWS 上的 ECS、Google Cloud Run 或 Fly.io。Render 的自动扩展存在，但对于真正可变的流量来说，粒度不够细。显然 Vercel 默认情况下水平扩展，因为每个函数调用都是独立的。
Fly.io 值得在这里提一下。从概念上讲，它更接近 Render（持久虚拟机），但具有更好的全球分布和更多控制权。我在需要特定区域中的实例的对延迟敏感的应用中使用过它。不过比 Render 的 DevOps 开销要多一些。
常见问题
Render 的前端托管速度比 Vercel 慢吗？
对于纯前端托管，通常是这样。Vercel 的 CDN 专门为此优化。Render 的静态网站托管运行良好，但它没有相同的边缘网络覆盖范围。如果你在托管前端，Vercel 在交付速度方面获胜。
我能在 Render 上运行 Next.js 应用吗？
可以。Render 支持 Node.js，所以你可以在 Render web 服务上运行 next start。你会失去 ISR 按照 Vercel 原生处理方式工作的能力，而且开箱即用不会得到预览部署。对于 Next.js 应用来说，Vercel 仍然是更好的选择，除非你有具体的理由要避免它。next start on a Render web service. You lose things like ISR working the way Vercel handles it natively, and you won't get preview deployments out of the box. For a Next.js app, Vercel is still the better choice unless you have specific reasons to avoid it.
Vercel 支持 WebSocket 吗？
从传统意义上讲不支持。Vercel 通过他们较新的流传输功能确实对长连接有一些支持，但这不能替代一个真正的 WebSocket 服务器。如果你的应用依赖 socket.io 或类似的库进行有状态连接，就在 Render 或 Fly.io 上运行它。socket.io or a similar library with stateful connections, run it on Render or Fly.io.
Netlify 呢？你为什么提及它不多？
Netlify 没问题。在这个讨论中它实际上和 Vercel 属于同一类别：无服务函数、CDN、非常适合静态和 SSR 前端。同样的持久服务器局限也适用。我在 Seahawk 用 Vercel 更多，所以这是我能诚实地谈论的对比。
数据库托管如何考量？
不要在 Render 免费实例上运行你的生产数据库。Render 上的免费 Postgres 适合开发和暂存环境，但存储限制很紧张而且会被暂停。对于生产环境，我通常使用 Render 的付费托管 Postgres（7 美元/月起价）或者如果客户想要行级安全和 Supabase 工具的话就用 Supabase。
---
简短版本：Vercel 是一个恰好运行服务端代码的前端平台。Render 是一个恰好有很好 UI 的服务器平台。一旦你理解了这个区别，任何给定项目的决策大约需要三十秒。两个都用。他们在不同的事情上确实很擅长，而且运行混合设置的成本基本上是零。