Node 的 Headless 出厂没有前台，Java 的 Headless 是从门户里长出来的

Node 系的 headless 是原生的。Strapi、Directus 出娘胎就没前台——内容只走 API，前端爱怎么渲染怎么渲染，"内容也是代码"那一整套玩法都建立在没有包袱的地基上。

Java 系的 headless 是倒着长的。先有门户一体机：页面、权限、工作流、多站点，全在一个 JVM 里跑了好多年；后来客户要移动端、要小程序、要把内容喂给别的系统，才在这套现成系统上开 API 的门。门是后装的，装在原来那面墙上，装好了也能走人，但你一眼看得出哪栋楼是先有墙后开门。

看清这个出身，四家产品的差别就不再是功能表上勾没勾"支持 headless"，而是门装在哪、装成什么样。

四条路，四种装法

dotCMS（2025-02-14 后新版本为 BSL 1.1）：2009 年起家的老牌 Java CMS，走的是把新门和老墙熔成一体的混合路线。官方给页面编辑器取名 Universal Visual Editor（UVE），明确说它是"统一传统与 headless 两种场景的体验"。

业务团队在可视化界面里排页面、走审批，开发者走 REST、Page API（Layout as a Service）或 /api/v1/graphql 单一端点取数据，两边从同一个内容库读写。

CrafterCMS（GPL v3）：把 API-first 写进交付层的代表。官方现行文档写明，Crafter Engine 向开发者提供内容、搜索、GraphQL 等接口，而且 Engine 本身多租户，一个交付引擎可以同时服务多个项目（站点）（本系列番外三，讲一个后台管 N 个站那篇拆过这层）。

它的 GraphQL 省了一桩常见的麻烦：每个项目的 schema 根据 Crafter Studio 里配好的内容类型独立生成，内容类型一改，schema 自动更新，不用手写第二份定义。

Magnolia（社区版 GPL v3）：门是后来加上的，且社区版和商业版分了档。官方 REST 模块随社区版（CE）预装，内置 Delivery API，拿 HTTP GET 就能把 JCR 树里的节点、子节点和查询结果当 JSON 取出来；官方 CLI 的 mgnl jumpstart 提供 headless 模板，选 ce 就能把 Tomcat、Light Module 和 React／Angular／Vue 前端示例一起拉下来，靠 magnolia.config.js 把页面模板映射到前端组件。

但要注意协议与版本的分界：官方 GraphQL 模块只随商业版 DX Core 分发，而且只读、只能查 Content Types 定义的内容（查不了 Pages 和 Stories 应用里的页面，那两样仍走 REST Delivery API）。

Liferay（社区版 LGPL-2.1 或 DXP EULA 双许可）：官方专门立了一章文档叫《Using Liferay as a Headless Platform》，给三条连接路子——符合 OpenAPI 规范的 Headless REST API、GraphQL API，以及 Service Builder 生成的普通 Web/REST 服务。

7.4 及以上版本里，后台把自定义对象（Objects）创建并发布出来，对应的 /o/c/* headless REST 端点就自动生成，配好 CORS 就能让外部 React 应用直接做增删改查。门户那套界面依然在主位，这套 API 的起点就是替原有的 Web 界面提供一份机器可读的对等操作。

为什么 Java 长成了这样

根子还在买家手里有什么。Java CMS 的买家早就有一堆现成系统：ERP、OA、老门户、内部业务台。他们要的往往是从现有内容库里拉数据出来喂新端，API 在这里的角色是接线。

拿 Node 那边"原生无前台"的标准去量，这批产品个个带着老房子的柱子；按接线的标准看，后开的门反而懂墙里原来埋着哪些管线——权限、工作流、审计日志都是现成的，不用前端自己再搭一套。

先开口子，别急着拆

• 团队只有一两个前端、内容就网站一个出口，别拆。拆开后多出来的部署、鉴权、缓存三笔账，全是系统原来替你干的活，单出口场景纯亏。
• 内容要同时喂主站、小程序、App，才值得逐个试这四家：
  • 想要开源且自带自动 GraphQL schema，先看 CrafterCMS；
  • 只用 REST 取 JCR 节点、前端自己映射组件，Magnolia 社区版就能跑通；
  • 已经在用 Liferay 管门户和权限，直接开它的 /o/c/* 端点最顺手。
  • 尽量别自建一层中转 API——你有多少精力搭接口，就会少多少精力发内容。
• 拿不准就走中间路：在现有系统上开只读 API 给新前端，老页面照跑。等新出口用 API 稳稳跑上三个月，再谈全拆。这四家里除了 CrafterCMS 本来就按读写分离拆开，其余三家的官方口子都支持你先这么用。