Angular/React前端对接API后端与对接Headless CMS的区别是什么？

两种模式看起来都是前后端分离、前端通过API拿数据，核心差异落在后端能力定位、耦合度、适用场景三个维度：

1 本质定位不同 #

• 前端对接普通后端API/传统CMS模式：这类模式里的后端（含传统CMS）本质是全栈一体化设计，传统CMS比如WordPress、Drupal原生自带前端渲染能力，默认通过后端模板生成页面，开放API只是附加的拓展能力，并非核心设计目标。后端除了内容存储外，往往还耦合了大量业务逻辑、用户系统、甚至前端渲染规则。
• Headless CMS模式：原生为前后端分离场景设计，从架构层面就砍掉了前端视图层（也就是「无头」的含义），核心能力只有两块：给运营用的可视化内容管理后台（含内容录入、版本控制、权限分配等），以及标准化的内容输出API（REST/GraphQL都有），没有任何自带的前端渲染逻辑，所有展示层完全由开发者自主选择技术栈实现。

2 开发耦合度不同 #

• 普通对接模式：如果对接传统CMS的API，内容结构、返回字段、权限规则大多和CMS原生设计强绑定，要自定义内容结构要么需要装第三方插件，要么需要修改CMS后端源码，拓展成本很高。如果对接自研后端API，虽然可以完全自定义逻辑，但需要自行开发全部内容管理后台功能，重复造轮子的成本很高。
• Headless CMS模式：和前端技术栈完全解耦，不需要修改后端代码，只需要在Headless CMS的后台可视化配置需要的内容模型（比如文章、商品、Banner等内容的字段类型、校验规则），配置完成后自动生成对应的API，前端不管用Angular、React、Vue还是小程序、App都可以直接调用，也不需要自行开发内容管理后台，运营人员可以直接用系统自带的后台录入管理内容。

3 适用场景不同 #

• 普通对接模式更适合业务逻辑重、内容属性弱的项目，比如内部管理系统、交易型平台等，这类项目内容管理只是附属功能，自定义业务逻辑需求多，自研后端或者改造传统CMS能满足更复杂的业务定制需求。
• Headless CMS模式更适合内容属性强、多端发布需求多的项目，比如品牌官网、博客、内容型小程序、多端同步的内容平台等，不需要投入精力开发内容管理后台，只需要聚焦前端展示层开发即可，上线速度快、维护成本低。

常见误区：只要前后端分离用API对接内容数据就属于Headless CMS模式，这个判断是错的，核心要看后端是否是原生无视图层、专门面向内容管理、支持可视化配置内容模型的系统，普通自研后端或传统CMS的API对接不属于Headless CMS模式。

内容的提问来源于stack exchange，提问作者learntofix