无头CMS的优势：灵活性与扩展能力从何而来

同一套内容，可以有不同的呈现方式。每个网站或应用仍然需要分别搭建并接入内容。

设想你要发布一场讲座的信息。标题、照片、简介和开始时间，都需要同时出现在网站和手机应用中。时间变更时，你希望只修改一次。同时，你也希望网站有网站的样子，应用有应用的体验。

无头内容管理系统将两项工作分开：一项是把信息组织好，另一项是决定读者如何看到这些信息。这种分离可能很有用，但具体有多大价值，取决于你要发布什么，以及由谁来搭建和维护两者之间的连接。

“无头”究竟是什么意思？

CMS是供编辑撰写、组织和发布内容的系统。在传统模式下，它也提供模板，将内容转化为网页。无头CMS则把呈现工作交给独立的网站、应用或其他界面。

双方通过API通信。API是一套约定好的方式，让一个软件向另一个软件请求信息。网站可以请求讲座的标题、时间和照片，再将它们放进自己的页面布局中。应用也可以请求同样的信息，以不同的方式排列。

Strapi就是一个例子。它提供编辑界面、内容模型，以及供应用使用的API。API让开发者能够获取内容，却不会替他们设计读者的使用体验。

灵活性在哪些地方有用

一份内容可以用于多个地方。讲座时间可以只存放在一个字段中，而不用复制到几个各自维护的页面里。不过，每个应用仍然需要有效的连接，以及获取更新的机制。旧的缓存页面在刷新之前，依然可能显示过时的信息。

改版不一定意味着重写每一篇文章。如果标题、段落、图片和图注的存储不依附于某一种页面布局，新的前端就可以复用这些内容。要让这种方式发挥作用，内容模型最好能清楚描述各类素材，而不是只存放一大块与特定布局绑定的标记代码。

不同读者可以看到不同的呈现方式。手机屏幕、长篇文章和活动展示屏各有各的需求。同一套底层信息可以支持这三种场景，无须强迫它们套用同一个模板。

这种架构不会替你完成什么

无头架构并不自动意味着速度快。页面可以提前生成，迅速交付给读者；也可能必须经过一连串缓慢的请求，才显示出任何内容。图片、缓存、托管环境和前端的构建方式，依然会影响最终表现。将各部分分开，能让团队选择在哪里改善性能、增加容量，但这些选择仍然需要有人作出并验证。

编辑需要的也不只是一个输入文字的框。他们需要预览草稿、检查链接和图片、发布正确的语言版本，以及恢复早期版本。开发者必须把这些工作接入新的前端。一个在架构图上看起来优雅的系统，仍然可能让日常发布变得别扭。

对控制权也应作同样的区分。API并不能决定谁有权修改规则、你是否能完整导出所有内容，或供应商停止为你提供服务后，你是否还能继续发布。这些问题取决于软件、托管安排、权限，以及是否有切实可行的途径迁往另一套系统。

试做一次完整的发布任务

1. 选择一项有代表性的内容，例如一场讲座，包含照片、日期、简介和第二种语言的版本。
2. 请今后实际负责编辑的人创建草稿，并预览网站和应用中的实际布局。
3. 发布内容，修改时间，再检查各个发布端何时显示修正后的信息。
4. 恢复到上一个版本。导出内容和媒体文件，再确认要在其他系统中使用它们，还需要做哪些工作。

这个小规模试用，比功能清单更能说明问题。它能让你看清，这种架构是否为团队带来了有用的自由，以及日常工作是否容易开展。

根据发布需求选择架构

当多个应用需要使用同一套结构化内容，或读者体验需要大量定制开发时，无头架构可能很合适。对于只有一个发布端的简单网站，将编辑与呈现整合在一起的系统，可能更省事。先看要做什么，再选架构。

如需更全面的比较，请阅读如何根据发布所需的工作量与迁移能力选择CMS。