你的客户在三月份批准了 Contentful。到了八月份，你的开发团队在 Slack 里讨论要把它拔掉。从 2022 年以来，我已经在 40 多个项目中交付了使用 Contentful、Sanity 和 Payload 的生产构建——有些是全新的 Next.js 应用，有些是从胶带和祈祷勉强维持的 WordPress 安装中救出来的。每个 CMS 都以不同的、昂贵的方式失败了。Contentful 的 API 限制在周二凌晨 6 点扼杀了一个产品发布。Sanity 的 GROQ 学习曲线让一个市场营销团队停滞了两个 sprint。Payload 的自托管账单让一个种子轮创始人惊讶不已，他以为"开源"意味着"免费"。有一个选择一致地导致了比其他选择更少的凌晨 2 点 Slack 通知。

本文在真正重要的维度上分解了 Contentful、Sanity 和 Payload CMS：按规模计费、开发人员在实战中的体验、内容建模灵活性、API 设计，以及你的内容团队每天要么喜欢要么讨厌的日常编辑工作流。

目录

Contentful vs Sanity vs Payload：无头 CMS 对比 2026

30 秒概览

Contentful 是现任者。它从 2013 年开始就存在，为大规模企业网站提供支持。它是精致、可靠和昂贵的。

Sanity 是开发者宠儿，具有实时、结构化内容方法和可定制的工作室。它功能强大，但有学习曲线，定价模式可能会让你惊讶。

Payload 是一个悄悄成为认真竞争者的后起之秀。它是开源的，默认自托管（现在还有云选项），用 TypeScript 编写，收取零许可费。Payload 3.0 通过完全基于 Next.js 的重写发布，它完全改变了等式。

功能 Contentful Sanity Payload
类型 SaaS SaaS（自托管工作室） 开源/自托管
语言 无（仅 API） JavaScript/React TypeScript/Next.js
许可费 是 是（基于使用） 无（MIT）
GraphQL 是 是（首选 GROQ） 是（自动生成）
REST API 是 是 是（自动生成）
实时协作 有限 优秀 好（2.0+）
自托管 否 仅工作室 完整堆栈
数据库 专有 专有 MongoDB 或 Postgres

定价分解：你实际会支付的费用

现在是真正重要的部分了。定价是我见过团队在项目中期切换 CMS 的首要原因，也是人们在评估期间最容易低估的一件事。

Contentful 定价（2026）

Contentful 的免费层给你 1 个空间、5 个用户和 25K 个 API 调用。这对博客来说不错。

基础计划从每月 $300 开始，给你更多的环境和角色。高级计划——这是大多数认真的团队需要的——是定制定价的，但通常对中等规模的组织来说从每月 $2,000-$3,000 开始。我见过企业合同超过 $80K/年。

最狡猾的地方是：API 调用超额。Contentful 对内容分发 API 调用、内容管理 API 调用和资产带宽分别收费。在月浏览量 10M+ 的高流量网站上，你可以轻易超过包含的配额。我合作过的一个客户在病毒式产品发布后，月账单从 $2,500 跳到 $4,800，原因是他们没有预见到的 CDN 和 API 超额。

Sanity 定价（2026）

Sanity 使用基于使用的模式，他们称之为"随增长而付费"。免费计划包括 3 个非管理员用户、500K 个 API 请求、20GB 带宽和 10GB 存储。对于入门来说很慷慨。

增长计划是每个用户每月 $15 加上使用超额。企业计划是定制定价的。

关于 Sanity 定价中让人头疼的事情是：GROQ 查询和 API CDN 请求是计量的，成本随着你的内容复杂性而扩展。单个提取深度嵌套、引用内容的 GROQ 查询消耗的配额可能比你预期的要多。Sanity 在这里改进了透明度，但我仍然建议团队尽早设置预算警报。

典型的中等规模项目成本：每月 $200-$800 取决于团队规模和流量。

Payload 定价（2026）

Payload 采用 MIT 许可证。CMS 本身成本是**$0**。永远。没有按座位计费，没有 API 调用计量，没有 Payload 的带宽费用。

