我花四年时间在 Hygraph（曾经的 GraphCMS）和 Contentful 上构建生产应用

我曾在凌晨 2 点处理过部署故障，与内容团队就建模决策进行过激烈讨论，并见证了两个平台的重大演进。这不是表面的功能清单——这是我在两个平台上真正交付实际项目后的真实想法。

如果你在 2026 年为企业项目评估这两个平台，你问的是正确的问题。它们是两个最成熟的无头 CMS 选项，都具有强大的 GraphQL 支持，但它们以不同的方式解决问题。让我带你了解每个平台的优势和可能令你感到沮丧的地方。

目录

• 2026 年企业级无头 CMS 现状
• 架构和 API 哲学
• 内容建模对比
• GraphQL 实现深度分析
• 企业团队价格详解
• 开发者体验和 SDK 质量
• 内容联合和多源数据
• 编辑体验和工作流
• 性能和全球交付
• 集成和生态
• 何时选择哪个
• 常见问题

2026 年企业级无头 CMS 现状

无头 CMS 市场已经整合了不少。Contentful 融资 1.75 亿美元，并公开表示针对企业交易。Hygraph（2022 年从 GraphCMS 重新品牌）已经开辟了一个强大的利基市场——"GraphQL 原生"选项，并在 2024 年底完成了 B 轮融资。两个平台都已大幅成熟其企业级产品。

过去一年发生了什么变化？Contentful 推出了新的 Contentful Studio（一个可视化编辑层）并改革了其应用框架。Hygraph 加倍投入内容联合——它们从外部 API 拉取数据并将其视为原生 CMS 内容的能力——并推出了改进的基于角色的访问控制。

市场本身也发生了变化。Vercel 的收购举措、Sanity 的持续增长以及可组合 DXP 架构的兴起，推动了 Hygraph 和 Contentful 进行更加差异化的竞争。如果你正在使用 Next.js 或 Astro 构建（考虑到你在 socialanimal.dev 上阅读这篇文章，有很大的可能性），两者都是不错的选择。但魔鬼藏在细节中。

架构和 API 哲学

这是基本差异所在的地方。

Contentful 是以 REST 优先构建的。他们的内容交付 API 和内容管理 API 原本是 REST，他们在顶部添加了 GraphQL 作为额外的层。这是很好的 GraphQL——别误会我——但这不是系统从一开始就设计的方式。你可以在边界情况中感受到这一点：某些在 REST 中完全有效的过滤操作在 GraphQL 中需要解决方案，GraphQL API 在功能方面与 REST 相比一直滞后。

Hygraph 从一开始就是 GraphQL 原生构建的。每一条内容、每一个资产、每一个关系——一切都通过单一 GraphQL 端点传输。他们的 schema 是从你的内容模型自动生成的，感觉很自然。变更、查询、订阅——所有这些都无需任何阻抗失配。

以下是这在实践中意味着什么：

# Hygraph - 过滤和排序感觉很自然
query {
  articles(
    where: { category: { slug: "engineering" }, publishedAt_gt: "2026-01-01" }
    orderBy: publishedAt_DESC
    first: 10
  ) {
    id
    title
    slug
    author {
      name
      avatar {
        url(transformation: { image: { resize: { width: 200 } } })
      }
    }
  }
}

# Contentful GraphQL - 类似的查询，略有不同的符号
query {
  articleCollection(
    where: {
      category: { slug: "engineering" }
      publishedAt_gt: "2026-01-01"
    }
    order: publishedAt_DESC
    limit: 10
  ) {
    items {
      sys { id }
      title
      slug
      author {
        name
        avatarCollection {
          items {
            url(transform: { width: 200 })
          }
        }
      }
    }
  }
}

注意 Contentful 中的 Collection 后缀和 items 包装。这不是致命问题，但当你在大型应用程序中编写数十个查询时，Hygraph 更简洁的 schema 确实更好用。

内容建模对比

两个平台都支持你期望的核心原语：文本、富文本、数字、布尔值、日期、JSON、引用、资产和枚举。

