Vercel 价格不只是月费：Hobby 旧预览可能撑不到 30 天

Vercel 价格和部署保留规则要放在一起看：Hobby 的 30 天部署历史已经不能再视为可靠的回滚承诺。自 2026 年九月 16 日起，只要某个 Hobby 团队超过 10GB Deployment Storage 上限，未受任何保留例外保护的旧预览部署或生产回滚目标，就可能立即被删除。

当前生产部署仍然安全。带有符合条件别名的部署，以及活跃 Git 分支的最新预览也仍受保护。变化落在这些保护范围之外：个人原型可能照常运行，旧的评审链接却会悄然失效。

30 天已不再是最低保留线

部署保留规则决定 Vercel 会把每次部署背后的构建文件保留多久。正是这些已存文件，让你可以重新打开旧预览、无需重新构建便提升经过测试的版本，或在故障期间回滚生产环境。

Hobby 的常规保留期仍为 30 天。新增的是超额清理规则：团队一旦超过 10GB Deployment Storage，未受保护的部署就可能在 30 天期满前进入删除范围。这正是此次调整对使用者的实际影响。免费的部署历史现在同时取决于存储用量，以及部署是否符合下述例外。

每个 Hobby 项目对近期部署有两类保护：

• 最新创建的 3 个部署，不限类型
• 最新 3 个状态为 Ready 的生产部署

这两类应视为一个合并后的集合，而不是六个预留名额。某个近期生产部署可能同时属于两类。如果最新的三个部署恰好也是最新的三个 Ready 生产版本，那么这两条规则实际保护的仍是同样的三个部署。

预览部署不再单独享有“近期预览”名额。排在最新三个部署之外的预览，只有命中其他例外才能继续保留。

Vercel 仍会保护哪些部署

理解这套规则最简单的方法，是把保护条件分成两类：一类取决于部署是否足够新，另一类取决于部署当前如何被使用。

这些例外来自 Vercel 当前的部署保留规则。仅仅保存一个部署 URL，并不属于列出的保护条件。真正起作用的是部署关联的别名、分支、生产状态或近期排序。

这一点会改变一种常见工作流：你把预览发给他人，合并拉取请求，然后默认该链接在当月余下时间仍然可用。一旦分支不再活跃，它的“最新预览”例外就会结束。如果团队已经超过 10GB，而且该部署也不在两个“最新三个”集合中，这个链接可能在第 30 天前就失去目标。

这项调整实际影响谁

最典型的是同时维护多个个人原型的独立开发者。旧项目可能一直占用构建产物存储，活跃项目又持续部署。团队一旦越过上限，Vercel 就可以清理整个 Hobby 团队内未受保护的历史记录；你真正需要的回滚目标，可能恰好属于一个近期没有动过的项目。

分享非商业概念稿的设计师面临另一种风险。开放评审分支的当前预览受保护，但此前某次设计决策所用的旧链接可能不受保护。如果必须继续查看那个确切版本，就要在分支关闭前给它配置符合条件的自定义别名，或准备其他保留方案。

把部署历史当作回滚货架的维护者，应重点检查近期生产部署集合。最新 3 个 Ready 生产部署仍受保护，但更早的已知稳定版本不会仅仅因为尚未满 30 天就自动安全。

自由职业者、代理机构或公司不应只用保留规则来判断是否升级。Hobby 仅限个人、非商业用途。商业项目即使未达到 10GB，也应使用 Pro；这次部署历史调整，只是再次凸显了原本就存在的套餐选择问题。

低于 10GB 的 Hobby 团队不会进入这次新增的即时清理路径，其部署仍遵循常规 30 天政策及相关例外。Pro 和 Enterprise 团队同样不受这项 Hobby 专属调整影响；它们默认的保留期限和受保护的近期部署数量都更高。

盘点真正不能丢的部署历史

先从团队层面着手。10GB 上限属于整个 Hobby 团队，但判断哪些部署有用的线索分散在各个项目中。