你的成本是基础设施：托管 Node.js 应用和数据库。在 Railway、Render 或基本的 AWS/DigitalOcean 设置上，大多数项目你在看每月 $20-$100。即使是大规模部署，在 AWS RDS 上使用托管 Postgres、适当规模的 EC2 或 ECS 以及前面的 CloudFront，很少超过每月 $300-$500——那是针对认真的流量。

Payload Cloud（他们托管的产品）从每月 $50 开始，计划根据存储和带宽扩展，但它完全是可选的。

场景 Contentful Sanity Payload（自托管）
独立开发者，小网站 $0（免费层） $0（免费层） $20-40/月（托管）
5 人团队，中等流量 $300-500/月 $200-400/月 $50-100/月（托管）
10 人团队，高流量 $2,000-4,000/月 $500-1,500/月 $150-400/月（托管）
企业，50+ 编辑 $5,000-10,000+/月 $2,000-5,000/月 $300-800/月（托管）

定价故事是明确的。Payload 在每个层级都赢了。

开发人员体验

定价让人进门。开发人员体验让他们留下来——或把他们赶走。

Contentful DX

Contentful 的开发人员体验是……还不错。他们的 SDK 支持很广泛（JavaScript、Python、Ruby、Java、Swift 等），文档是成熟的，REST 和 GraphQL API 有很好的文档。

但这里让我沮丧的是：一切都通过网络 UI 配置。内容类型、字段、验证——这一切都在浏览器中点点点。是的，你可以使用 Contentful CLI 和迁移脚本来版本控制你的架构，但它感觉像是匆忙拼凑的。它不是代码优先的；它是 UI 优先的，有一个代码逃生舱。

迁移工具已通过他们的 contentful-migration 包改进，但与在 TypeScript 中定义你的架构并获得即时类型安全相比？它感觉像是落后了一代。

Sanity DX

Sanity 的开发人员体验在许多方面确实非常出色。架构是在 JavaScript/TypeScript 文件中定义的。工作室是一个你可以广泛定制的 React 应用——自定义输入组件、自定义视图、工作流插件。

GROQ，他们的查询语言，一旦你学会它就很强大。但"一旦你学会它"在这句话中做了很多繁重的工作。GROQ 不是 SQL。它不是 GraphQL。它是它自己的东西，你团队中的每个新开发者都需要学习它。我见过初级开发者为 GROQ 投影努力了数周。

// GROQ 查询 - 功能强大但语法独特
*[_type == "post" && publishedAt < now()] | order(publishedAt desc) [0...10] {
  title,
  slug,
  "author": author->{ name, image },
  "categories": categories[]->{ title, slug },
  body[] {
    ...,
    _type == "image" => {
      "url": asset->url
    }
  }
}

Sanity 的实时功能不过是令人难以置信的。多个编辑在同一个文档上工作，有存在指示器，没有保存冲突——它就是有效。内容湖架构以竞争对手无法匹配的方式启用了这一点。

Payload DX

Payload 3.0 改变了一切。建立在 Next.js 上，完全用 TypeScript 编写，你的配置文件是唯一的真实来源。你在代码中定义集合、字段、钩子、访问控制和自定义端点。

这是一个典型的 Payload 集合的样子：

import { CollectionConfig } from 'payload'

export const Posts: CollectionConfig = {
  slug: 'posts',
  admin: {
    useAsTitle: 'title',
    defaultColumns: ['title', 'status', 'publishedAt'],
  },
  access: {
    read: () => true,
    create: ({ req: { user } }) => Boolean(user),
    update: ({ req: { user } }) => Boolean(user),
    delete: ({ req: { user } }) => user?.role === 'admin',
  },
  fields: [
    {
      name: 'title',
      type: 'text',
      required: true,
    },
    {
      name: 'content',
      type: 'richText',
    },
    {
      name: 'author',
      type: 'relationship',
      relationTo: 'users',
    },
    {
      name: 'status',
      type: 'select',
      options: ['draft', 'published'],
      defaultValue: 'draft',
    },
    {
      name: 'publishedAt',
      type: 'date',
      admin: {
        position: 'sidebar',
      },
    },
  ],
  hooks: {
    beforeChange: [
      ({ data, operation }) => {
        if (operation === 'create') {
          data.publishedAt = new Date()
        }
        return data
      },
    ],
  },
}

