2026年Next.js App Router最佳CMS：我們在生產環境中測試了6個

我自 Pages Router 時代開始就一直在發佈 Next.js 網站，我已經數不清有多少次看到「最佳 CMS」的文章，是由某個顯然只是安裝過一次、跟著快速入門教程走、然後就把它當成評論的人寫的。這篇不是那樣的。

在 Social Animal，我們在多個 CMS 架構上運行生產網站 -- 從使用 Payload CMS 的醫療應用，到服務超過 253,000+ 頁面跨三個不同平台的 Supabase。我們為實際客戶項目評估過 Strapi 5、Sanity 和 Contentful。而你正在閱讀的這個網站？它建立在提交到 Git 儲存庫的 MDX 檔案上。

所以當我說「我們在生產環境中測試了 6 個」時，我是指我們經歷過遷移的麻煩、構建時間的驚喜、關於內容無法發佈的凌晨 3 點 Slack 訊息。以下是我們關於為 2026 年的 Next.js App Router 選擇合適 CMS 的所有學習成果。

目錄

• 為什麼 App Router 改變了 CMS 等式
• 我們測試的 6 個 CMS（以及我們如何測試它們）
• 1. Payload CMS 3 -- Next.js 的最佳整體選擇
• 2. Supabase-as-CMS -- 規模最佳（10K+ 頁面）
• 3. Strapi 5 -- 非技術團隊的最佳選擇
• 4. Sanity -- 即時協作的最佳選擇
• 5. Contentful -- 企業級的最佳選擇（預算充足）
• 6. Markdown/MDX -- 開發者部落格的最佳選擇
• 生產指標比較
• 決策框架：如何選擇你的 CMS
• 我們會做不同的事
• 常見問答

為什麼 App Router 改變了 CMS 等式

如果你仍然像使用 Pages Router 時那樣考慮 CMS 選擇，你就會在性能上有所損失。App Router 從根本上改變了數據如何流經 Next.js 應用程序，這對於哪個 CMS 最適合有著直接的影響。

以下是現在重要的內容：

Server Components 是默認的。 你的 CMS 數據獲取發生在服務器上，不會向客戶端發送任何 JavaScript。這意味著具有原生 Node.js SDK 的 CMS，或者更好的是，跳過網絡的本地 API 具有巨大優勢。

React Server Components + fetch 快取。 App Router 的內置 fetch 去重和快取意味著你的 CMS 集成模式看起來完全不同。你不再依賴 getStaticProps 或 getServerSideProps。你在編寫直接調用 CMS 的非同步組件。

平行路由和攔截路由。 這些模式解鎖了之前構建起來很麻煩的 CMS 驅動佈局。一個支持靈活內容建模的 CMS（不僅僅是部落格文章和頁面）在這裡會表現出色。

部分預渲染（PPR）。 截至 Next.js 15，PPR 允許你使用動態孔洞提供靜態殼。這完全改變了 ISR 與 SSR 的爭論，這意味著你的 CMS 重新驗證策略比以往任何時候都更重要。

有了所有這些背景，讓我們深入實際的測試。

我們測試的 6 個 CMS（以及我們如何測試它們）

我們的評估不是理論上的。對於每個 CMS，我們要麼發佈了生產頁面，要麼對實際客戶項目進行了深入的技術評估。我們測量了：

• 特別是針對 App Router 的開發者體驗
• 不同頁面數量下的構建時間
• 非開發者團隊成員的內容編輯器 UX
• 規模定價（不僅僅是免費層）
• TypeScript 集成品質
• 重新驗證模式（ISR、按需、webhooks）

讓我們逐一介紹。

1. Payload CMS 3 -- Next.js 的最佳整體選擇

我們的判決：針對 Next.js App Router 的最佳開發者體驗，無可置疑。

Payload CMS 3 是那個讓我重新思考 CMS 可能是什麼的。它不是你通過 HTTP 調用的單獨服務。它住在你的 Next.js 應用程序內。相同的儲存庫、相同的部署、相同的 TypeScript 類型。

我們在 SleepDr 上運行 Payload 3 在生產環境中，這是一個擁有 228 頁、多級訪問控制和需要準確的內容的醫療保健平台（它與健康相關，所以錯誤的內容不僅是不好看 -- 它是一個責任問題）。

什麼使 Payload 對 App Router 特別

Local API 是殺手級功能。不是向你的 CMS 發出 HTTP 請求，而是直接導入和調用函數：

