我在 Strapi CMS 上搭内容系统已经很多年了。但 2025 年 6 月 Figma 收购 Payload CMS 之后，我开始注意到它。接下来两个月里，我选用了 Payload CMS 来给一个基于 Next.js 的前端搭建内容系统。
这篇文章就是基于这两段实际使用经历，从功能、定制能力和定价方案几个方面，对比 Payload CMS v3 和 Strapi v5。
声明：我和 Payload 或 Strapi 的开发团队都没有任何关系。
如果你只想看结论，可以直接看下面这张表：
| 如果你想要 | 选它 |
|---|---|
| Payload CMS |
| Strapi |
1. 核心区别
Payload CMS 和 Strapi 想解决的问题，本质上就不一样。理解这个理念上的差异，能帮你更清楚地看到各自的强项和短板，从而选到真正适合自己需求的那个。
1.1. 开发者优先的框架 vs 编辑器友好的平台
Payload 的定位，是给开发者用来构建自己的内容系统或后端应用的框架，而不是一个开箱即用的、打磨好的 GUI 内容工具。数据模型和访问控制都必须用代码写。它的 Admin UI 只是一个默认前端，任何字段、视图或布局组件都能轻松用开发者自己的 React UI 代码覆盖。
Strapi 则更像一个传统的 headless CMS。它的管理面板允许内容编辑通过 Admin UI 定义 schema、创建组件、管理角色、设置权限。Strapi 的 Admin UI 也打磨得更精致，并且设计上并不鼓励你去覆盖它。它可以通过插件扩展，但整体上追求的是一个成品体验，而不是一个框架层。
1.2. 与 Next.js 集成的后端 vs 独立 headless CMS
Payload 安装在 Next.js 项目的 /app 目录里。也就是说，你的 Payload CMS 项目本身就是一个 Next.js 项目。因此，Payload CMS 可以部署在任何能托管 Next.js 项目的地方（Vercel、Cloudflare 等）。而且，对于基于 Next.js 的前端，CMS 和前端可以跑在同一个 Next.js 实例里。
Strapi 则是一个独立的 headless CMS，前端基于 React，后端基于 Node。它通过 REST API 或 GraphQL 把内容暴露给前端，部署方式跟传统的 Node 后端一样。
Payload 通过和 Next.js 的紧密集成、以及可组合的后端框架，给开发者很大的发挥空间；而 Strapi 通过打磨完善的管理界面，让内容编辑几乎不用技术团队插手，就能管理 schema 和权限。
2. 内容管理功能对比
搞清楚两者在根本方向上的差异之后，接下来对比它们在内容管理方面的具体功能：
2.1. 内容版本管理 Payload CMS ✅
对内容团队来说，能查看、对比和恢复某条记录的历史版本，往往是很关键的功能。在多个编辑协作处理内容的情况下，这一点尤其重要。
Payload CMS 和 Strapi 都支持保留记录的内容版本。但 Strapi 的内容版本功能（叫 Content History）有两个限制：
- 不会高亮显示两个版本之间的差异。
- Free 方案不可用。
相比之下，Payload CMS 的免费版就带内容版本功能，并且能高亮显示任意两个版本之间的改动。
两者都支持版本历史，但 Payload 所有方案都提供，并且能显示两个版本的可视化差异；Strapi 则把版本功能限制在付费方案里，也没有并排对比高亮。
2.2. 媒体上传 Payload CMS ✅
Payload 和 Strapi 都支持把媒体资源上传到各种存储服务（本地、AWS S3、Backblaze B2 等），也允许编写自定义上传 provider，来控制文件怎么存、存到哪。
Strapi 通过核心的 Media Library 插件处理上传。这个插件界面打磨得不错，还有 Folders 这种组织资源的功能。但如果想扩展媒体文件的 schema（比如给媒体项加自定义元数据字段），就得用一些变通办法，或者非平凡地覆盖插件 UI。
Payload 允许任何 collection 变成媒体上传相关的 collection（在那个 collection 的配置里指定 upload 配置即可）。这带来两个根本性的好处：
- 我们可以让媒体 collection 带任何需要的元数据字段，比如
altText、title、artist或copyrightInfo。 - 可以按需用不同的媒体 collection 来组织媒体资源，各自配不同的 schema、provider、上传规则等（比如文档、图片、视频分别用不同
upload配置的 collection）。
在上传能力和 provider 灵活性上，Strapi 和 Payload CMS 不分伯仲。但如果你需要给上传内容存自定义元数据，Payload 的 schema 驱动方式会更有优势。
2.3. 组件 / Group Fields Payload CMS ✅ Strapi ✅
Strapi 的组件或 Payload 的 group fields，都允许创建由多个字段组成的可复用字段结构，并在多个 collection 之间使用。比如一个 BlogPostAuthor 结构可以包含 ProfilePicture、Name 和 Bio 这几个字段，然后在 BlogPost 和 Article collection 里复用。
虽然两者都支持这个功能，但实现方式不同。Strapi 允许在 Admin UI 里定义和使用组件。Payload CMS 则要求 group fields 用 TypeScript 代码定义。这给开发者带来更强的类型安全，也能定义这些 group 在 Admin UI 里怎么显示、怎么行为。
两个平台也都支持嵌套结构（一个组件或 group field 里可以再包含另一个组件或 group field）。
Strapi 让编辑可以通过 UI 构建可复用组件，而 Payload 更看重强类型安全和开发者通过代码获得的灵活性。
2.4. Dynamic Zone / Blocks Field Payload CMS ✅ Strapi ✅
Dynamic zone 或 Blocks field 允许 collection 里有一个字段类型，可以包含差异很大的多种数据类型。比如 Webpage collection 可以有个 Body 字段，里面能放零个或多个 Image、Paragraph、Separator、Table、TwoColumnParagraph 等区块。这让内容团队能从一个 collection 构建出各种不同的网页，内容编辑既灵活又强大。
同样，Payload CMS 和 Strapi 对这个功能的支持都很扎实。区别在于方式：内容编辑可以通过 Strapi Admin UI 定义 Dynamic zone，而开发者可以在 Payload CMS 项目里定义 Blocks field。
在构建动态结构、让内容编辑更灵活强大这一点上，Strapi 和 Payload CMS 势均力敌。
2.5. 实时预览 Payload CMS ✅
内容编辑都希望能即时预览自己往 CMS 里填的内容输出效果。更顺畅的预览机制意味着更快的反馈循环，能省下不少时间。
Strapi 的 Live Preview 功能在 Free 方案里没有（只有 Growth 或更高方案才有）。相比之下，Payload CMS 的 Free 方案就包含预览。另外，Payload CMS 的预览比 Strapi CMS 更加即时（见下面的录屏）。
2.6. 内容翻译管理 Payload CMS ✅ Strapi ✅
Strapi 和 Payload CMS 都具备管理同一条记录多语言版本的能力。但它们的实现方式差异很大，也带来了明显的下游区别。
Strapi 通过核心插件 @strapi/plugin-i18n 支持多语言。这个插件给每个条目加一个 locale 字段，每条本地化记录都作为独立的数据库行存储。相比之下，Payload 把本地化原生集成进了 schema 系统。本地化是在字段级别配置的（不是 collection 级别），在字段定义里指定 localized: true 即可。Payload 不是把翻译存成独立记录，而是存在同一行里（比如 { greetings: { en: 'Hello', fr: 'Bonjour' } }）。
Strapi 的方式更适合翻译由不同人或不同团队负责的场景。Payload 的方式则更适合只需要本地化少数几个字段、其余字段在各语言间共享的需求，也适合所有语言版本都并排维护的编辑。
两者都支持多语言内容，但方式不同。Strapi 按语言存独立记录，适合不同人分别管理翻译的场景。Payload 在单条记录里本地化字段，更适合所有语言版本并排管理的编辑。
2.7. 用户管理 Strapi ✅
一个 CMS 通常要管理两类用户：一类是访问 Admin UI 管理内容的人，另一类是登录前端或应用、使用用户专属功能的人。
Strapi 内置了对这两类用户的支持。它开箱即用地提供了独立的管理员用户和应用用户体系，也允许给应用用户加自定义字段，用极简配置做服务端认证定制。
Payload 允许我们把任何 collection 通过指定 auth: true 变成用户 collection。所以我们可以创建 admin 和 customer 这样的 collection，并通过 Payload 配置对象限制 admin 用户的 Admin UI 访问。但给非管理员和管理员设置不同 access 需要初始的编码工作。相比之下，Strapi 可以直接在 Admin UI 里设置。
两者在用户管理能力上差不多。但 Strapi 内置的管理员和用户体系让搭建更快，Payload 则需要在代码里显式写访问规则。
2.8. 基于角色的 API 访问 Strapi ✅
Payload CMS 和 Strapi 都支持定义角色、设置基于角色的 API 访问权限。两者也都允许在代码里实现更细粒度的逻辑，比如只有请求带有效优惠码时，才返回 product_type 为 premium 的行。
在 Payload 里，访问控制完全在代码里定义，可以在 collection 或字段级别：
// 用 Payload CMS 定义字段级访问权限
{
name: 'editorNotes',
type: 'textarea',
access: {
read: ({ req }) => !!req.user && req.user.role === 'editor',
update: ({ req }) => !!req.user && req.user.role === 'editor',
},
}相比之下，Strapi 允许通过 Admin UI 定义基于角色的 API 访问，更细粒度的限制可以在代码里实现。
Payload 的纯代码模型给了开发者完全的控制权，但也意味着改访问规则需要开发者介入。或者，要构建动态 RBAC 系统，需要大量初始编码。相比之下，Strapi 的混合模型——常见情况用 UI，特殊情况用代码——更灵活，既适合内容团队也适合开发者。
两者都提供基于角色的 API 访问，但 Strapi 的 Admin UI 让内容团队能独立调整权限，减少对开发者的依赖，迭代更快。Payload 要实现类似能力，需要大量前期开发。
3. 定制能力对比
可定制的 CMS 能带来灵活性，让你围绕具体的编辑需求、审批流程和集成要求来塑造它。下面从这几个方面对比 Payload CMS 和 Strapi：
3.1. 定制 Admin UI Payload CMS ✅
定制 Admin UI，指的是扩展或覆盖默认 UI，改变它的外观或行为。
Strapi 允许通过插件和扩展来扩展 Admin UI。但要完全覆盖默认 UI，需要用自定义代码重新构建 Strapi 包。这很复杂，也难以维护。
Payload 则从设计上就考虑到了定制。它的 Admin UI 就是为了被覆盖而构建的，开发者可以通过代码控制任何字段或 collection 的显示和行为。它也支持通过插件扩展管理能力。
Strapi 的 Admin 通过插件容易扩展，但内置 UI 很难覆盖。Payload 的 Admin 从设计上就可定制，深度改 UI 更简单，也更好维护。
3.2. 定制 API Payload CMS ✅ Strapi ✅
定制 API，指的是覆盖默认 CRUD API 的行为，以及定义自定义 API 端点。
Payload 和 Strapi 都允许：
- 通过 Strapi 的 policy 或 Payload 的 access 函数设置基于代码的访问控制。
- 利用 Strapi 的 middleware 或 Payload 的 lifecycle hook 修改请求过滤条件或响应数据对象。
- 当上述方式不够用时，编写 Koa（Strapi）或 Express（Payload）中间件。
- 编写带自定义业务逻辑的自定义 API 路由，扩展 API 能力。
Payload CMS 和 Strapi 都允许覆盖默认 CRUD API 行为，也都能定义自定义 API 端点。
3.3. 与其他系统集成 Payload CMS ✅ Strapi ✅
CMS 常常需要把数据推送到其他系统（比如搜索索引或 Zapier），或者从外部来源（比如 IoT 传感器）接收数据。
Strapi 有针对 API 的 middleware、自定义 API 路由和 webhook 来支持集成。用 Payload CMS 的话，类似的集成可以通过 lifecycle hook 和 collection 专属的自定义 API 端点来搭建。
通过 lifecycle hook、自定义 API 端点和中间件，Payload CMS 和 Strapi 都能让 CMS 和其他系统集成。
3.4. 前端集成 Payload CMS ✅
一个内容系统由消费 CMS 数据的前端或应用组成。两者之间强集成能保证更快的开发、更简单的内容工作流和更容易的维护。
Strapi 是一个传统的基于 Node 的 headless CMS，通过 REST 或 GraphQL API 与前端集成。它也支持预览草稿内容和触发前端缓存失效。
Payload CMS 提供所有这些能力，并且和 Next.js 前端搭配时还有额外好处：
- 前端可以像普通函数一样调用 CMS API（比如
payload.find()），作为进程内 API 调用执行。这样写代码更简单，运行也更快（仅当 Next.js 前端跑在同一个 Node 进程里时）。 - CMS 的 TypeScript 类型自动在前端代码里可用（仅限使用 Next.js 的 monorepo 项目）。
Strapi 和 Payload 都能和前端顺畅集成，但 Payload 原生的 Next.js 基础，在搭配 Next.js 前端时能带来额外好处。
4. 其他方面对比
除了内容功能和定制能力，选择 CMS 框架时还有一些因素要考虑。下面逐一评估：
4.1. 流行度和生态成熟度 Strapi ✅
评估 CMS 框架时，流行度很重要。它意味着更强的社区支持、更多第三方插件、更成熟的生态和更少的边缘问题。
npm 包下载量
截至 2025 年 10 月，Payload 和 Strapi 的 npm 下载量不相上下。但过去六个月里，Payload 呈现出更强的上升趋势，说明接下来几个月还会保持势头。
GitHub stars
截至 2025 年 10 月，@strapi/strapi 仓库有 7 万 stars，而 payloadcms/payload 仓库有 3.8 万，主要是因为 Strapi 起步比 Payload CMS 早很多。
社区插件
Strapi 的插件生态更强，市场里大约有 350 个插件，而 Payload CMS 有 130 个社区插件。
总体来看，Strapi 仍然是更流行的 CMS，主要因为它存在时间更长、生态更成熟。但 Payload 加速增长的 adoption 曲线说明，它可能很快成为主流选择。
截至 2025 年 10 月，Strapi 看起来更流行，社区生态也更广。但 Payload 的快速增长趋势说明它的采用曲线在上升，未来可能更受欢迎。
4.2. 托管选项 Payload CMS ✅ Strapi ✅
Strapi 可以自托管在任何支持 Node.js 后端的平台上，包括 Render、Railway 这类托管服务商，以及 AWS EC2、Hetzner 这类 VPS。它也提供 Strapi Cloud（商业用途只有付费方案），一个托管方案，负责 CMS、数据库、媒体存储以及 dev、staging、production 等多环境。
Payload 则没有自己的托管云，必须自托管，这意味着团队要自己管理独立的存储和数据库托管，以及部署环境。不过 Payload 的自托管选项很丰富：
- 除了 Node.js 兼容平台，Payload 还能托管在 Vercel、Netlify、Cloudflare 这类前端托管平台，这些平台有慷慨的免费额度。
- Payload 团队提供 starter template，方便在 Vercel 和 Cloudflare 上快速部署。
- 当前端基于 Next.js 时，Payload 和前端可以托管在同一个实例里，降低基础设施复杂度。
Payload 的自托管灵活性让它很适合想要控制权和低成本部署方案的团队。Strapi 则同时提供托管云和自托管，更适合想完全把托管、数据库和 CMS 环境都外包出去的团队。
4.3. 定价方案 Payload CMS ✅ Strapi ✅
Payload 的免费方案开箱即用，功能更完整。它包含内容版本和实时预览这类高级内容功能，而 Strapi 的免费版没有这些。
另一方面，Strapi 的 Growth 方案定价远低于企业级，包含单点登录（SSO）和基于 AI 的内容建模等功能。相比之下，Payload 要从免费方案直接跳到企业级才能用 SSO 和 AI 功能。
Payload 的免费方案免费提供更多功能，而 Strapi 定价合理的付费档让 SSO 这类高级功能更容易获得，不用直接跳到企业级价格。
5. 结论
基于上面的对比，不同的优先级会把团队导向不同的 headless CMS。下面这个简洁的总结可以帮你做决定：
| 如果你是 | 那么 |
|---|---|
| 以开发者为主、看重灵活性的团队 | Payload 基于代码、Next.js 原生的方式，让你能直接用 TypeScript 塑造一切。 |
| 以内容为主、希望初始编码工作最少的团队 | Strapi 打磨完善的 Admin UI 和成熟的插件生态，让你能自助管理 schema、权限和工作流，对 |
暂无评论内容