corpusctl 对比 Payload：一款不在你前端之内的 CMS
Payload 加入了 Figma，新的 Cloud 部署已暂停，他们的 FAQ 说你最终会迁移。以下就是一个解耦替代方案的样子。
Payload 是这个类别中上升最快的名字，而且当之无愧。Google Trends 将 payload cms 标记为“headless CMS”的一个飙升（breakout）相关搜索词，它的 npm 包每月拉动数百万次下载，并拥有大约 44,000 个 GitHub star。
今年发生了两件事，应当纳入你的评估。
Payload 现已成为 Figma 的一部分——而 Cloud 已暂停
摘自 Payload 自己的 Cloud 页面，于 2026 年 8 月 17 日阅读：
Payload 已加入 Figma。 ……尽管新项目的部署目前已暂停，现有的 Cloud 项目将继续正常运行。
以及同一页面的 FAQ：
我需要迁移我的项目吗？ 是的，最终需要。不用着急，但我们正计划构建一个更好的东西，一旦它可用，你就能迁移过去。
该肯定的要肯定：这是一个难得直率的回答，发布在他们自己的网站上，而且他们承诺帮助企业客户完成迁移。没有人被误导。
但如果你是在本月选择一款 CMS，那么事实是：托管产品不再接受新项目，而现有的那个在未来会有一次迁移。Payload 这个开源项目不受影响，仍可在任何能运行 Next.js 应用的地方自托管。
一次收购是不是好消息，取决于你站在它的哪一边。Figma 的资源很可能会让 Payload 变得更好。它们也会让 Payload 的路线图服从于 Figma 的战略——而设计工具的战略，与内容基础设施的战略并不相同。
更深层的差异：Payload 住在你的应用之内
这是比任何收购都更长存的部分。
Payload 运行在你的 Next.js 应用之内。这是它核心的设计决策，也是其最佳特性的来源——一个完全跳过 HTTP 的本地 API，因为 CMS 和前端共享同一个进程。对于一个由单一团队维护的单个 Next.js 产品而言，这是一种真正出色的开发者体验，也是 Payload 正在赢得开发者的原因。
这也意味着你的 CMS 和你的网站共享一次部署、一个运行时和一个伸缩单位。公开站点上的一次流量高峰，就是你编辑人员正在使用的那个东西的一次流量高峰。前端重新构建就是 CMS 重新构建。更换前端框架不再是一个前端项目。