功能	Hygraph	Contentful
内容类型限制（企业版）	无限	每个 space 200 个
每个内容类型的字段数	500	50
支持的区域设置	最多 50 个	最多 50 个（企业版）
富文本格式	自定义 AST + Slate 基础	结构化富文本（自定义 AST）
组件/块	是（可重用组件）	是（嵌入条目）
联合类型	原生 GraphQL 联合	通过内容类型引用
条件字段	是（可见性条件）	通过应用框架扩展
字段验证	内置 + 正则表达式	内置 + 正则表达式 + 自定义应用
环境	是（多阶段）	是（环境别名）
计划发布	是	是

Contentful 中每个内容类型的 50 字段限制会让人意外。如果你正在建模复杂的产品数据或多部分登陆页面，你会遇到这个瓶颈。解决方案是将内容分解为更小的、关联的类型，这实际上是更好的架构——但这是一个强制的约束而不是一个选择。

Hygraph 的组件系统特别值得一提。你可以定义可重用的组件 schema 并将其嵌入到内容类型中。把它看作一个嵌套的、有类型的 JSON 字段，它有自己的 schema 定义。这对于构建灵活的页面构建器非常有用，编辑可以从预定义的块中组合部分。Contentful 用富文本中的嵌入条目实现了类似的功能，但这是一个不同的思维模式。

富文本处理

说实话，这是两个平台上的痛点。无头 CMS 中的富文本本质上是复杂的，因为你存储的是结构化内容，需要在任何前端中呈现。

Contentful 的富文本返回一个 JSON AST，你用他们的 @contentful/rich-text-react-renderer 包来呈现。它可以工作，但呈现嵌入条目（如内联产品卡或 CTA）需要自定义节点解析器，这可能会变得冗长。

Hygraph 的富文本也是基于 AST 的，需要类似的呈现方法。他们提供 @graphcms/rich-text-react-renderer。两者都很好用。都不是特别优雅。这就是无头富文本的本质。

GraphQL 实现深度分析

让我们具体讨论 GraphQL API，因为这是这个比较的重点。

查询复杂性和速率限制

Contentful 对 GraphQL 查询应用复杂性分数。截至 2026 年，限制是每个查询 11,000 个复杂性点。深度嵌套的查询带有多个 Collection 扩展可能会达到此限制。他们的速率限制在企业计划的交付 API 上设置为每秒 55 个请求。

Hygraph 使用类似的复杂性评分系统。他们的企业层允许可配置的速率限制，通常从每秒 100 个请求开始。他们还在边缘支持查询缓存，这意味着重复的查询从缓存服务，不计入你的限制。

订阅

Hygraph 开箱即用地支持 GraphQL 订阅，用于实时内容更新。如果你正在构建需要实时内容刷新的东西——比如仪表板、实时事件页面、协作工具——这是很重要的。

Contentful 不支持 GraphQL 订阅。你会使用 webhook 加实时层（如 Pusher 或 Ably）来实现类似的功能。它有效，但需要更多基础设施来管理。

变更

Hygraph 通过他们的 GraphQL API（在管理端点上）公开内容变更。你可以使用相同的 GraphQL 工具以编程方式创建、更新和删除内容，就像你用于查询一样。

Contentful 的 GraphQL API 是只读的。所有写操作通过基于 REST 的内容管理 API 进行。这意味着如果你需要读取和写入操作，你的代码库最终会有两个不同的 API 客户端。

// Contentful - 读/写的两个不同客户端
import { createClient } from 'contentful';
import { createClient as createManagementClient } from 'contentful-management';

const deliveryClient = createClient({
  space: process.env.CONTENTFUL_SPACE_ID,
  accessToken: process.env.CONTENTFUL_DELIVERY_TOKEN,
});

const managementClient = createManagementClient({
  accessToken: process.env.CONTENTFUL_MANAGEMENT_TOKEN,
});

// Hygraph - 单个 GraphQL 客户端用于一切
import { GraphQLClient } from 'graphql-request';