一切都是有类型的。你的 IDE 会自动完成字段名。钩子给你生命周期控制。访问控制作为函数定义在字段旁边，不是在某个单独的权限 UI 中。而且因为它只是一个 Next.js 应用，你可以添加自定义页面、API 路由或服务器操作到你的 CMS 代码中。

对于做 Next.js 开发的团队来说，从开发人员体验的角度来看，Payload 3.0 是显而易见的选择。你的 CMS 和前端住在同一个项目中。同一部署。同一个仓库。

Contentful vs Sanity vs Payload：无头 CMS 对比 2026 - 架构

内容建模

内容建模是你要么为成功做准备，要么为多年的噩梦做准备的地方。

Contentful 的方法

Contentful 使用传统的内容类型 → 条目模型。你定义有字段的内容类型，编辑创建条目。内容类型之间的引用是显式的。它对直接的内容结构很有效。

限制出现在富文本中。Contentful 的富文本字段将内容存储为结构化的 JSON 树，这对渲染灵活性很好，但建模具有嵌套组件的复杂页面布局需要创意使用嵌入式条目和引用。它可能变得很麻烦。

Contentful 在基础计划上支持 50 个内容类型，在高级计划上支持 100+。对于具有许多内容类型的大型网站，这可能成为约束。

Sanity 的方法

Sanity 的内容建模可能是三者中最灵活的。他们的块内容（Portable Text）是富文本的开放规范，将内容存储为结构化数据。你可以定义自定义块类型、内联对象和注解。

架构系统支持深度嵌套的对象类型、条件字段和自定义验证。我在 Sanity 中建立了一些真正复杂的内容模型，在 Contentful 中会很痛苦。

// Sanity 架构，带有 Portable Text 定制
export default {
  name: 'post',
  type: 'document',
  fields: [
    {
      name: 'body',
      type: 'array',
      of: [
        { type: 'block',
          marks: {
            annotations: [
              { name: 'internalLink', type: 'object',
                fields: [{ name: 'reference', type: 'reference', to: [{ type: 'post' }] }]
              }
            ]
          }
        },
        { type: 'image', options: { hotspot: true } },
        { type: 'codeBlock' },
        { type: 'callout' },
      ]
    }
  ]
}

Payload 的方法

Payload 的内容建模位于 Contentful 的结构化简单性和 Sanity 的自由形式灵活性之间——但完全在 TypeScript 中的优势。

Payload 的块字段对于页面构建特别强大。你定义块类型，每个都有自己的字段，编辑可以从这些块组成页面。结合布局字段类型和条件逻辑，你可以建模几乎任何东西。

Payload 3.0 的 Lexical 富文本编辑器是一个突出的地方。它用现代编辑器取代了 Slate（这是可以的，但正在老化），支持自定义节点、内联块和开箱即用的服务器端渲染。你可以直接在富文本内容中嵌入 React 组件。

版本控制系统值得一提。Payload 给你草稿/发布工作流和完整的文档版本历史与差异比较。这是内置的，不是付费附加服务。

APIs：REST、GraphQL 及其他

Contentful APIs

Contentful 为分发（CDN 缓存，只读）、预览（非缓存，草稿内容）、管理（CRUD）和图像提供了单独的 API。分离是合理的，但这意味着你在玩多个 API 令牌和基础 URL。

他们的 GraphQL API 是坚实的，但有深度限制和速率限制，在建模深度引用内容时会令人沮丧。复杂的查询可能需要多次往返。

Sanity APIs

Sanity 的主要查询语言是 GROQ，通过 HTTP 提供。他们确实提供 GraphQL API，但它是单独部署的，感觉像是二等公民。对于大多数 Sanity 用例，GROQ 无论如何都更强大。

真正的魔力是 Sanity 的实时监听器 API。你可以订阅对任何查询的更改并获得即时更新。这启用了真正令人印象深刻的实时预览体验。

Payload APIs

Payload 从你的集合配置自动生成 REST 和 GraphQL API。无需额外设置。定义一个集合，立即获得两种 REST 和 GraphQL 的完整 CRUD 端点。

# 自动生成的 GraphQL 查询
query {
  Posts(where: { status: { equals: published } }, sort: "-publishedAt", limit: 10) {
    docs {
      id
      title
      content
      author {
        name
      }
      publishedAt
    }
    totalDocs
    hasNextPage
  }
}

