那是一个周四晚上，一个客户的 Next.js 网站进入了我只能称之为超时螺旋的状态。无服务器函数卡在 9.8 秒，用户看到空白屏幕，我在午夜疯狂刷新 Vercel 仪表板，试图确定我们是否真的触发了计划限制，还是代码本身就有问题。（老实说，两者都是。）那个项目使用的是 Hobby 计划。它本不应该使用这个计划的。
多年来，我在 Seahawk Media 部署了超过 12,000 个网站。Vercel 是我们堆栈的一部分，特别是对于 Next.js 工作，没有其他东西能与之相比的开发体验。但 Hobby 计划有一些尖锐的边界，在项目出问题之前很容易被忽视。所以这是我对这些边界在哪里以及何时开始重要的真实看法。
Hobby 计划实际上能提供什么
让我们说清楚。截至 2024 年，Vercel 的 Hobby 计划为你提供：
每月 100 GB 带宽
每月 6,000 分钟的构建时间
无服务函数执行超时时间为 10 秒
每天 100 次无服务函数调用...等等，不对。那个限制不存在。但有每月 100 GB 小时的无服务函数执行上限
边缘函数每月 500,000 次调用
一次只能进行 1 个并发构建
部署仅限于个人账户（不支持团队）
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 的忽略构建步骤，在仅有特定文件变更时跳过构建（比如 readme 更新或非代码提交）。
批量提交。与其分别推送 6 个小修复，不如把它们暂存然后一次推送。
这些都不算什么新鲜事儿。但实际上大多数用 Hobby 套餐的开发者就是随意推送，然后到月 20 号左右就奇怪自己的分钟数怎么用完了。
带宽：通常没问题，偶尔有问题
Hobby 套餐的 100 GB 月带宽额度其实还是挺合理的。对于个人项目、作品集、小博客，甚至几百个用户的小型 SaaS 副项目，你可能都达不到这个上限。
问题出在图片密集型网站且没有合适的 CDN 层，或者网站突然流量激增的时候。我有个客户是音乐人，他们的网站在过渡期间用的是我的个人 Vercel 账户（我知道这不对，涉及商业用途什么的）。他们的一首曲子被一个规模不小的播放列表收录了，网站在 48 小时内获得了大约 40,000 次访问。带宽使用量暴增。幸好我们没超过限额，但已经很接近了，所以我立即把他们从 Hobby 套餐转移出去。
如果你在用 Next.js Image Optimisation，要知道通过 Vercel 提供的优化图片会计入你的带宽。而且 Hobby 套餐每月有 1,000 张源图片的优化上限。这个限制几乎没人提起，但如果你在运营摄影作品集或任何图片密集型内容网站，它绝对会让你中招。
商业用途这件事值得多关注
我想回到这个话题，因为我觉得在自由职业圈子里这件事真的被严重低估了。