我在生产环境测试了 6 个 CMS：2026 年 Next.js App Router 最佳选择

自从 Pages Router 时代以来，我一直在部署 Next.js 网站，我已经数不清看过多少次"最佳 CMS"的文章，这些文章的作者显然只是装过一次，跟着快速开始教程走了一遍，然后就写了个评测。这不是那种文章。

在 Social Animal，我们在多个 CMS 架构上运行生产网站——从支持医疗保健应用的 Payload CMS，到为三个不同平台服务 253,000+ 页面的 Supabase。我们为真实客户项目评估过 Strapi 5、Sanity 和 Contentful。而你现在正在阅读的这个网站？它是用提交到 Git 仓库的 MDX 文件构建的。

所以当我说"我们在生产环境中测试了 6 个"时，我的意思是我们处理过迁移的头痛，build 时间的意外，以及关于内容无法发布的凌晨 3 点 Slack 消息。以下是我们关于为 2026 年的 Next.js App Router 选择合适 CMS 所学到的一切。

目录

Best CMS for Next.js App Router 2026: We Tested 6 in Production

为什么 App Router 改变了 CMS 方程

如果你仍然以 Pages Router 的方式思考 CMS 选择，你在性能上就落后了。App Router 从根本上改变了数据如何流经 Next.js 应用，这对哪个 CMS 最适合有直接的影响。

以下是现在重要的东西：

Server Components 是默认。 你的 CMS 数据获取发生在服务器上，而不是向客户端发送任何 JavaScript。这意味着具有原生 Node.js SDK 的 CMS，或者更好的是——跳过网络完全使用本地 API 的 CMS 具有巨大的优势。

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 的支持
  • Build 时间，在各种页面数量下
  • 内容编辑器 UX，针对非开发者团队成员
  • 规模化定价（不仅仅是免费层）
  • TypeScript 集成质量
  • 重新验证模式（ISR、按需、webhooks）

让我们逐一看看。

1. Payload CMS 3 -- Next.js 综合最佳选择

我们的判断：Next.js App Router 的最佳开发者体验，无容置疑。

Payload CMS 3 让我重新思考什么是 CMS。它不是一个你通过 HTTP 调用的独立服务。它存在于 你的 Next.js 应用内。同一个仓库，同一个部署，同样的 TypeScript 类型。

我们在 SleepDr（一个医疗保健平台，有 228 个页面、多级访问控制，以及需要准确的内容——这是与健康相关的，所以错误的内容不仅仅是不好看——这是一个责任）上在生产环境中运行 Payload 3。

什么让 Payload 对 App Router 特别

本地 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 页面以下的内容丰富网站的默认推荐。

Best CMS for Next.js App Router 2026: We Tested 6 in Production - architecture

2. Supabase-as-CMS -- 大规模最佳选择（10K+ 页面）

我们的判断：技术上不是 CMS，但没有其他东西能在大规模结构化数据方面接近。

这是非常规的选择，也是我最兴奋的一个。Supabase 没有作为 CMS 营销。它是一个带有认证、存储和边缘函数的 PostgreSQL 平台。但是当你的"内容"真的是结构化数据——名人档案、商业列表、产品数据库——传统 CMS 在规模上就崩溃了，Supabase 甚至不会流汗。

我们在 Supabase-as-CMS 上运行三个生产网站：

  • DA -- 跨越 30 种语言的 91,000+ 名人数据页面
  • NAS -- 137,000+ 商业列表
  • HostList -- 25,000+ 托管提供商列表

那是 253,000+ 页面。让我告诉你当你尝试把 91,000 个条目放入传统 headless CMS 时会发生什么：管理面板变得无法使用，build 时间趋向于无穷，你的账单飞速上升。

架构

我们不用 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 // 每天重新验证

Build 时间？大约 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 的定价。

对于我们的 headless CMS 开发解决方案，我们为任何超过 10,000 个结构化内容页面的项目推荐这种方法。

3. Strapi 5 -- 非技术团队最佳选择

我们的判断：最好的视觉内容建模体验，对于编辑不是开发者时是理想的。

我们为一个客户项目深入评估了 Strapi 5，并撰写了一份详细的 Payload vs Strapi 比较（它在第 1 页排名，所以显然其他人也在问同样的问题）。虽然我们最终为那个项目选择了 Payload，但 Strapi 有一个明确的用例。

Strapi 5 的内容类型构建器让非技术团队成员通过拖放 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 的本地 API 相比，你感受到了阻抗不匹配。你在序列化和反序列化数据，这些数据可以保持在进程内。TypeScript 类型需要单独生成（Strapi 有一个 CLI 用于此，v5 已经改进）。

Strapi 5 定价（2026）

计划 价格 座位 资产
Community 免费（自托管） 无限制 无限制
Team $29/月/座位 5-20 100GB
Business $99/月/座位 自定义 500GB
Enterprise 自定义 自定义 自定义

自托管 Strapi 真正免费且运行良好。Cloud 计划增加了托管和高级支持。

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 的定价变得很重要。Growth 计划（$15/用户/月）包括 1M API CDN 请求。听起来很多，直到你意识到一个有 91K 页面产生不错流量的网站很快就会消耗掉这个。我们估计我们的月度 Sanity 账单对 DA 单独来说会是 $300-500/月。Supabase Pro 在 $25/月是一个明确的赢家。

Sanity 对于有 50-5,000 个内容项目，多个编辑需要协作的网站来说很出色。媒体公司的编辑团队喜欢它。