const hygraph = new GraphQLClient(process.env.HYGRAPH_ENDPOINT, {
  headers: {
    Authorization: `Bearer ${process.env.HYGRAPH_TOKEN}`,
  },
});

企业团队价格详解

让我们谈谈金钱。两个平台都已向高端市场转移，价格也相应反映了这一点。

计划层级	Hygraph（2026）	Contentful（2026）
免费/社区	$0（2 个座位，每月 1M API 调用）	$0（1 个 space，5 个用户）
专业版	起价约 $399/月	起价约 $489/月
企业版	自定义（通常 $2,500-15,000/月）	自定义（通常 $3,500-25,000+/月）
API 调用包含（企业版）	10M-100M+	5M-50M+
资产存储（企业版）	500GB+	250GB+
环境	按计划多个	多个（企业前成本额外）

这些是基于公开价格和我在提案中看到的范围的近似值。你的实际报价会根据座位、API 量和支持层级而不同。

Contentful 通常更昂贵，特别是在规模化时。他们的 API 调用超额费用可能会让你吃惊——我见过团队因为配置不当的 ISR 设置进行过多 API 调用而被收取 $2,000+ 的超额费用。Hygraph 的定价对 API 量更加宽松，他们的缓存层意味着更少的调用接触源服务器。

值得注意的一点是：Contentful 的企业合同往往是年度合同，需要大量承诺。根据我的经验，Hygraph 在较大交易中提供更灵活的条款，尽管他们也在推动年度合同。

开发者体验和 SDK 质量

Contentful 已经存在更长时间，这在 SDK 中显而易见。他们的 SDK 生态系统更成熟：

• 8+ 种语言的官方 SDK
• contentful.js 用于交付，contentful-management.js 用于管理
• 带有 cf-content-types-generator 的出色 TypeScript 代码生成
• React、Vue 和原生 JS 的富文本渲染器
• Contentful CLI 用于迁移和 space 管理

Hygraph 已经赶上来，但仍有差距：

• 主要关注 JavaScript/TypeScript SDK
• graphql-request 或任何 GraphQL 客户端都可以工作（不需要特定于供应商的 SDK）
• 通过 GraphQL 代码生成器的 TypeScript 代码生成（不是 Hygraph 特有的，但完美适用）
• 管理 API SDK 较新，测试不足
• CLI 工具用于 schema 迁移可用但不那么成熟

不过关键的是——因为 Hygraph 只是标准 GraphQL，你实际上不需要他们的 SDK。你可以使用 urql、Apollo Client、graphql-request 或任何 GraphQL 客户端。schema 是自文档化的。如果你的团队已经有 GraphQL 经验，这实际上是一个优势。

对于使用 Next.js 或 Astro 构建的团队，两个 CMS 平台都集成得很好。我们在 Social Animal 上在两个平台上交付了项目，DX 差异是显著的但不是戏剧性的。

内容迁移

Contentful 的迁移工具是同类中最好的。他们的脚本迁移让你对内容模型变更进行版本控制：

// Contentful 迁移脚本
module.exports = function (migration) {
  const blogPost = migration.createContentType('blogPost')
    .name('Blog Post')
    .description('A blog post');

  blogPost.createField('title')
    .name('Title')
    .type('Symbol')
    .required(true);

  blogPost.createField('body')
    .name('Body')
    .type('RichText');
};

Hygraph 的迁移工具存在但不那么精致。他们有管理 SDK，最近改进了他们的 schema 迁移能力，但在实践中，许多团队仍然通过 UI 处理模型变更。对于基础设施即代码是非协商的企业项目，Contentful 有明确的优势。

内容联合和多源数据

这是 Hygraph 的杀手级功能，老实说，是一些企业选择它而不是 Contentful 的主要原因。

内容联合让你定义远程数据源（REST API、其他 GraphQL API、数据库）并通过单一 GraphQL 端点将该数据与 CMS 内容一起呈现。想象从 PIM 拉取产品数据、从 Stripe 拉取定价和从 Hygraph 拉取编辑内容——全部在一个查询中。