1. 1

   同时检查两项存储指标

   在 Vercel 中选择正确的团队，打开 Usage，再选择 Deployment Storage。同时查看 Deployment Storage 和 Functions Storage：前者涵盖构建产物与静态资源，后者涵盖函数包。分别打开每项指标下的 Projects，找出存储产物最多的项目。

2. 2

   列出绝对不能丢的部署

   逐一打开大型项目的 Deployments。记下当前生产部署、实际需要回滚到的生产版本、仍处于评审或审批流程中的预览 URL，以及审计或回归检查仍需使用的旧版本。这份清单才是需求，部署动态只是库存目录。

3. 3

   为每个保留项匹配保护条件

   检查每个必须保留的部署：它是否位列最新创建的 3 个部署、是否属于最新 3 个 Ready 生产部署、是否带有符合条件的别名，或是否为活跃分支的最新预览。同一部署如果同时出现在两个“最新三个”集合中，不要重复计算。

4. 4

   保住例外，或保住源文件

   只要仍需使用某个评审分支的最新预览，就让该分支保持活跃。如果工作流适合，可为必须保留的非生产部署设置自定义别名。其他情况则要确保重新构建所需的源代码提交、配置与外部数据已保存在部署历史之外。

5. 5

   删除已经没有用途的存储内容

   负责人确认哪些内容可以移除后，通过常规代码仓库流程删除过时的自定义别名，并关闭过时的拉取请求。随后检查最大部署的 Resources 视图，查找体积过大的静态产物或 Function 包。Usage 页面能定位项目，却不能指出究竟是哪个文件、部署或包推高了总量。

Vercel 的存储优化指南建议在调整后，对比同一团队、两项存储指标、同一批项目以及相同的 30 天区间。保留清理与缩小构建产物解决的是不同问题：前者会随时间减少已存历史，后者会让新的部署本身更小。

清理历史还是升级 Pro：Vercel 价格怎么算

对于个人、非商业项目，清理是无需订阅费的方案。你要舍弃已经没有实际用途的历史记录，尽可能缩小输出体积，并让用量保持在 Hobby 上限以内。代价体现在运维层面：可供检查的旧预览更少，可用于回滚的生产版本也更少。

Pro 并不是花 $0.10 就能完成的升级。Pro 的 Deployment Storage 和 Functions Storage 标价都是每 GB-月 $0.10，因此单项指标保留 10GB 整整一个月，标价为 $1。但套餐首先收取每月 $20 的平台费，其中包含一个部署席位，以及每月 $20 的基础设施用量抵扣额。每增加一个可部署的 Owner 或 Member 席位，每月还要再加 $20；Viewer 席位免费。

因此，正确的决策方式很直接：不要比较“删除历史”和“花 $1 买存储”，而要把清理与完整的每月 $20 套餐相比较，再计入每个额外部署者，并确认内含抵扣额能否覆盖团队实际的存储及其他基础设施用量。Vercel 价格完整拆解介绍了账单的其余组成部分。

对个人原型来说，每月 $20 可能不值得只为保存这些历史。对商业项目来说，套餐资格在保留规则之前就已经决定了答案。对本来就需要 Pro 的单开发者企业而言，更长的默认保留期和更多近期部署保护，本就是所购价值的一部分。

下周一该做什么

如果 Hobby 团队已经达到或接近 10GB，先打开 Usage 页面，找出占用 Deployment Storage 和 Functions Storage 最多的项目。然后标记仍承担业务或评审用途的具体预览链接与回滚目标，有意识地保护这些部署，其余没有用途的历史则可以清理。

如果团队用量明显低于 10GB，就不必紧急清理。但仍要记住常规 30 天政策，尤其是在关闭某个分支，而其预览仍有人需要使用时。

如果项目用于商业用途，就不要再把清理 Hobby 当作长期方案。预算应按完整的 Pro 费用计算，把部署权限留给真正需要的人，其余成员使用免费的 Viewer 席位，再将这笔账与重新构建缺失的评审或回滚工作流所需的成本比较。

如果想每周读一篇这样清晰直白的拆解，欢迎订阅 Newsletter。