无头 CMS

传统的内容管理系统（如 WordPress、Drupal）把后端内容管理与前端页面渲染耦合在一起，编辑在后台写好内容，系统通过内置的主题模板直接输出 HTML。这种方式在单体站点场景下开箱即用，但当业务需要把同一份内容分发到 Web、移动 App、小程序、IoT 设备等多个端时，模板化的前端就成了限制。

无头 CMS（Headless CMS） 应运而生。它去掉了前端「头部」（head），只保留后端的内容存储、编辑与协作能力，对外通过 API 把结构化内容交付给任意前端。本文梳理无头 CMS 的核心概念、架构特征、典型场景与选型要点。

什么是无头 CMS

无头 CMS 是一种仅含后端的内容管理系统，主要充当内容仓库（content repository）。它把内容创作、管理、组织（taxonomy）等能力与内容展示彻底分离：编辑人员通过管理后台维护内容，前端开发者则通过 API 拉取这些内容并用任意技术栈渲染。

与无头 CMS 相对的，是耦合式（coupled）和分离式（decoupled）架构。传统 CMS 属于耦合式，后端与前端是一体的；无头 CMS 属于 decoupled 架构的一种特化形式——后端与前端完全独立运行，后端不关心前端用什么框架，前端也不依赖后端的模板引擎。

核心特征

• API 优先：内容通过 REST、GraphQL 等 API 暴露，前端可以按需消费。
• 多渠道交付（Omnichannel）：同一份内容可同时服务于网站、移动应用、IoT 设备等。
• 前后端解耦：前端可选用 React、Vue、Next.js、Astro 等任意框架,后端独立演进。
• 结构化内容：内容以字段化的数据结构存储（而非 HTML 片段），便于复用与查询。
• 云优先（可选）：许多商业方案提供多租户 SaaS,具备高可用、可扩展、托管升级等能力。

与传统 CMS 的差异

简言之,传统 CMS 更适合单一站点的快速上线,无头 CMS 更适合多端、长周期、内容复用需求强的项目。两者并非互斥,部分平台（如 WordPress）也通过插件同时提供 REST API 与 GraphQL,具备一定的「无头化」能力。

典型使用场景

• 多端发布：同一份内容需要同时推送到 Web、iOS、Android、小程序等。
• Jamstack / 静态站点：在构建期通过 API 拉取内容,生成静态页面,获得极致性能与安全性。
• 单页应用（SPA）与服务端渲染（SSR）：React/Vue 等现代前端项目以 API 为数据源。
• 国际化与多语言：内容与展示分离后,多语言版本的管理与分发更清晰。
• 内容中台：作为企业内部的内容枢纽,供多个产品线复用。

常见方案选型

无头 CMS 方案大致分为三类：开源可自托管、商业 SaaS、面向特定场景的混合方案。

开源自托管

• Strapi：基于 Node.js 的开源无头 CMS,用 TypeScript 构建,MIT 许可。可视化定义 Content Type 后自动生成 REST 与 GraphQL API,内置角色权限、媒体库、i18n 与草稿/发布。支持 SQLite、PostgreSQL、MySQL、MariaDB 等数据库。
• Directus：在任意 SQL 数据库（Postgres、MySQL、SQLite 等）之上自动生成 REST 与 GraphQL API,并附带可视化管理后台,既可做无头 CMS,也可做后台面板。
• Ghost：Node.js 写就的开源发布平台,官方自称「最流行的开源无头 Node.js CMS」,内置 Content API,常用于博客、会员订阅与 Newsletter 场景。

商业 SaaS

• Contentful：典型的 API 优先内容基础设施,提供 Content Delivery API（CDA,只读、CDN 加速）与 Content Management API（CMA,读写、需鉴权）,面向企业级内容运营。
• Sanity：以 Content Lake 存储结构化 JSON,提供自家查询语言 GROQ 与 GraphQL,搭配可定制的 Sanity Studio 编辑器,实时性较强。
• Storyblok：以可视化编辑器（visual editor）与组件化内容模型见长,API 优先,同时兼顾编辑体验与开发者灵活度。

用 Strapi 快速起步示例

以 Strapi 为例,创建一个新项目：

npx create-strapi@latest my-strapi-project
cd my-strapi-project
npm run develop

启动后访问管理后台,通过 Content-Type Builder 可视化定义内容模型（如「文章」包含 title、body、cover 等字段）,保存后 Strapi 会自动生成对应的 REST 与 GraphQL 端点。例如以下 GraphQL 查询可获取已发布的文章列表：

query {
  articles(status: PUBLISHED) {
    documentId
    title
    createdAt
  }
}

随后,任意前端（Next.js、Astro、移动端等）都可以通过该端点拉取内容进行渲染。

取舍与注意事项

引入无头 CMS 并非银弹,选型与落地时需要权衡：

• 前端工作量大：失去主题模板后,页面、组件、SEO、预览等都要自行实现。
• 内容预览体验：编辑人员在草稿态下看到的与最终页面可能不一致,需要额外搭建预览方案。
• 托管与运维：开源自托管意味着要自己处理部署、备份、升级、安全补丁；商业 SaaS 则按用量计费,长期成本需评估。
• 学习曲线：内容建模、API 设计、权限模型对团队都是新的认知负担。

在内容复用度高、多端交付、团队具备前端工程能力的场景下,无头 CMS 的解耦红利会显著大于其复杂度成本;反之,简单的单体站点,传统 CMS 依然是更务实的选择。

参考

• Headless CMS — Wikipedia
• Strapi 官方仓库（GitHub）
• Strapi 官方文档
• Contentful 帮助中心
• Sanity 官网
• Storyblok 官网
• Directus 官方仓库（GitHub）
• Ghost 官方仓库（GitHub）
• 内容管理革命：无头 CMS 推荐（掘金）