但这是 Payload 具有独特优势的地方：因为它在与你的 Next.js 应用相同的进程中运行，你可以跳过 API，使用 Payload 的本地 API进行服务器端数据获取。直接数据库查询，具有相同的访问控制、钩子和验证——但零 HTTP 开销。

// 本地 API - 无 HTTP，无序列化开销
const posts = await payload.find({
  collection: 'posts',
  where: { status: { equals: 'published' } },
  sort: '-publishedAt',
  limit: 10,
})

这对服务器渲染页面来说是一个巨大的性能胜利。没有网络往返到 CMS API。只是一个函数调用。

编辑体验

开发者选择 CMS，但编辑每天都在其中生活。忽视他们的体验需要付出代价。

Contentful 拥有最成熟的编辑 UI。它清洁、可预测，你的非技术团队会迅速掌握它。高级计划中的调度、工作流和批准链是坚实的。然而，它可能感觉有些刻板——定制编辑界面需要构建一个 Contentful 应用，这是一个完全独立的 React 应用。

Sanity Studio 是最可定制的。你可以构建完全定制的编辑体验。但这种定制付出了代价：开箱即用，Sanity Studio 对非技术编辑来说可能感觉压倒性。结构构建器需要开发者时间来配置良好。

Payload 的管理面板在 3.0 中有了巨大改进。它清洁、快速（它是一个 Next.js 应用），支持自定义组件、条件字段渲染和实时预览。它不如 Contentful 的 UI 精致，但它更可定制，比 Contentful 的工作量更少，而且比 Sanity 对编辑更容易接近。

自托管 vs SaaS：真实的权衡

这是哲学分歧。Contentful 和 Sanity 是 SaaS 平台。你不管理基础设施；你付钱让他们做。Payload 默认自托管。

SaaS 的理由：更少的运营开销、内置 CDN、托管的正常运行时间。这些是真实的优势，特别是对于没有 DevOps 经验的小团队。

自托管的理由：数据所有权、无供应商锁定、可预测的成本、监管合规性（GDPR、HIPAA、数据驻留），以及自由定制任何东西。

对于像我们这样做无头 CMS 开发的机构来说，自托管已成为 2026 年大多数客户的建议。基础设施工具已成熟到可以在 Railway、Vercel 或 AWS 上部署 Payload 应用很简单。Docker 使其可重现。基础设施成本随着时间推移相比于 SaaS CMS 的节省是复利的。

如果你担心运维负担，Payload Cloud 可以为你处理托管，同时保持开源的优势。

性能和可扩展性

Contentful 的 CDN 支持的分发 API 很快。典型响应时间是从边缘节点的 50-100ms。它在规模上已被十年来激烈的战斗考验。

Sanity 的 CDN API 为缓存内容提供类似的性能，他们的实时层为实时查询增加了大约 20-30ms。

Payload 的性能取决于你的基础设施，但这里是一件事——当你使用本地 API 与 Next.js 服务器组件时，你在对本地数据库做函数调用。响应时间可以在 10ms 以下。在你的 Next.js 输出前面添加 CDN（Vercel、CloudFront 等），你匹配或击败 SaaS 选项。

对于基于 Astro 的项目，所有三个都作为 API 源很好用，但 Payload 的 REST 和 GraphQL API 在 Astro 的数据获取层中特别容易使用。

生态系统和社区

Contentful 拥有最大的企业生态系统。大量的集成、一个应用商场和广泛的机构支持。

Sanity 有一个热情的开发者社区、出色的文档和一个不断增长的插件生态系统。他们的社区 Slack 是真正有帮助的。

Payload 是三者中社区增长最快的。他们的 Discord 非常活跃，核心团队定期回答问题。插件生态系统较小但增长迅速——而且因为 Payload 只是 Node.js/TypeScript，你可以 npm install 任何你需要的东西。

Payload 的 GitHub 截至 2026 年初有超过 30K 颗星，轨迹是陡峭的。

判决

我会直言不讳：Payload 是 2026 年大多数项目中最好的无头 CMS。

