Vercel Hobby 计划的限制：何时升级

那是一个周四晚上，一个客户的 Next.js 网站进入了我只能称之为超时螺旋的状态。无服务器函数卡在 9.8 秒，用户看到空白屏幕，我在午夜疯狂刷新 Vercel 仪表板，试图确定我们是否真的触发了计划限制，还是代码本身就有问题。（老实说，两者都是。）那个项目使用的是 Hobby 计划。它本不应该使用这个计划的。

多年来，我在 Seahawk Media 部署了超过 12,000 个网站。Vercel 是我们堆栈的一部分，特别是对于 Next.js 工作，没有其他东西能与之相比的开发体验。但 Hobby 计划有一些尖锐的边界，在项目出问题之前很容易被忽视。所以这是我对这些边界在哪里以及何时开始重要的真实看法。

Hobby 计划实际上能提供什么

让我们说清楚。截至 2024 年，Vercel 的 Hobby 计划为你提供：Vercel's Hobby plan gives you:

每月 100 GB 带宽
每月 6,000 分钟的构建时间
无服务函数执行超时时间为 10 秒10 seconds
每天 100 次无服务函数调用...等等，不对。那个限制不存在。但有每月 100 GB 小时的无服务函数执行上限
边缘函数每月 500,000 次调用
一次只能进行 1 个并发构建
部署仅限于个人账户（不支持团队）personal accounts only (no teams)
Vercel 条款中不允许商业用途

最后这一条比任何技术限制都更容易绊住人。Hobby 计划明确是为个人的、非商业项目设计的。如果你是为付费客户构建，或在其上运营任何类型的业务，你已经违反了服务条款。我见过自由职业者这样做了多年，这是一个潜伏的法律风险。

10 秒函数超时

这个最容易卡人。10 秒听起来很长，直到你调用一个需要 4 秒的第三方 API，再加上 3 秒的数据库逻辑，然后处理响应。突然间你已经用了 9.2 秒，没有任何余地了。

在 Pro 计划中，这个上限跳升到 60 秒（企业版配置最高可达 900 秒）。这不是小差别。这是一个正常工作的集成和对某些用例来说根本崩坏的产品之间的区别。

构建分钟数：它们消失的速度比你想象的要快

每月 6,000 构建分钟数听起来很慷慨。对于单个个人项目，它可能确实是。问题是，一旦你开始认真迭代，这个数字会比预期消耗得更快。

回到 2021 年，我在运行一个副项目，一个基于 Next.js 构建的内容聚合器，约 400 个静态页面。我设置了 ISR，但我也在频繁执行完整重建，同时试验数据层。在三周内消耗了大约 4,200 构建分钟。不是因为构建很慢，而是因为我在不断触发它们。

在中等复杂度的 Next.js 网站上，每次构建轻松可以运行 4-8 分钟。如果你在活跃开发期间每天推送到 main 15 次（这对我来说很正常），那就是单日消耗 60-120 构建分钟。这样坚持一周，你就会消耗掉月度配额的一半。

没有结转。分钟数不会月度结转。当你达到零时，你的部署就停止了。完全停止。

如何减缓消耗

我在 Hobby 计划项目中做的几件事来保护构建分钟数：

为实验性更改推送到非生产分支。只在某些东西真正准备好时才合并到 main。
使用 vercel --prebuilt 配合缓存输出，其中构建工件没有发生有意义的变化。vercel --prebuilt with cached outputs where the build artefacts haven't changed meaningfully.
设置 Vercel 的忽略构建步骤，在仅有特定文件变更时跳过构建（比如 readme 更新或非代码提交）。Vercel's ignored build step to skip builds when only certain files change (like readme updates or non-code commits).
批量提交。与其分别推送 6 个小修复，不如把它们暂存然后一次推送。

这些都不算什么新鲜事儿。但实际上大多数用 Hobby 套餐的开发者就是随意推送，然后到月 20 号左右就奇怪自己的分钟数怎么用完了。

带宽：通常没问题，偶尔有问题

Hobby 套餐的 100 GB 月带宽额度其实还是挺合理的。对于个人项目、作品集、小博客，甚至几百个用户的小型 SaaS 副项目，你可能都达不到这个上限。

问题出在图片密集型网站且没有合适的 CDN 层，或者网站突然流量激增的时候。我有个客户是音乐人，他们的网站在过渡期间用的是我的个人 Vercel 账户（我知道这不对，涉及商业用途什么的）。他们的一首曲子被一个规模不小的播放列表收录了，网站在 48 小时内获得了大约 40,000 次访问。带宽使用量暴增。幸好我们没超过限额，但已经很接近了，所以我立即把他们从 Hobby 套餐转移出去。