// app/blog/[slug]/page.tsx
import { getPayload } from 'payload'
import config from '@payload-config'

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const payload = await getPayload({ config })
  
  const posts = await payload.find({
    collection: 'posts',
    where: {
      slug: { equals: params.slug },
      status: { equals: 'published' },
    },
  })
  
  const post = posts.docs[0]
  if (!post) notFound()
  
  return <Article post={post} />
}

沒有網絡跳躍。沒有 REST 或 GraphQL 開銷。沒有 SDK 要安裝。函數調用是完全類型化的，因為 Payload 從你的集合配置生成 TypeScript 接口。當你重命名字段時，你的 IDE 會立即捕捉到每個損壞的引用。

使用 App Router 的即時預覽

Payload 3 的即時預覽適用於 Server Components。你的內容編輯器在實際站點佈局上實時看到變化 -- 不是管理面板中的近似值。我們為 SleepDr 配置了這個，編輯團隊在一週內從「我需要開發者來檢查這個」變成自給自足的發佈。

實際有效的訪問控制

Payload 的字段級和集合級訪問控制在代碼中定義：

const Posts: CollectionConfig = {
  slug: 'posts',
  access: {
    read: () => true,
    create: ({ req: { user } }) => user?.role === 'editor' || user?.role === 'admin',
    update: ({ req: { user } }) => user?.role === 'admin',
    delete: ({ req: { user } }) => user?.role === 'admin',
  },
  fields: [
    // ...
  ],
}

對於醫療應用，這種粒度不是可選的。它是必需的。

權衡取捨

Payload 在你的基礎設施上運行。如果你想要一個完全託管的 SaaS 體驗，Payload Cloud 存在（起價約 $35/月用於生產），但你仍然負責理解部署。它也是一個 Node.js 運行時依賴，這意味著你的託管需要支持它（Vercel 有效，但成本隨著到你的數據庫的持久連接而上升）。

對於我們的Next.js 開發工作，Payload 3 現在是我們對於超過 5,000 頁的內容豐富網站的默認推薦。

2. Supabase-as-CMS -- 規模最佳（10K+ 頁面）

我們的判決：嚴格來說不是 CMS，但對於大規模結構化數據集，沒有其他東西能夠接近。

這是非傳統的選擇，也是我最興奮的選擇。Supabase 不以 CMS 的身份進行行銷。它是一個具有身份驗證、儲存和邊緣函數的 PostgreSQL 平台。但當你的「內容」實際上是結構化數據時 -- 名人檔案、企業清單、產品數據庫 -- 傳統 CMS 在規模上崩潰，而 Supabase 甚至沒有出汗。

我們在 Supabase-as-CMS 上運行三個生產網站：

• DA -- 超過 91,000 頁名人數據跨 30 種語言
• NAS -- 137,000+ 企業清單
• HostList -- 25,000+ 主機提供商清單

那是 253,000+ 頁。讓我告訴你當你試著將 91,000 個條目放入傳統無頭 CMS 中會發生什麼：管理面板變得無法使用，構建時間去無窮大，你的賬單突飛猛進。

架構

我們不使用 generateStaticParams 來生成 253K 頁面。我們使用完全動態渲染和積極快取：

// app/[locale]/celebrity/[slug]/page.tsx
import { createClient } from '@/lib/supabase/server'

export default async function CelebrityPage({ params }: Props) {
  const supabase = await createClient()
  
  const { data: celebrity } = await supabase
    .from('celebrities')
    .select('*, social_profiles(*), net_worth_history(*)')
    .eq('slug', params.slug)
    .eq('locale', params.locale)
    .single()
  
  if (!celebrity) notFound()
  
  return <CelebrityProfile data={celebrity} />
}

export const revalidate = 86400 // 每日重新驗證

構建時間？約 10 秒。頁面按需渲染並在邊緣快取。當有人搜索一個我們最近沒有提供的名人時，第一個請求擊中 Supabase（通常從邊緣的 20-50ms），渲染頁面、快取它，之後每個後續訪客都獲得快取版本。

行級安全作為訪問控制

Supabase 的 RLS 策略替代了你通常在 CMS 管理中構建的內容：

CREATE POLICY "Public read access" ON celebrities
  FOR SELECT USING (status = 'published' AND locale = current_setting('app.locale'));

CREATE POLICY "Editor update access" ON celebrities
  FOR UPDATE USING (auth.role() = 'editor');

內容編輯問題

這是誠實的缺點：Supabase 的表格編輯器對開發者來說很不錯，但它不是內容編輯體驗。我們使用 Supabase 的客戶端庫為我們的編輯團隊構建自定義管理界面。如果你不想構建自己的管理 UI，這個方法不適合你。