# Hygraph 联合查询
query {
  product(where: { slug: "pro-plan" }) {
    name
    description  # 来自 Hygraph
    stripePricing {  # 从 Stripe 联合
      unitAmount
      currency
    }
    inventory {  # 从仓库 API 联合
      quantity
      warehouse
    }
  }
}

Contentful 不原生提供任何可比较的功能。你需要构建 API 网关或 BFF（前端后端）层来聚合多个数据源。像 Apollo Federation 或 Grafbase 这样的工具可以帮助，但这是你的团队需要构建和维护的额外基础设施。

对于在多个系统间处理分布式数据的企业——这基本上是所有企业——这是一个重要的差异者。如果你正在构建一个需要从多个后端组合数据的无头 CMS 驱动的架构，Hygraph 的联合使你的应用层更简单。

编辑体验和工作流

Contentful 的编辑 UI 更加精致。它已经迭代多年，这显而易见。侧边栏、条目编辑器和资产管理器都感觉很好用。他们较新的可视化编辑层 Contentful Studio 让编辑可以在实际前端的背景下预览和编辑内容——对于习惯于传统 CMS 工具的编辑团队来说是很大的改进。

Hygraph 的 UI 自重新品牌以来已经大幅改进，但仍感觉略微更倾向开发者。他们的编辑工作流功能——草稿/已发布状态、计划发布、批准工作流——都存在，但管理它们的 UI 对非技术用户来说不太直观。

编辑功能	Hygraph	Contentful
可视化/预览编辑	基础预览	Contentful Studio（可视化）
批准工作流	是（企业版）	是（所有计划）
内容版本控制	是	是（带比较）
翻译工作流	内置	通过 Lokalise/Phrase 集成
批量编辑	是	是
自定义仪表板	是	是（通过应用框架）
内容计划	是	是
角色粒度	好	优秀

如果你的内容团队的满意度很重要（它应该是——他们是每天在 CMS 中工作的人），Contentful 目前提供更好的编辑体验。但差距正在缩小。

性能和全球交付

两个平台都使用 CDN 支持的交付。Contentful 使用 Fastly 作为他们的内容交付网络。Hygraph 使用 Cloudflare 和他们自己的边缘缓存的组合。

在 2025-2026 年我在多个项目中的测试中：

• Contentful GraphQL API：平均响应时间 80-150ms（缓存），200-400ms（未缓存）
• Hygraph GraphQL API：平均响应时间 50-120ms（缓存），150-350ms（未缓存）

Hygraph 往往稍微快一些，特别是对于具有嵌套关系的复杂查询。这是有道理的，因为 GraphQL 是他们的原生 API，而不是一个转换层。

对于使用 Next.js 的静态站点生成和 ISR，两者都足够快——CMS 响应时间很少重要——你的内容在构建时被烤成静态 HTML。响应时间更重要的是动态页面或客户端获取。

集成和生态

Contentful 有更大的市场，拥有 300+ 个集成。从 Algolia 到 Shopify 到 Cloudinary 的一切都原生接入。他们的应用框架让你构建自定义侧边栏小部件和字段编辑器，这对企业定制来说真的很强大。

Hygraph 的集成生态系统较小但在增长。他们拥有必需品——Shopify、Algolia、Auth0、Vercel——他们的 webhook 系统足够灵活可以连接到几乎任何东西。他们的内容联合功能也可以替代一些集成，因为你可以直接查询外部服务。

何时选择哪个

选择 Hygraph 当：

• 你的团队是 GraphQL 优先的，想要原生体验
• 你需要内容联合来合并多个数据源
• 预算敏感性是一个因素（更低的企业定价）
• 你需要实时订阅
• 你想要单一 API 范例（用于读取和写入的 GraphQL）

选择 Contentful 当：

