为什么又写一个 CMS

现成的 CMS 不是太少，是太多。WordPress、Ghost、Halo、Strapi、Directus、Statamic……每一类需求都有好几个成熟选项，而且都比我一个人写的好。

那为什么还是写了 Lumo？

因为我在实际操作中反复碰到几件具体的事，而现成方案要么不做另一件事，要么做得不一样。这篇只讲那几件事。

一、部署摩擦是真实成本

一个建站系统从「能用」到「用上」之间的距离，几乎全部消耗在部署上。

PHP 体系要一个运行环境，Node 体系要一个进程管理器加一次构建，Java 体系要一个 JVM 参数调对的运维。容器把这件事包装得好了一些，代价是你得先有一个能跑容器的地方——而很多人的服务器上只有一个面板和一块 SSD。

这些摩擦单独看都不大，但它们会相乘：每一步都需要一个决定，每一个决定都需要一个人来做。 当这个人是「顺手搭个站」而不是「专职运维」时，摩擦就直接等于门槛，或者等于放弃。

所以 Lumo 的第一条设计约束是：发布产物是一个可执行文件。 后台前端、内置主题、数据库迁移、时区数据全部嵌进去，目标机器上不需要 Go、不需要 Node、不需要 Docker，只需要一个 PostgreSQL。

这条约束改变了很多下游决定，比如为什么前端产物必须经 go:embed 嵌入（而不是拷一个目录上去），为什么构建时必须先出前端再编译后端。这些代价是真的，我在另一篇里写了。

二、后台和前台应该用不同的渲染策略

后台是一个应用：状态多、交互密、局部刷新频繁。单页应用是这个场景的正解。

前台是一堆文档：可被搜索、可被引用、要在弱网下打开、要能在十年后的浏览器里渲染。服务端渲染的 HTML 是这个场景的正解。

奇怪的是，很多 CMS 对两者用同一套策略。要么整个前后台都是 SPA，于是前台页面的可抓取性要靠额外的预渲染补救；要么前后台都是服务端渲染，于是后台每次点击都整页刷新。

Lumo 里这两件事是分开的：后台是嵌进二进制的 React 单页应用，前台是 Go 模板渲染的 HTML。访客侧的关键表单——登录、注册、找回密码、账户页——是原生 POST，关掉 JavaScript 也完整可用。

这条决定的收益不只是 SEO。它意味着前台没有「水合失败」这种故障模式，也意味着主题作者写的是模板而不是组件。

三、主题不该是插件

把主题做成插件看起来更统一，但两者面对的约束完全不同。

插件是功能：装一次、配置一次、之后基本不动。给它一套清单、一个设置界面、一份生命周期就够，出了故障也是可以隔离的。

主题是表现：做得好的主题作者会反复调整它，站长会想改一行文案就看见效果。要求他为一个模板改动走一遍构建、打包、上传，是把开发的摩擦转移给了使用者。

所以主题在 Lumo 里是「文件 + 约定」而不是「包 + 运行时」：一份 zip 解压到 data/themes/，改模板点一下重新加载就生效。必需模板只有四个，缺哪个都整页回退到内置主题——一个半成品主题不该让站点露出破绽，而「这个页面我不会做」是主题作者最正常的处境。

插件则是另一条路，而且目前刻意保守：第一期是纯声明式的，不执行任何代码。声明式插件能覆盖「加一段统计脚本」「挂一个友情链接页」这类需求，而它的安全模型简单到可以一句话讲完。WASM 运行时会在后面几期接上——一个能执行任意代码的插件系统必须先有可靠的沙箱，而可靠的沙箱不该赶。

四、生态需要先把授权说清楚

这一条是写代码之前必须想明白的，否则代码写完也没人用。

AGPL 是传染性很强的协议。如果没有额外声明，「一个主题算不算 Lumo 的衍生作品」会是个没有答案的问题，而任何人拿它做商业产品之前都得先请律师——那等于这个生态不存在。

所以项目附带了一份插件与主题接口例外条款：仅通过插件或主题接口交互的独立作品，不因该交互本身被视为衍生作品，你可以用任何条款开发、分发和销售它，包括专有条款。这份例外不可撤销。

配套的是「程序本体免费、靠主题市场抽成」这个模式。它不是为了显得高尚，而是一个更简单的算术：如果使用者的规模本身要收费，那就永远有动力做功能分档和用量限制，而这个动力最终会扭曲技术决定。 我不想在「这个功能放免费版还是专业版」上花任何时间。

我不主张的

• 不主张它更快、更省资源。 静态二进制省的是运维的心，不是 CPU。
• 不主张功能比谁多。 上面列的东西大部分竞品都有，有些做得更好。
• 不主张它适合所有人。 需要多租户、需要可视化拖拽搭建、需要从别的系统一键迁移的，现在都不该选它。
• 不主张你现在就上生产。 它还没经过生产环境检验，也没有自动化测试。这一条我在路线图里写得很直白。

如果你要的正好是「拷一个文件过去就能跑的、前台是 HTML 的、主题可以自己随便改的 CMS」，那 Lumo 是冲这几件事来的。