Supabase Pro 運行 $25/月，即使在 253K 頁面，我們也遠未達到計算或存儲限制。將其與相似規模的 Contentful 或 Sanity 定價比較。

對於我們的無頭 CMS 開發解決方案，我們推薦這個方法用於超過 10,000 個結構化內容頁面的任何項目。

3. Strapi 5 -- 非技術團隊的最佳選擇

我們的判決：最佳視覺內容建模體驗，理想用於當你的編輯者不是開發者時。

我們為一個客戶項目深入評估了 Strapi 5，並編寫了一份廣泛的 Payload vs Strapi 比較（在第 1 頁排名，所以顯然其他人也在問相同的問題）。雖然我們最終為該項目選擇了 Payload，但 Strapi 有明確的用例。

Strapi 5 的 Content-Type Builder 讓非技術團隊成員通過拖放 GUI 創建和修改內容結構。沒有代碼。沒有配置檔。沒有部署。你的行銷經理可以添加一個「證明」內容類型，包含引言、作者、公司和評級字段，而無需提交 Jira 票證。

App Router 集成

Strapi 5 暴露了 REST 和 GraphQL API。與 App Router 的集成很直接，但需要網絡請求：

// lib/strapi.ts
export async function getArticles() {
  const res = await fetch(
    `${process.env.STRAPI_URL}/api/articles?populate=*`,
    {
      headers: { Authorization: `Bearer ${process.env.STRAPI_TOKEN}` },
      next: { revalidate: 60 },
    }
  )
  return res.json()
}

它有效。但與 Payload 的 Local API 相比，你會感受到阻抗不匹配。你正在序列化和反序列化本可以保持進程內的數據。TypeScript 類型需要單獨生成（Strapi 有一個 CLI，在 v5 中有所改進）。

Strapi 5 定價（2026）

計畫	價格	座位	資源
Community	免費（自託管）	無限制	無限制
Team	$29/月/座位	5-20	100GB
Business	$99/月/座位	自定義	500GB
Enterprise	自定義	自定義	自定義

自託管 Strapi 是真正免費的，運行良好。雲計畫增加託管和優先支持。

4. Sanity -- 即時協作的最佳選擇

我們的判決：最佳即時編輯體驗，但 GROQ 是一個愛它或討厭它的承諾。

我們為 DA 項目（91K 名人頁面）認真評估了 Sanity，然後在選擇 Supabase 之前。Sanity Studio 真的令人印象深刻 -- 它是一個你可以將其自定義到字段級別的 React 應用程序。即時協作無縫工作。兩個編輯可以同時在同一個文檔上工作，Google Docs 風格。

GROQ：強大但有爭議

Sanity 使用 GROQ，它自己的查詢語言：

*[_type == "article" && slug.current == $slug][0] {
  title,
  body,
  "author": author->{ name, image },
  "categories": categories[]->{ title, slug },
  publishedAt
}

GROQ 一旦你學會了實際上很優雅。投影語法（->）用於解析引用在許多用例中比 GraphQL 更好。但它是你的團隊需要學習和維護的另一種查詢語言。當你擊中邊緣情況時，文檔可能會感到薄弱。

為什麼我們沒有為 DA 選擇 Sanity

在 91,000 個文檔，Sanity 的定價變得重要。增長計畫（$15/用戶/月）包括 1M API CDN 請求。聽起來很多，直到你意識到一個擁有 91K 頁面、生成不錯流量的網站會快速耗盡這個限制。我們估計 DA 的每月 Sanity 賬單將是 $300-500/月。$25/月的 Supabase Pro 是顯而易見的選擇。

Sanity 對於擁有 50-5,000 個內容項目的網站很出色，其中多個編輯需要協作。媒體公司的編輯團隊喜歡它。

5. Contentful -- 企業級的最佳選擇（預算充足）

我們的判決：最成熟的無頭 CMS，但你會為那個成熟付出代價。

Contentful 自 2013 年起就存在了。它是無頭 CMS，企業團隊默認採用，並且有原因：內容建模很優秀、API 很穩固（Premium 上 99.99% SLA），集成生態系統無與倫比。

我們為多個企業客戶項目評估了 Contentful。內容模型構建器很亮麗、Web 應用程序中的 API 瀏覽器對於調試很有用，webhook 系統與 Next.js 按需重新驗證乾淨集成。

標籤價格

計畫	價格（2026）	內容類型	地區	API 調用
免費	$0	48	2	1M/月
基本	$300/月	48	6	2M/月
Premium	自定義（通常 $3,000+/月）	無限制	無限制	自定義

