内容仓库框架、Wiki、静态生成和自研，怎么选

正篇（二）讲了国产 Java CMS 为什么少，把还活着的几个说完。这篇给会写代码的人。

先给一个对照，说清楚 Java 生态缺了什么。Node.js 那边有一整类轻量 CMS，主打"内容也是代码"：内容存在 Git 仓库里，前端自己写，改完 push 就算发布（Decap、Tina、Sveltia 那一路）。这类产品的好处是轻、快、可控、不绑数据库。Java 生态里这一层是真空——没有一个像样的、活着的"内容存 Git/文件、轻量部署"的 Java CMS。

原因不复杂，三条：
一是形态。Java CMS 全是重量级服务，JVM 应用加内容仓库，动辄要中间件和数据库，天然不是"一个目录丢上去就能跑"的形态，跟轻量文件驱动是两路人。
二是客户。Java CMS 的买家是公司，公司要的是开箱即用的企业功能，不是"前端你自己写"的半成品。
三是替代品。真想要轻，Java 开发者不会等别人造轮子——自己写一个，比在生态里找还快。

所以 Java 开发者想要"代码化的内容管理"时，现实里只有下面四条路。

一、内容仓库路线：Apache Sling 和 Jackrabbit Oak

这是 Java 里最"正统"、也最硬核的一条路，属于框架层，不算成品 CMS。

Java 内容仓库（JCR）是老标准，把内容当成一棵树来存和查，天然适合文档、页面这种层级结构。这条路上有两个 Apache 项目：

• Apache Jackrabbit：JCR 标准的实现，其中 Oak 是新一代内容仓库实现，底层存储可以换成 MongoDB 或关系数据库，支持查询和版本控制；
• Apache Sling：在内容仓库之上做 REST 化——URL 直接映射到内容节点，资源即内容，Java 里最顺的"内容即资源"模型。

这两个项目都是 Apache 顶级项目，Apache 2.0 许可，也都还活着（Sling 14／2026-03，Oak 2.8.0／2026-10）。它们最出名的用户是 Adobe Experience Manager（AEM）——Adobe 的商业企业 CMS 就是建立在 Sling 和 Oak 之上的，Java 系商业化最成功的那套东西，底座是这两个开源项目。

走这条路的代价很直接：没有后台界面，没有模板系统，一切都是你自己从 API 层往上搭。实际上真正这么干的基本是 AEM 的实施商和少数想完全掌控内容后端的团队。对大多数团队来说，这条路的正确用法是"理解它，然后不自己造"。

二、wiki / 协作路线：XWiki

XWiki 是 Java 的 wiki 引擎，按 LGPL-2.1 发布，最新正式版 18.8.0／2026-09，16.x 和 17.x 的 LTS 分支也还在出维护版。Java 开源内容类项目里，它是难得的常青树。

它表面是 wiki，实际比 wiki 多走了一步：官方有个叫"App Within Minutes"的功能，可以在界面上直接搭小型应用——列表、表单、报表，数据存在 wiki 页面背后的结构里。做内部知识库、部门协作站、文档中心，XWiki 顺手得很，权限、版本历史、全文搜索都现成。

它不算传统 CMS：没有为"对外网站"设计的那套模板和发布流，做对外官网不如去用 Halo 或 Liferay。但如果你想在 Java 系里找一个"能装就给团队用、还带内容管理"的东西，XWiki 是这个位置最没坑的选择。

能对上号的没几个：Confluence 闭源按人头收费；eXo 的 Wiki 组件 2022 年弃用归档；JAMWiki 上游仓库没了，GitHub 上只剩 2016 年的镜像；还活着的轻量替代是 Apache JSPWiki（Apache-2.0，最新正式版 3.0.0／2026-08，今年 8 月刚发过大版本），可它是纯 wiki 引擎，结构化数据和 App Within Minutes 那一套都没有。Liferay 也带 wiki 模块，但那是门户平台的附带件，不在这个位置上。

三、静态站路线：JBake 年更，Roq 绑在 Quarkus 上

Java 这边能叫上名的静态站生成器，就那么几款，还各有各的问题。老资格是 JBake，把 Markdown 渲染成 HTML 发布，思路和 Jekyll、Hugo 一样，MIT 许可。它的正式版一度停了四年多：上一个正式版 v2.6.7 在 2021 年 5 月，v2.7.0 等到 2025 年 12 月才出来，隔四天又放出一个 early-access 预发布，此后仓库再没有推送。

唯一真正在更新的是 Quarkus Roq，Quarkiverse 官方的静态站生成器扩展，Apache-2.0，最新正式版 2.2.0／2026-10，版本号基本按月走。站点本身是个 Quarkus 应用，既能整站导出成静态文件，也能直接当服务跑；内容支持 Markdown、AsciiDoc，带 FrontMatter 头，数据文件用 JSON 和 YAML。代价是绑死在 Quarkus 上，团队不在这个技术栈里就用不上。

其余的死掉一批、凉掉一批：Orchid 和 SkyDocs 已经归档，Griffin 2023 年后没了推送，StaGen 的最后正式版停在 2014 年，jssg 十二年没动过，也没标协议。Java 开发者想生成静态站，基本直接去用别家的工具（Hugo、Hexo 这些），不会为了"用 Java"在这一堆里翻。

所以这条路线在 Java 生态里约等于不存在：能用的就一个年更的和一个绑 Quarkus 的，社区和模板都搬去了 Hugo、Hexo。要用 Java 又想纯静态，自己写个渲染器并不难，但那又是自研的范畴了。

四、自研路线：Java 团队的默认答案

把上面三条看完你会发现，Java 团队做内容型网站，挑到最后往往是自己搭——Spring Boot 起个服务，文章存数据库或 Markdown，后台自己写个简单的，或者干脆用现成的无头服务。这不是 Java 开发者懒，是生态逼的：成品 CMS 要么太重（Liferay、Magnolia 那类全家桶），要么许可证要算账（dotCMS 的 BSL），轻量舒适区又没人做，自研反而是性价比最高的选择。

如果走自研，几个决定提前想清楚，能少走弯路：

• 内容存哪：数据库（方便检索、后台好写）还是 Git/Markdown（方便代码评审、迁移简单）；
• 后台要不要：团队内部用可以只留 API 加简单管理页，给业务同事用就得好好做权限和编辑体验；
• 发布怎么走：纯静态生成、还是服务端渲染、还是前端单独部署走 API——这个决定越早定越省钱；
• 多语言、图片处理这些"看似简单"的功能，往往比正文功能还费时间，能借现成服务就借。

Java 开发者的选择题其实不难：要省事，个人内容站去用 Halo，公司门户去用 Liferay，headless 场景回正篇（一）按许可证算账；要掌控，Spring Boot 起服务自己搭。中间那条"轻量、可二次开发、有人维护"的舒适区，Java 里没人修，别去翻了。

想理解 Java 内容管理的正统模型，去读读 Sling 和 Oak 的文档，比你盲选任何一个 CMS 都有用。