原因如下：

  1. 任何规模零许可费。你的 50 编辑企业团队不向 Payload 支付一分钱。
  2. TypeScript 原生配置意味着你的内容模型是代码，版本控制，类型安全，在 PR 中可审查。
  3. 本地 API + Next.js 集成给你 SaaS CMS 物理上无法匹配的性能。
  4. 数据所有权——你的内容住在你的数据库中，不是别人的专有存储中。
  5. 无供应商锁定——如果你想切换出去，你的数据在 Postgres 或 MongoDB 中。只需查询它。

有些情景下其他的赢了：

  • 选择 Contentful 如果你是一个大企业，有一个既定的内容团队，需要一个精致的、零运维的编辑体验，并且有预算。
  • 选择 Sanity 如果实时协作对你的工作流至关重要，你需要 Portable Text 无与伦比的结构化富文本，或者你在构建一个高度定制的工作室体验。
  • 选择 Payload 对于其他一切。初创公司、机构、中型公司、开发者领导的团队、需要数据控制的受监管行业，以及任何不想为惊喜账单而醒来的人。

如果你在评估一个新项目的无头 CMS，并且想讨论细节，我们很乐意帮忙。我们已经交付生产 Payload、Sanity 和 Contentful 项目，可以根据你的实际需求和预算给你诚实的建议。

常见问题

Payload CMS 真的免费吗？

是的。Payload 是 MIT 许可的开源软件。没有许可费、按用户费用或 Payload 的 API 调用限制。你的唯一成本是托管基础设施（服务器和数据库），这通常运行 20-500 美元/月，取决于规模。Payload Cloud 可用作付费托管选项，如果你不想管理基础设施。

Sanity 可以自托管吗？

部分可以。Sanity Studio（管理 UI）是一个 React 应用，你可以在任何地方部署。然而，内容湖——你的实际数据所在的地方——是由 Sanity 管理的托管服务。你不能自托管数据层。这意味着你的内容总是住在 Sanity 的基础设施上，这可能是数据驻留或合规性需求的问题。

哪个无头 CMS 有最好的 GraphQL 支持？

Contentful 和 Payload 都提供强大的 GraphQL API。Payload 从你的集合配置直接自动生成其 GraphQL 架构，这意味着零手动架构维护。Contentful 的 GraphQL API 是成熟的并有很好的文档。Sanity 提供 GraphQL 但更喜欢 GROQ 作为其主要查询语言，他们的 GraphQL 实现不支持所有 GROQ 功能。

Contentful 在 2026 年值得这个价格吗？

对于具有复杂内容操作、现有 Contentful 工作流和重视不用动手的 SaaS 方法的大企业——是的，它可以值得。对于小到中型团队，当 Payload 以一小部分价格提供可比（以及在某些方面优越）的功能时，成本越来越难以合理化。我们看到多个客户专门因成本而从 Contentful 迁移出去。

Payload CMS 如何处理图像优化？

Payload 有内置的图像调整大小和焦点裁剪。当你上传图像时，Payload 可以根据你的配置自动生成多个尺寸。在 Payload 3.0 与 Next.js 中，你可以将此与 Next.js Image 优化相结合，用于响应式、WebP/AVIF 提供。它不如 Contentful 的图像 API 功能丰富（提供基于 URL 的转换），但它涵盖 90% 的用例，无需第三方服务。

我能从 Contentful 迁移到 Payload 吗？

是的。由于 Payload 使用标准数据库（Postgres 或 MongoDB），迁移涉及通过他们的管理 API 从 Contentful 导出你的内容并将其导入到 Payload 集合中。从 Contentful 内容类型到 Payload 集合的内容建模转换通常是直接的。我们处理过几次这样的迁移——最棘手的部分通常是富文本转换，不是结构化数据。

哪个 CMS 最适合非技术编辑？

Contentful 对非技术用户有最直观的开箱即用编辑体验。Payload 的管理面板是第二名，正在快速改进。如果开发者投入时间定制它，Sanity Studio 可以是三者中最好的，但默认体验对编辑来说有更陡峭的学习曲线。

Payload CMS 是否可以与 Next.js 以外的框架一起使用？

绝对地。虽然 Payload 3.0 使用 Next.js 作为其管理 UI 框架，REST 和 GraphQL API 可以与任何前端一起工作——Astro、Nuxt、SvelteKit、Remix，甚至移动应用。本地 API 是 Next.js 特定的，但外部 API 没有框架依赖。我们根据项目需求定期将 Payload 与 Next.js 和 Astro 配对。