我在過去四年間在 Hygraph（當時還叫 GraphCMS）和 Contentful 上都開發過生產應用。我在凌晨 2 點處理過部署故障，與內容團隊討論過建模決策，也見證了這兩個平台的重大演進。這不是表面層級的功能清單 — 這是我在這兩個平台上發佈實際項目後的真實想法。

如果你在 2026 年為企業項目評估這兩個平台，你問的是對的問題。它們是兩個最成熟的無頭 CMS 選項，都有強大的 GraphQL 支持，但它們解決問題的方式不同。讓我帶你看看每個平台的優勢和缺點。

目錄

Hygraph vs Contentful 2026: Enterprise GraphQL CMS Compared

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（鑑於你在這裡閱讀，很可能你就是），兩者都是不錯的選擇。但魔鬼隱藏在細節中。

架構和 API 理念

根本區別就在這裡。

Contentful 最初是以 REST 優先的方式構建的。他們的內容交付 API 和內容管理 API 原本是 REST，他們在最上層添加了 GraphQL。這是很好的 GraphQL — 別誤會我的意思 — 但它不是系統從一開始就設計的方式。你可以在邊界情況下感受到這一點：某些在 REST 中完美運行的篩選操作在 GraphQL 中需要變通方案，GraphQL API 在功能方面歷來落後於 REST。

Hygraph 從一開始就是以 GraphQL 本地的方式構建的。每條內容、每個資產、每個關聯 — 都通過單個 GraphQL 端點傳遞。他們的架構由你的內容模型自動生成，感覺很自然。變更、查詢、訂閱 — 一切都在那裡，沒有任何阻抗不匹配。

以下是它在實踐中的含義：

# 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 的更簡潔的架構確實更好用。

內容建模比較

兩個平台都支持你期望的核心原語：文本、富文本、數字、布爾值、日期、JSON、參考、資產和枚舉。

功能 Hygraph Contentful
內容類型限制（企業版） 無限制 每個空間 200 個
每個內容類型的欄位數 500 50
支持的語言環境 最多 50 個 最多 50 個（企業版）
富文本格式 自定義 AST + 基於 Slate 結構化富文本（自定義 AST）
組件/區塊 是（可重用組件） 是（嵌入式條目）
聯合類型 本地 GraphQL 聯合 通過內容類型參考
條件欄位 是（可見性條件） 通過應用框架擴展
欄位驗證 內置 + 正則表達式 內置 + 正則表達式 + 自定義應用
環境 是（多階段） 是（環境別名）
排期發佈 是 是

Contentful 中每個內容類型 50 個欄位的限制讓人感到驚訝。如果你在建模複雜的產品數據或多部分著陸頁面，你會撞到那堵牆。變通方案是將內容分解成更小的、相互鏈接的類型，這實際上是更好的架構 — 但這是一個強制約束而不是選擇。

Hygraph 的組件系統值得特別指出。你可以定義可重用的組件架構並將其嵌入到內容類型中。把它想像成一個嵌套的、有類型的 JSON 欄位，擁有自己的架構定義。對於構建靈活的頁面編輯器非常有用，編輯器可以從預定義的區塊中組成部分。Contentful 通過富文本中的嵌入式條目實現類似的功能，但它是一個不同的思維模型。

富文本處理

說實話，這兩個平台都是痛點。富文本在無頭 CMS 中本質上很複雜，因為你存儲的是結構化內容，需要在任何前端呈現。

Contentful 的富文本返回一個 JSON AST，你可以用他們的 @contentful/rich-text-react-renderer 包進行渲染。它可以工作，但呈現嵌入式條目（如內聯產品卡或 CTA）需要自定義節點解析器，可能變得冗長。

Hygraph 的富文本也是基於 AST 的，需要類似的渲染方法。他們提供 @graphcms/rich-text-react-renderer。兩者都可以工作。兩者都不是特別優雅。這就是無頭富文本的本質。

Hygraph vs Contentful 2026: Enterprise GraphQL CMS Compared - architecture

GraphQL 實現深度探討

讓我們深入討論 GraphQL API，因為這就是這個比較的全部意義所在。

查詢複雜性和速率限制

Contentful 為 GraphQL 查詢應用複雜性評分。截至 2026 年，限制為每個查詢 11,000 個複雜性點。具有多個 Collection 擴展的深層嵌套查詢可能會超過此限制。他們的速率限制每秒 55 個請求，適用於企業計劃上的交付 API。

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 個席位，每月 100 萬個 API 調用） $0（1 個空間，5 個用戶）
專業版 起價約 $399/月 起價約 $489/月
企業版 自定義（通常 $2,500-15,000/月） 自定義（通常 $3,500-25,000+/月）
API 調用包含（企業版） 1000 萬 - 1 億+ 500 萬 - 5000 萬+
資產存儲（企業版） 500GB+ 250GB+
環境 每個計劃多個 多個（企業前額外費用）

