Contentful vs Sanity vs Payload：哪個 CMS 能度過實際客戶考驗？

你的客戶核准了 Contentful，時間是三月。到了八月，你的開發團隊已經在 Slack 上討論要把它撕掉。自 2022 年以來，我已經在 40 多個專案中使用 Contentful、Sanity 和 Payload 進行生產構建——有些是全新的 Next.js 應用，有些是從由膠帶和祈禱堆砌而成的 WordPress 安裝的救援。每個 CMS 都以不同的、昂貴的方式失敗了。Contentful 的 API 限制在週二早上 6 點扼殺了一次產品發佈。Sanity 的 GROQ 學習曲線讓行銷團隊停滯了兩個 sprint。Payload 的自託管帳單讓一位種子期創辦人驚訝，因為他認為「開源」意味著「免費」。有一個選擇始終導致比其他的 2 AM Slack 通知更少。

本文分別從 Contentful、Sanity 和 Payload CMS 在實際構建真實項目時真正重要的維度進行分析：大規模定價、實地開發人員體驗、內容建模靈活性、API 設計，以及你的內容團隊將喜歡或討厭的日常編輯工作流程。

目錄

• 30 秒概覽
• 定價細目：你實際將支付的費用
• 開發人員體驗
• 內容建模
• API：REST、GraphQL 及其他
• 編輯體驗
• 自託管 vs SaaS：真實的權衡
• 性能和可擴展性
• 生態系統和社群
• 總結
• 常見問題

30 秒概覽

Contentful 是現任者。它自 2013 年以來一直存在，為企業網站大規模供電。它是拋光的、可靠的，而且昂貴的。

Sanity 是開發人員最喜愛的，以其實時、結構化內容方法和可自訂的 studio 著稱。它功能強大，但有學習曲線和定價模型可能會讓你驚訝。

Payload 是一個安靜地成為嚴肅參與者的新興力量。它是開源的、預設為自託管的（現在有雲端選項），用 TypeScript 編寫，不收取許可費。Payload 3.0 在 Next.js 基礎上推出了完整重寫，它完全改變了方程式。

功能	Contentful	Sanity	Payload
類型	SaaS	SaaS（自託管 studio）	開源／自託管
語言	無（僅 API）	JavaScript/React	TypeScript/Next.js
許可費	是	是（基於使用）	無（MIT）
GraphQL	是	是（首選 GROQ）	是（自動生成）
REST API	是	是	是（自動生成）
實時協作	有限	優秀	良好（2.0+）
自託管	否	僅 Studio	完整堆棧
數據庫	專有	專有	MongoDB 或 Postgres

定價細目：你實際將支付的費用

這是事情變得真實的地方。定價是我見過的團隊在專案中期更換 CMS 的首要原因，也是人們在評估期間最容易低估的事情。

Contentful 定價（2026）

Contentful 的免費層提供 1 個 space、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 開發人員體驗

Contentful 的開發人員體驗是......還可以。他們的 SDK 支援範圍廣泛（JavaScript、Python、Ruby、Java、Swift 等），文件成熟，REST 和 GraphQL API 有詳細記錄。

但以下是令我沮喪的地方：一切都通過網路 UI 配置。內容類型、欄位、驗證——一切都在瀏覽器中點擊點擊點擊。是的，你可以使用 Contentful CLI 和遷移指令碼來版本控制你的架構，但它感覺像是事後補充。它不是程式碼優先的；它是 UI 優先的，有程式碼逃脫艙口。

遷移工具已隨著他們的 contentful-migration 套件改進，但與在 TypeScript 中定義你的架構並獲得即時類型安全相比？它感覺像是落後一代。

Sanity 開發人員體驗

Sanity 的開發人員體驗在許多方面都是真正優秀的。架構在 JavaScript/TypeScript 檔案中定義。Studio 是你可以廣泛自訂的 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 開發人員體驗

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 應用，你可以在你的 CMS 程式碼旁邊添加自訂頁面、API 路由或伺服器動作。

對於進行 Next.js 開發的團隊，Payload 3.0 從開發人員體驗的角度來看是一個不費吹灰之力的選擇。你的 CMS 和前端住在同一個專案中。同一部署。同一個 repo。

內容建模

內容建模是你要麼為自己設定成功，要麼創建一個你將多年來生活的噩夢。

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 提供你草稿/發佈工作流程和完整的文件版本歷史記錄，帶有 diffing。這是內建的，不是付費附加功能。