從免費到基本的跳躍很陡峭。從基本到 Premium 的跳躍是懸崖。如果你是一個年度 SaaS 預算 $50K+ 的企業，Contentful 是一個安全的選擇。如果你是一個試著保持燃燒率低的初創，看別的地方。

App Router 集成

Contentful 的 JavaScript SDK 與 Server Components 很好地工作：

import { createClient } from 'contentful'

const client = createClient({
  space: process.env.CONTENTFUL_SPACE_ID!,
  accessToken: process.env.CONTENTFUL_ACCESS_TOKEN!,
})

export async function getPage(slug: string) {
  const entries = await client.getEntries({
    content_type: 'page',
    'fields.slug': slug,
    include: 3,
  })
  return entries.items[0]
}

SDK 維護良好且完全使用 contentful-typescript-codegen 類型化。DX 方面沒有抱怨。

6. Markdown/MDX -- 開發者部落格的最佳選擇

我們的判決：零開銷，最大控制，Git 本地工作流。

這個網站 -- socialanimal.dev -- 運行在 MDX 上。每篇文章是儲存庫中的一個檔案，帶有前言元數據：

---
title: "Next.js App Router 2026 最佳 CMS"
slug: "best-cms-nextjs-app-router-2026"
category: "Resources"
tags: ["nextjs", "cms", "payload", "supabase"]
publishedAt: "2026-01-15"
---

我自 Pages Router 時代開始就一直在發佈 Next.js 網站...

使用 @next/mdx 或 contentlayer2（社區分支），MDX 與 App Router 本地集成。你的內容就是你的代碼庫。版本控制、分支、pull request 評論 -- 你已經知道的所有工作流。

MDX 何時崩潰

非開發者無法使用它。句號。如果你的行銷團隊需要發佈部落格文章，MDX 意味著他們要麼學習 Git，要麼你在為他們構建編輯界面（此時，只需使用 Payload）。

MDX 也不能很好地擴展到數千個頁面。在大約 500+ MDX 檔案，構建時間開始拖累，你的 IDE 變慢。對於公司部落格或文檔網站，它很完美。對於內容平台，它不是。

對於我們的Astro 開發工作，我們甚至更廣泛地使用 MDX，因為 Astro 的內容集合為 Markdown/MDX 內容提供了優秀的類型安全。

生產指標比較

這是來自我們實際生產部署和評估的數據：

CMS	生產頁面	語言	構建時間	月成本	我們的判決
Payload 3	228（SleepDr）	1	~45s	$35（Payload Cloud）	Next.js 最佳 DX
Supabase	253K（DA+NAS+HostList）	30	~10s	$25（Pro 計畫）	規模最佳
Strapi 5	0（已評估）	N/A	N/A	免費（自託管）	最佳 GUI 編輯器
Sanity	0（已評估）	N/A	N/A	~$300-500 估計	協作最佳
Contentful	0（已評估）	N/A	N/A	$300+（基本）	企業最佳
MDX	~60（此網站）	1	~30s	$0	開發者部落格最佳

構建時間列值得解釋。Payload 在 45 秒包括生成 228 個靜態頁面。Supabase 在 10 秒因為我們不靜態生成 253K 頁面 -- 我們使用動態渲染和 ISR。MDX 在 30 秒是約 60 篇文章，帶有語法突出顯示和圖像優化。

決策框架：如何選擇你的 CMS

忘記功能清單。回答這四個問題：

1. 誰在編輯內容？

• 僅開發者 → MDX 或 Payload
• 開發者 + 技術編輯 → Payload 或 Sanity
• 非技術行銷團隊 → Strapi 或 Contentful

2. 有多少頁？

• 不足 500 → 任何 CMS 都有效。根據編輯 UX 選擇。
• 500-5,000 → Payload 或 Sanity。兩者都很好處理這個範圍。
• 5,000-50,000 → Supabase 或 Contentful（預算充足）。
• 50,000+ → Supabase。沒有其他東西在經濟上有意義。

3. 你的月 CMS 預算是多少？

• $0 → 自託管 Payload、自託管 Strapi 或 MDX
• $25-50 → Supabase Pro 或 Payload Cloud
• $100-500 → Sanity Growth 或 Strapi Cloud
• $500+ → Contentful 或 Sanity Enterprise

4. 你需要即時協作嗎？

• 是的，關鍵 → Sanity（同類最佳）
• 很高興有 → Payload（即時預覽很接近）
• 不關心 → 任何其他

我們會做不同的事

後見之明是有價值的。以下是我們會改變的內容：