這些是基於公開定價和我在提案中看到的大致範圍。你的實際報價將根據席位、API 量和支持層級而異。

Contentful 通常更昂貴，特別是大規模情況。他們的每 API 調用超額費用可能會讓你吃驚 — 我見過團隊因為配置不當的 ISR 設置進行過度 API 調用而被收取 $2,000+ 的超額費用。Hygraph 的定價在 API 量上更寬容，他們的快取層意味著更少的調用命中源。

值得注意的一點是：Contentful 的企業合同傾向於年度簽訂，有重大承諾。根據我的經驗，Hygraph 對更靈活的條款提供更多靈活性，儘管他們也在推動大型交易的年度合同。

開發者體驗和 SDK 質量

Contentful 存在時間更長，這點顯而易見。他們的 SDK 生態系統更成熟：

  • 8 種以上語言的官方 SDK
  • contentful.js 用於交付，contentful-management.js 用於管理
  • 優秀的 TypeScript 代碼生成，配合 cf-content-types-generator
  • 適用於 React、Vue 和原生 JS 的富文本渲染器
  • 用於遷移和空間管理的 Contentful CLI

Hygraph 已經趕上了不少，但仍有缺口：

  • 主要關注 JavaScript/TypeScript SDK
  • graphql-request 或任何 GraphQL 客戶端都可以工作（無需特定於供應商的 SDK）
  • 通過 GraphQL 代碼生成器的 TypeScript 代碼生成（非 Hygraph 特定的，但完美運行）
  • 管理 API SDK 較新，經過的實戰測試較少
  • 用於架構遷移的 CLI 工具可用，但成熟度較低

這裡的事情是 — 因為 Hygraph 只是標準 GraphQL，你實際上不需要他們的 SDK。你可以使用 urql、Apollo Client、graphql-request 或任何 GraphQL 客戶端。架構是自文檔化的。如果你的團隊已經有 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，最近改進了他們的架構遷移能力，但實際上，許多團隊仍然通過 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 構建。架構由你的內容模型自動生成，變更通過 GraphQL 工作，訂閱本地支持。Contentful 的 GraphQL 是他們 REST 架構上的一個層，運行良好，但在篩選、變更和實時功能方面有微妙的限制。

Contentful 的 GraphQL API 能完全取代他們的 REST API 嗎？ 2026 年還不能完全。Contentful 的 GraphQL API 是只讀的 — 你仍然需要基於 REST 的內容管理 API 以編程方式創建、更新和刪除內容。還有一些查詢複雜性限制和某些欄位類型的行為不同。對於純內容交付，GraphQL 可能涵蓋了 95% 的用例。

對於有 20 名編輯的團隊，每月有 500 萬次 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 App Router？ 兩者都很好。由於 Next.js App Router 鼓勵使用 fetch 或 GraphQL 客戶端進行服務器端數據獲取，Hygraph 和 Contentful 都自然地適合。Hygraph 更簡潔的 GraphQL 架構使在 React 服務器組件中編寫查詢略微更令人愉快，但 Contentful 的官方 SDK 和 TypeScript 類型更成熟。對於我們的Next.js 開發項目，我們已經成功使用了兩者。

內容遷移在每個平台中如何運行？ Contentful 有腳本化的、版本可控的遷移，可以通過 CLI 運行並集成到 CI/CD 管道中。它對於基礎設施即代碼方法真的很優秀。Hygraph 有一個管理 SDK 和基本的遷移工具，但不如成熟。對於有多個環境和嚴格部署流程的大型企業項目，Contentful 的遷移故事更強。

這兩個平台有供應商鎖定問題嗎？ 兩者都是無頭的，所以你的前端始終是可移植的。內容導出是鎖定很重要的地方。Contentful 支持完整的空間導出為 JSON，文檔齊全。Hygraph 通過他們的 API 支持內容導出，儘管用於批量導出的工具不如精煉。富文本是兩個平台上最大的鎖定風險 — 每個都使用專有 AST 格式，如果你遷移需要轉換。

哪個平台對全球企業的本地化處理更好？ 兩者在企業計劃上支持約 50 個語言環境。Contentful 的本地化更深入地集成到編輯 UI 中 — 編輯可以在語言環境之間內聯切換並一目瞭然看到翻譯狀態。Hygraph 支持語言環境感知的內容交付並有可靠的本地化設置，但 Contentful 與 Lokalise 和 Phrase 等翻譯管理平台的集成更成熟。對於大量多語言網站，Contentful 在編輯工作流中略有優勢。