API：REST、GraphQL 及其他

Contentful API

Contentful 為傳遞（CDN 快取、唯讀）、預覽（非快取、草稿內容）、管理（CRUD）和影像提供了分離的 API。分離是合理的，但這意味著你正在處理多個 API 權杖和基本 URL。

他們的 GraphQL API 很穩固，但有深度限制和速率限制，這在建模深度參考內容時可能令人沮喪。複雜的查詢可能需要多次往返。

Sanity API

Sanity 的主要查詢語言是 GROQ，通過 HTTP 提供。他們確實提供 GraphQL API，但它似乎是分開部署的和二流公民。對於大多數 Sanity 使用案例，GROQ 無論如何都更強大。

真正的魔力在 Sanity 的實時監聽器 API 中。你可以訂閱任何查詢上的更改並獲得即時更新。這實現了真正令人印象深刻的實時預覽體驗。

Payload API

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 App，這是一個完全分離的 React 應用。

Sanity Studio 是最可自訂的。你可以建立完全自訂的編輯體驗。但那種自訂伴隨著成本：開箱即用，Sanity Studio 對於非技術編輯可能感覺不堪重負。結構構建器需要開發人員時間才能配置良好。

Payload 的管理面板在 3.0 中有了大幅改進。它乾淨、快速（它是一個 Next.js 應用），並支援自訂元件、條件欄位渲染和實時預覽。它不如 Contentful 的 UI 那樣拋光，但它更易自訂，比 Contentful 需要更少的工作，比 Sanity 對開箱即用的編輯更易理解。

自託管 vs SaaS：真實的權衡

這是哲學分野。Contentful 和 Sanity 是 SaaS 平台。你不管理基礎設施；你付費讓他們做。Payload 預設為自託管。

SaaS 的論點：較少的 ops 開銷、內建 CDN、受管的正常運行時間。這些是真實的好處，特別是對於沒有 DevOps 經驗的小型團隊。

自託管的論點：資料所有權、沒有供應商鎖定、可預測的成本、規制合規（GDPR、HIPAA、資料駐留），以及自由自訂任何東西。

對於像我們這樣進行無頭 CMS 開發的機構，自託管在 2026 年已成為大多數客戶的建議。基礎設施工具已成熟到在 Railway、Vercel 或 AWS 上部署 Payload 應用是直接的程度。Docker 使其可複製。而且 SaaS CMS 的成本節省逐年複合。

如果你擔心 ops 負擔，Payload Cloud 為你處理託管，同時保持開源好處。

性能和可擴展性

Contentful 的 CDN 支援傳遞 API 很快。典型的回應時間是來自邊緣節點的 50-100ms。它已在過去十年的規模上經過戰鬥檢驗。

Sanity 的 CDN API 為快取內容提供類似的性能，他們的實時層為實時查詢添加 20-30ms。

Payload 的性能取決於你的基礎設施，但這裡是一件事——當你與 Next.js 伺服器元件一起使用本地 API 時，你正在對本地資料庫進行函式呼叫。回應時間可以低於 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 任何你需要的東西。

截至 2026 年初，Payload 的 GitHub 有 30K+ 星，軌跡很陡峭。

總結

我會直言不諱：Payload 是 2026 年大多數專案的最佳無頭 CMS。

原因如下：

1. 任何規模零許可費。你的 50 個編輯企業團隊不向 Payload 支付一毛錢。
2. TypeScript 原生配置意味著你的內容模型是程式碼，版本控制、類型安全且可在 PR 中審查。
3. 本地 API + Next.js 整合提供了 SaaS CMS 在物理上無法匹配的性能。
4. 資料所有權 —— 你的內容住在你的資料庫中，不是別人的專有商店。
5. 沒有供應商鎖定 —— 如果你想遷移，你的資料在 Postgres 或 MongoDB 中。只是查詢它。

有些情況下其他的會贏：

• 選擇 Contentful，如果你是一個大型企業，擁有一個既定的內容團隊，需要一個拋光的、零 ops 的編輯體驗，並且有預算。
• 選擇 Sanity，如果實時協作對你的工作流程至關重要，你需要 Portable Text 無與倫比的結構化豐富文字，或者你正在構建高度自訂的 studio 體驗。
• 為其他所有東西選擇 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 影像優化結合起來，進行響應式、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 配對。