5. Contentful -- 企业最佳选择（需要预算）

我们的判断：最成熟的 headless CMS，但你会为那个成熟付费。

Contentful 从 2013 年以来就存在。它是企业团队默认采用的 headless CMS，是有原因的：内容建模很出色，API 很稳固（Premium 上 99.99% SLA），生态系统的集成无与伦比。

我们为多个企业客户项目评估了 Contentful。内容模型构建器很精美，web 应用中的 API 浏览器对于调试真正有用，webhooks 系统与 Next.js 按需重新验证干净集成。

价格标签

计划 价格（2026） 内容类型 区域 API 调用
Free $0 48 2 1M/月
Basic $300/月 48 6 2M/月
Premium 自定义（通常 $3,000+/月） 无限制 无限制 自定义

从 Free 到 Basic 的跳跃很陡峭。从 Basic 到 Premium 的跳跃是一个悬崖。如果你是一个企业，有 $50K+/年 SaaS 预算，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 上。每篇文章是仓库中带有 frontmatter 元数据的文件：

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

I've been shipping Next.js sites since the Pages Router days...

使用 @next/mdx 或 contentlayer2（社区分支），MDX 与 App Router 本地集成。你的内容 IS 你的代码库。版本控制、分支、拉请求评审——所有你已经知道的工作流。

MDX 何时崩溃

非开发者不能使用它。期间。如果你的营销团队需要发布博客文章，MDX 意味着他们要么学习 Git，要么你为他们构建编辑界面（此时，只使用 Payload）。

MDX 也不能很好地扩展到数千页。在大约 500+ MDX 文件，build 时间开始拖曳，你的 IDE 变慢。对于公司博客或文档网站，它很完美。对于内容平台，它不是。

对于我们的 Astro 开发工作，我们更广泛地使用 MDX，因为 Astro 的内容集合为 Markdown/MDX 内容提供出色的类型安全。

生产指标对比

这是来自我们实际生产部署和评估的数据：

CMS 生产中的页面 语言 Build 时间 月度成本 我们的判断
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+（Basic） 企业最佳
MDX ~60（这个网站） 1 ~30s $0 开发者博客最佳

build 时间列值得解释。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 最好的 headless CMS 是什么？ 基于我们在 253K+ 页面上的生产体验，Payload CMS 3 是 Next.js App Router 的最佳总体选择。其本地 API 消除了网络开销，TypeScript 类型自动生成，管理面板存在于你的 Next.js 应用内。对于超过 10,000 页面的网站，我们推荐 Supabase 作为 CMS 层，配备自定义管理界面。

Payload CMS 真的免费吗？ Payload CMS 是开源的，可以免费自托管，没有功能限制。你需要提供自己的托管和数据库（MongoDB 或 PostgreSQL）。Payload Cloud，他们的托管服务，从 2026 年生产工作负载的大约 $35/月开始。自托管版本没有按座位收费。

我能为 Next.js 使用 Supabase 作为 CMS 吗？ 是的，我们大规模这样做。我们在 Supabase 上运行三个生产网站，总共 253,000+ 页面。当你的内容是结构化数据（档案、列表、产品目录）而不是长篇编辑内容时，它的工作特别出色。主要的权衡是你需要构建自己的内容编辑界面——Supabase 的表编辑器不是为编辑工作流设计的。

Strapi 5 与 Payload CMS 3 对 Next.js 的比较如何？ Strapi 5 用其视觉内容类型构建器在非技术内容编辑中表现出色。Payload 3 用其本地 API 和 TypeScript 原生方法在开发者体验中表现出色。如果你的编辑是开发者，选择 Payload。如果你的编辑是营销人员，选择 Strapi。我们撰写了详细的 Payload vs Strapi 比较，深入覆盖这个主题。

Next.js 最便宜的 headless CMS 是什么？ 自托管 Payload CMS 和自托管 Strapi 都真正免费。Git 仓库中的 MDX 文件除了你的托管外没有成本。对于托管服务，Supabase Pro 在 $25/月 提供规模化最佳价值——我们在单个 Pro 计划上服务 253K 页面。Sanity 的免费层对小项目也很慷慨（最多 3 个用户，500K API 请求/月）。

Contentful 值得 Next.js 项目的价格吗？ 如果你是一个需要 99.99% SLA、与 Commercetools 或 Salesforce 等工具的既定集成，并且你有预算（$300+/月 Basic，$3,000+/月 Premium）的企业团队，Contentful 是值得的。对于初创公司和中型公司，Payload 或 Sanity 以成本的一小部分提供可比的功能。

我应该与 headless CMS 在 Next.js App Router 中使用 ISR 还是 SSR？ 这取决于你的页面数量和内容更新频率。对于 5,000 页面以下的网站，通过 webhooks 的静态生成加上按需重新验证是理想的。对于 5,000+ 页面，动态渲染与 ISR（revalidate = 3600 或类似）更实际——你不能在每次部署时构建 50K 页面。使用 Payload 的本地 API，这个区别更少重要，因为无论哪种方式都没有网络开销。

我可以从 WordPress 迁移到 Next.js 的 headless CMS 吗？ 绝对。我们已经做过多次 WordPress 迁移。典型的路径是：通过 REST API 或 WP-CLI 导出 WordPress 内容，转换和导入到你的目标 CMS，然后在 Next.js 中重建前端。Payload CMS 使这个特别顺利，因为你可以建模你的集合以匹配你现有的 WordPress 文章类型。对于这个流程的更多细节，看我们的 headless CMS 开发解决方案。