在无头、耦合和混合 CMS 架构之间做出选择

传统的耦合式 CMS 既存储内容，也负责渲染展示内容的页面。编辑在一个知道页面外观的系统中工作，开发人员在该系统内构建模板。无头 CMS 负责存储和管理内容，并通过 API 对外提供；而“头”（网站、移动应用、自助终端屏幕）是一个独立的应用，自行获取内容并渲染。

两者的全部差异都源于这种分离。无头架构的所有优点（速度、灵活性、现代前端框架、多渠道发布）都由此而来，所有缺点也同样如此。内容变成了结构化数据而不再是页面，这带来了灵活性，但也意味着必须有人设计这套结构。渲染成为组织自己的应用，这意味着其团队要对性能、无障碍和可用性负责。

无头架构最有说服力的场景，是内容需要在多处呈现。例如：一个集团拥有十几个品牌网站，共用产品信息、法律文本和新闻稿；一家企业将同一内容发布到网站、移动应用和门店显示屏；一个组织使用三种语言服务客户，需要译文与原文保持同步。在这些情况下，将内容作为支持多语言的结构化条目只存储一次，再通过 API 分发，可以省去大量复制工作，也避免了随之而来的不一致。

无头架构也适合拥有强大前端工程团队的组织：团队已在使用 React 或类似框架，并希望把网站当作产品来经营，采用与其他应用相同的流水线、测试和部署实践。如果具备这样的团队，内容 API 比模板系统更为契合。

开发人员通常偏爱无头架构：简洁的 API、由自己掌控的前端、没有遗留的模板语言。编辑往往没那么热衷，而他们的体验决定了内容能否顺利发布。在耦合式 CMS 中，编辑能看到页面的最终效果，把组件拖到位置上，然后点击发布。在纯无头架构中，编辑在表单中填写字段，并相信前端会正确渲染。用未发布内容预览真实页面的功能需要自行开发；如果 CMS 不提供排期、工作流和审批，这些也都需要自行开发。

在选择无头架构之前，先访谈编辑人员。了解他们每周发布多少页面、是自己搭建落地页还是请开发人员协助，以及编辑时是否需要看到页面效果。如果市场部门需要在没有工程支持的情况下搭建和修改页面，组织就需要一个在 API 之上提供真正可视化编辑的 CMS，或者采用混合模式；无论哪种情况，都应为预览和页面组装工具预留预算。

在电子商务领域，这一选择的影响最为深远。无头架构将内容平台与独立的商务引擎、搜索服务和支付服务商组合在一起，即所谓的可组合技术栈。对于需求独特且团队能力较强的零售商，这能获得各领域最佳的能力，并可自由替换任一组件。但对大多数组织而言，这也意味着要自行负责商品目录、内容、购物车、结算和促销之间的集成，并协调多家供应商的产品路线图。

一体化平台让内容与商务共用一套数据模型和管理界面，省去了上述集成成本，通常也能为商品运营人员带来更好的日常使用体验。关键在于，商务需求是否特殊到值得自行组装技术栈。在许多组织中，答案是否定的。

无头网站通常速度很快，但速度来自前端的构建方式，而非架构本身。只有当页面预先渲染或在边缘渲染、采用积极的缓存策略，并在构建时或请求时获取内容，而不是每次访问都在浏览器中获取时，网站才会快。如果无头网站的每个组件都从浏览器调用内容 API，其速度可能还不如被它取代的耦合式 CMS。配置得当、部署在 CDN 之后的耦合式 CMS 同样能非常快速地提供页面。

应将性能作为一项有明确预算的需求（首次内容呈现时间、最大内容元素、可交互时间），并要求每个候选架构说明如何满足该预算，而且要在移动网络而非办公网络条件下验证。

当内容只用于一个网站、编辑需要自行组装页面、工程团队规模较小或需兼顾其他系统，而且上线速度比架构上的可选性更重要时，应选择耦合式或混合式 CMS。大量企业营销网站、内部网和服务门户都属于这种情况。混合式 CMS 既能渲染页面，又能通过 API 对外提供全部内容，既满足当下的网站需求，也为日后增加应用或第二个渠道留有余地。

当内容需要分发到多个目的地、译文和品牌网站必须在众多站点间保持一致、强大的前端团队希望掌控用户体验，或者商务需求要求采用可组合技术栈且组织已做好运营准备时，应选择无头架构。这一决定取决于组织自身，而非技术的名声。