如果你在用 Next.js Image Optimisation，要知道通过 Vercel 提供的优化图片会计入你的带宽。而且 Hobby 套餐每月有 1,000 张源图片的优化上限。这个限制几乎没人提起，但如果你在运营摄影作品集或任何图片密集型内容网站，它绝对会让你中招。Next.js Image Optimisation, be aware that optimised images served through Vercel count against your bandwidth. And the Hobby plan has a 1,000 source images cap on optimisation per month. That's a limit that almost nobody talks about and it will absolutely catch you if you're running a photography portfolio or any image-heavy content site.

商业用途这件事值得多关注

我想回到这个话题，因为我觉得在自由职业圈子里这件事真的被严重低估了。

Vercel 的条款很清楚。Hobby 是为个人、非商业项目设计的。从客户付钱让你在 Hobby 上构建东西的那一刻起，或者从项目开始产生收益的那一刻起（广告、订阅、销售），你就违反了条款。这不是 Vercel 在咄咄逼人，只是套餐本身就是这样设计的。

我和一些自由职业者沟通过，他们为了省钱把客户项目部署到 Hobby 计划上。有人这样做了多年都没出过问题。但 Vercel 确实会执行这些规则。他们会联系那些看起来在进行商业活动的账户。因为条款违规导致网站被下架，而客户的生意又依赖于这个网站，这不是你想要进行的对话。

Pro 计划是每个成员每月 20 美元。对于任何实际的客户项目，这个费用应该纳入你的项目预算中。这没有商量余地。

单个并发构建何时成为真正的问题

对于个人项目，单个并发构建无所谓。但当你和他人协作开发时，即使只是非正式的合作，问题就开始显现。两个人快速连续推送代码意味着第二个构建会排在第一个后面。

对于个人项目这不是问题。但如果你有贡献者、共同创始人或者也能提交代码的设计师，那么你会注意到排队时间。Pro 计划可以获得最多 12 个并发构建。差异相当大。

Seahawk 今年早些时候有一个小型内部工具项目，我们两个人在一个冲刺期间都在快速迭代同一个 Next.js 代码库。我们为了商业原因选了 Pro，即便如此，重叠的构建偶尔还是会造成摩擦。如果用 Hobby 会明显更糟。

Hobby 对比 Pro：实际的决策树

我的实际想法是这样的：

个人项目，没有收入，个人开发，页面少于 50 个：Hobby 就可以。就呆在那里。 Hobby is fine. Stay there.
侧项目获得真实流量（每月 5,000+ 访问）：开始关注你的带宽和函数执行时间。Hobby 仍然可用，但你已经接近极限。 Start watching your bandwidth and function execution hours. Hobby still works but you're closer to edges.
任何客户项目：Pro。句号。 Pro. Full stop.
API 密集型应用，其中无服务器函数经常接近 5 秒以上：Pro。此时 10 秒的超时限制不够宽松。 Pro. The 10-second timeout is not a comfortable ceiling at that point.
需要多个团队成员在账户上：Pro。Hobby 不支持团队账户。 Pro. Hobby doesn't allow team accounts.
运行电商、订阅或任何交易流程：Pro，并且可能需要仔细考虑 Vercel 的无服务器模型是否适合你的架构。 Pro, and probably think carefully about whether Vercel's serverless model suits your architecture anyway.

对于超出 Pro 的任何需求，Vercel 有企业级方案，可以自定义限制。我只接触过两次企业级方案，都是为了满足客户特定 SLA 要求的项目。对于大多数读到这里的人来说，Pro/Hobby 的选择才是相关的。

值得了解的替代方案

如果预算是真正的制约因素，Vercel 不是你的唯一选择。Netlify 的免费层结构与 Vercel Hobby 相似，每月 300 分钟构建时间（实际上比 Vercel 少），但有 100 GB 带宽。对于无服务器需求最少的静态网站，Netlify 是一个合理的对比。Netlify's free tier has similar shape to Vercel Hobby with 300 build minutes per month (lower than Vercel, actually) but 100 GB bandwidth. For static sites with minimal serverless needs, Netlify is a reasonable comparison.

如果你的使用场景适合 Workers，Cloudflare Pages 值得考虑。免费层带宽无限，构建额度慷慨，Pages 平台已经成熟了不少。对于不需要 Next.js 特定功能的静态网站，我用它。 is worth considering if your use case fits Workers. Unlimited bandwidth on the free tier, generous build allowances, and the Pages platform has matured significantly. I use it for static sites where I don't need Next.js-specific features.

Railway 和 Render 适合全栈应用，你想要比无服务器部署模型更多的控制权。权衡不同，不是 Vercel 的直接竞争者，但值得放在你的工具箱里。