• 你的编辑团队的体验是首要优先级
• 你需要一个成熟的迁移和环境管理方案
• 你的集成需求很重（300+ 个市场应用）
• 你想要可视化编辑功能（Contentful Studio）
• 你的团队对 REST 更舒适，但想要 GraphQL 作为选项

选择任一个当：

• 你正在用 Next.js、Astro 或类似工具构建无头前端
• 你需要企业级安全、SSO 和合规性
• 多区域设置内容是一个需求
• 你需要计划发布和批准工作流

如果你正在权衡这些选项，并想要基于你的具体项目需求的诚实评估，我们在 Social Animal 正是做这种评估的。查看我们的无头 CMS 开发能力或与我们联系，我们会为你详细讲解。

常见问题

Hygraph 真的是 GraphQL 原生还是只是营销？ 这是真的。Hygraph 从一开始就作为 GraphQL API 构建。schema 是从你的内容模型自动生成的，变更通过 GraphQL 工作，订阅原生支持。Contentful 的 GraphQL 是他们 REST 架构顶部的一层，这很好用，但在过滤、变更和实时能力周围有微妙的限制。

Contentful 的 GraphQL API 能完全替代他们的 REST API 吗？ 在 2026 年不能完全。Contentful 的 GraphQL API 是只读的——你仍然需要基于 REST 的内容管理 API 来以编程方式创建、更新和删除内容。还有一些查询复杂性限制和某些字段类型的行为不同。对于纯内容交付，GraphQL 可能涵盖约 95% 的用例。

对于 20 个编辑团队成员和每月 5M API 调用，价格如何比较？ 基于当前定价结构，你将看到大约 $4,000-8,000/月 Hygraph 和 $6,000-15,000/月 Contentful 的用途分布。Contentful 倾向于在企业层按座位和 API 调用收费更多。总是协商——两个供应商都会为多年承诺的定价与你合作。

什么是 Hygraph 中的内容联合，Contentful 有类似的东西吗？ 内容联合让 Hygraph 查询外部 API（REST 或 GraphQL）并在单个 GraphQL 查询中将该数据与 CMS 内容一起呈现。把它看作你内容层的内置 API 网关。Contentful 不原生提供这个。你需要构建一个单独的 BFF 层或使用像 Apollo Federation 这样的东西来实现类似的结果。

哪个 CMS 更好地与 Next.js 应用路由协作？ 两者都很好用。由于 Next.js 应用路由鼓励使用 fetch 或 GraphQL 客户端的服务器端数据获取，Hygraph 和 Contentful 都天然适配。Hygraph 更简洁的 GraphQL schema 使在 React 服务器组件中编写查询略微更愉快，但 Contentful 的官方 SDK 和 TypeScript 类型更成熟。对于我们的Next.js 开发项目，我们两个都成功使用过。

内容迁移在每个平台中如何工作？ Contentful 有可编写脚本的、版本可控的迁移，可通过 CLI 运行并集成到 CI/CD 管道中。它对基础设施即代码方法真的很好。Hygraph 有管理 SDK 和基本迁移工具，但不那么成熟。对于具有多个环境和严格部署流程的大型企业项目，Contentful 的迁移方案更强。

两个平台都有供应商锁定的顾虑吗？ 两者都是无头的，所以你的前端总是可移植的。内容导出是锁定重要的地方。Contentful 支持完整的 space 导出到 JSON，这记录良好。Hygraph 支持通过他们的 API 的内容导出，尽管批量导出的工具不那么精致。富文本是两个平台上最大的锁定风险——每个都使用专有 AST 格式，如果你迁移需要转换。

哪个平台对全球企业的本地化处理更好？ 两个平台都支持企业计划上最多约 50 个区域设置。Contentful 的本地化更深入地集成到编辑 UI 中——编辑可以在区域设置之间内联切换并一目了然地看到翻译状态。Hygraph 支持区域设置感知的内容交付并有一个可靠的本地化设置，但 Contentful 与翻译管理平台（如 Lokalise 和 Phrase）的集成更成熟。对于大量多语言网站，Contentful 在编辑工作流中有小优势。