我們會更早開始使用 Payload。 在 Payload 3 成熟之前，我們構建了一些基於 Supabase 的自定義管理面板的早期項目。對於超過 5K 頁面的網站，Payload 會節省我們大量的管理 UI 開發時間。

我們會更早標準化我們的 Supabase-as-CMS 模式。 我們的三個 Supabase 項目中的每一個在內容建模、快取和重新驗證的約定上都略有不同。我們現在已經創建了一個內部模板，用於所有新的高流量項目。

我們會為非企業客戶跳過 Contentful 評估。 定價懸崖是真實的，兩次我們進行了多週的評估，只是意識到客戶的預算與 Contentful 的定價不符。我們應該首先詢問預算。

如果你面臨類似的 Next.js 項目 CMS 決策，我們很樂意分享更多關於我們體驗的詳細信息。查看我們的定價頁面或直接聯繫 -- 我們每天都在做這些東西。

常見問答

2026 年 Next.js 的最佳無頭 CMS 是什麼？ 基於我們在 253K+ 頁面上的生產體驗，Payload CMS 3 是 Next.js App Router 的最佳整體選擇。它的 Local API 消除了網絡開銷、TypeScript 類型自動生成，管理面板住在你的 Next.js 應用程序內。對於超過 10,000 頁的網站，我們推薦使用 Supabase 作為 CMS 層，帶有自定義管理界面。

Payload CMS 真的是免費的嗎？ Payload CMS 是開源的，可免費自託管，沒有功能限制。你需要提供自己的託管和數據庫（MongoDB 或 PostgreSQL）。Payload Cloud 是他們的託管服務，2026 年起價約 $35/月用於生產工作負載。自託管版本上沒有按座位收費。

我能將 Supabase 用作 Next.js 的 CMS 嗎？ 是的，我們在規模上做。我們運行三個生產網站，在 Supabase 上總共 253,000+ 頁。當你的內容是結構化數據（檔案、清單、產品目錄）而不是長篇社論內容時，它的效果特別好。主要權衡是你需要構建自己的內容編輯界面 -- Supabase 的表格編輯器不是為編輯工作流設計的。

Strapi 5 與 Payload CMS 3 對 Next.js 有何比較？ Strapi 5 以其視覺化 Content-Type Builder 為非技術內容編輯提供了優秀的效果。Payload 3 以其 Local API 和 TypeScript 本地方法為開發者體驗提供了優秀的效果。如果你的編輯者是開發者，選擇 Payload。如果你的編輯者是行銷人員，選擇 Strapi。我們編寫了詳細的 Payload vs Strapi 比較，深入涵蓋了這個主題。

Next.js 最便宜的無頭 CMS 是什麼？ 自託管 Payload CMS 和自託管 Strapi 都是真正免費的。Git 儲存庫中的 MDX 檔案除了你的託管之外沒有成本。對於託管服務，Supabase Pro 在 $25/月 提供最佳規模價值 -- 我們在單個 Pro 計畫上提供 253K 頁。Sanity 的免費層對於小項目也很慷慨（最多 3 個用戶，500K API 請求/月）。

Contentful 對 Next.js 項目值得嗎？ Contentful 如果你是需要 99.99% SLA 的企業團隊、與 Commercetools 或 Salesforce 等工具建立的集成以及你有預算（$300+/月用於基本，$3,000+/月用於 Premium），那麼它值得。對於初創公司和中型公司，Payload 或 Sanity 以相對成本的一小部分提供了可比較的功能。

我應該在 Next.js App Router 中使用 ISR 還是 SSR 帶著無頭 CMS？ 這取決於你的頁面計數和內容更新頻率。對於超過 5,000 頁的網站，靜態生成帶著通過 webhooks 的按需重新驗證是理想的。對於 5,000+ 頁，動態渲染帶著 ISR（revalidate = 3600 或類似）更實用 -- 你無法在每個部署上構建 50K 頁。使用 Payload 的 Local API，區別變得較少重要，因為無論哪種方式都沒有網絡開銷。

我能從 WordPress 遷移到 Next.js 的無頭 CMS 嗎？ 絕對可以。我們已經進行了多次 WordPress 遷移。典型的路徑是：通過 REST API 或 WP-CLI 導出 WordPress 內容、轉換並導入到你的目標 CMS，然後在 Next.js 中重建前端。Payload CMS 使這個過程特別順利，因為你可以建模你的集合以匹配現有的 WordPress 文章類型。有關此過程的更多詳細信息，請參見我們的無頭 CMS 開發解決方案。