张超的博客

我做了6年CMS，把答案推翻了三遍

文章不是技术选型指南，是一个人在资源有限、需求多变的环境里，三次重新定义”问题是什么”的记录。每次重定义，都意味着一次完整的技术栈洗牌。

六年前我接手了一个烂摊子——1台 2 核 4G 的服务器，11 个不同行业的独立站点，没有运维，没有前端，后端只有一个人。

我是那个后端。

版本技术栈结果
V1CI4 + Vue2 + PHP-FPM初代 CMS，能用但不好用
V1.5模板过度封装定义错了问题，干废了
V2Webman + Vue2 内嵌100ms 动态渲染，一个人全栈
V3Webman API + Vue3/Next.js SSR前后端完全解耦

这六年我推翻了三遍自己。每次推翻的理由都一样——约束条件变了，架构就得跟着变。

CMS 到底在解决什么问题？

你问一个刚入行的工程师：CMS 是什么？

“内容管理系统，管文章和页面的。”

这个答案没错。但想了十年之后，我觉得它只说了一半。

另一半是——CMS 不是用来”管理内容”的，是用来”让内容被高效地生产、组织和消费”的。

区别在哪？区别在于：你是站在”管”的角度，还是站在”用”的角度。

为什么我敢这么说？因为我就是那个被逼着去想的人。几台服务器，2 核 4G，没有运维，用不起 K8s。我是 CMS 的开发者，我同事和客户是使用者。资源就这么多，我得站在更高的地方看清整个棋盘——不然走一步错一步。

这个答案，我在 6 年里推翻了三遍。每次推翻，都意味着一次完整的技术栈洗牌。

为什么不用 WordPress？

你大概会问：有 WordPress 为什么不用？

我用过。而且我做的第一个定制化 CMS，就是因为客户对 WordPress 彻底失望了才开始的。

问题在哪？两点。

一个是插件越多越慢。 WordPress 的生态靠插件，但插件装到十几个，整个系统就臃肿得不行。你想优化？难。插件之间互相踩脚，你根本不知道瓶颈在哪。

另一个更本质——它是基于 PHP-FPM 跑的。 每次请求都要重新加载一遍资源，OpCache 能救一点，但救不了命。慢就是慢，根上的问题。

当然这不是说 WordPress 不行。它现在发展得很好，仍然市场占有率第一，7.0 全面接入了 AI，把我有想法但还没做的很多实践已经加进去了——这点我服气。

但回到我的牌桌：

  • 不是 1 个站，是 11 个独立域名、不同行业的站点
  • 整个后端就我一个人
  • 每个站点的 SEO 策略、模板、业务逻辑都不一样

成熟 CMS 产品都在赌那”60% 通用需求 + 30% 插件生态”。可当你那 10% 的定制需求得改核心代码的时候——不如自己写一个。至少你知道每行代码是干啥的。

选型不是比功能多，是比谁在你的约束条件下效率最高。

这不是”Not Invented Here”综合征。这个判断框架，后面还会反复出现。

第一次翻牌：一个人怎么管 11 个站？

一个人，没有任何帮手，怎么搞定 11 个域名不同的学校官网？

方案是什么？

那时技术栈挺素的——CI4 做后头，Vue2 搭前台，PHP-FPM 吭哧吭哧跑着。

数据库我分了五层：

一圈搭下来，95% 的内容都能在后台搞定——域名路由到各个学校，3 套模板来回调，SEO 各配各的。该干的都干了。

但那个后台，我自己都不想打开。

功能都在，就是不知道怎么用。一堆字段列在那，你得猜。后来才想明白——好的产品是你打开就知道点哪儿的，不用人教。我那会儿做不到。不是 Vue2 的问题，是我自己前端底子薄，有些交互想做但做不出来。

留了什么坑？

更大的隐患在后面——后端高度耦合。

所有逻辑都揉在一起，功能看着都有，但想拆出一套可复用的框架来？难。后来想给新项目用，发现几乎搬不动。

这就是约束——能力有限的时候做出来的东西，一定是各种妥协堆出来的。

第二次翻牌：问题是定义错了，还是技术选错了？

做了几个站，基本不维护了。不展开了——结论就是四个字：干废了。

根因是什么？

复盘的时候，表面看是框架选错了。但再往深挖一层——我根本就没搞清楚要解决什么问题就动手了。

当时我想让后端能更好地控制 CMS 页面，就把 Vue 工程拆成了 PHP 模板组合渲染。

结果呢？模板过度封装，同事学不会。

不是因为选了个”坑”的框架，是因为选框架的时候，我连自己在解决什么问题都没想通。追了”更新的技术”，不是”更匹配约束条件的技术”。

问题定义错了，后面所有”解决方案”都是在掩盖这个错误。

回头去看”为什么不用 WordPress”那一节——那个判断框架如果早两年存在，这代失败品根本不会出现。

第三次翻牌：不靠前端，一个人能做出好产品吗？

V1 的后台我自己都不想用，V1.5 又干废了。但我得继续做 CMS，不能因为前端能力不够就停。

那怎么办？换个思路——既然前端不是我强项，就别硬搞前后端分离那一套，V1.5 封装过度，那我就模块化。

我选了 Webman，一个 PHP 常驻内存框架，彻底跟 FPM 说再见。前端怎么办？Vue2 继续用，直接内嵌到 PHP 模板里，但不对 PHP 模版进行过度封装，而是灵活组合。后端一个人就能调样式、改交互，省掉一个前端工程师是其次，省掉沟通成本才是大头。

有人会说：这不主流吧？

是。但它是我当时能走的最快路径。

开发效率上去了之后，我又加了一个东西——内置 JSON 对象编辑器。以前 CMS 的字段是固定的，标题、正文、图片各占一栏。现在你可以在编辑器里定义任意数据结构，CMS 自动适配输入界面。从”固定字段”到”灵活结构”，这一跳很重要——后面所有复杂站点的数据模型都是靠这个撑起来的。

然后就是性能。那会儿我脑子里只有一件事：让站点页面变快。

选了 Webman 之后，缓存分了三层叠着用——查询缓存、HTML 渲染缓存、OpCache 脚本缓存。三层叠穿，动态页面响应压到了 100ms 以内——说实话我测出来的时候自己都有点不信。

这一代验证了两件事：PHP 可以很快，一个后端自己也能扛住 CMS。

但更重要的是——这次我先定义清楚了自己要解决什么问题（一个人全栈，效率优先），再选了方案。跟 V1.5 的顺序正好反过来。

AI 能写代码了，然后呢？

V2 做到 100ms 以内的时候，我以为 CMS 这条线基本到头了。直到 AI Agent 开始能写前端代码。

回头一看，V2 架构接不住。Vue2 内嵌在 PHP 模板里——AI 擅长生成的是独立的 Vue3 组件、React 组件，它不认识我这套 PHP 套壳的写法。想让 AI 帮我写前端，我得先让架构认识 AI 的语言。

这个判断一出，整个架构都得动。

要不要前后端彻底分离？以前不舍得。因为后端一个人干全栈，拆了反而增加沟通成本。

但 AI 改写了这个等式

AI 对我来说最大的冲击，不是它能写代码——是它把学习门槛和隐形知识门槛一起削平了。

以前我不敢碰前端工程化那一套：Webpack、Vite、SSR、TypeScript 编译——试错成本太高，踩一个坑半天出不来。现在 LLM 能帮我填这些坑了。我只需要关注应用逻辑、UX、测试，配置和脚手架交给 AI。

这意味着什么？意味着我可以选最主流的框架，不用再委曲求全选”一个人能搞定”的方案。

LLM 的训练语料里 React 占大头，但我最后选了 Vue3 + Next.js 的 SSR。不是因为 React 不好——是因为我熟悉 Vue，这样才能把 Agent 的效能发挥到最大。Next.js 的 SSR 把前后端分离后最头疼的 SEO 问题也解决了。

方案定下来之后，Webman 那一层我顺手把所有功能拆成了组件——JWT、CORS、动态路由、参数校验、统一返回值、微信登录、API 审计、标准 CRUD、多租户隔离、OSS 接入。不是为了代码好看，是为了让 AI 写前端的时候，调这些接口像搭积木一样。

到这一步，CMS 变成了真正的 Headless：Webman 只出 API，前端可以换 Vue3 也可以换 React，CMS 管理端独立部署。前后端完全解耦。

这个架构，我一点没犹豫。

因为我看清楚了——这不是一次普通的技术升级。是我对”CMS 在解决什么问题”这个定义的第三次重写。

这一次，变量变了：从”适不适合人做”变成了”适不适合 AI 做”。

跟开篇那句话一脉相承——自研 CMS 不是因为它比 WordPress 功能多，而是约束条件变了，架构就得跟着变。只不过这次的条件，不是服务器配置，不是团队规模，是 AI。

现在回头看，就是三件事

V1.5 那摊子烂在那里的时候，我每天都在想：到底哪错了？明明技术选型的时候都认真比过的。

后来想明白了——不是在比参数，是在看它跟我手里的牌匹不匹配。手里就一张 2，你非要凑同花顺，能不输吗？这个认知从”自研还是买”那段就开始长了，长到 V1.5 才算彻底落地。

V2 选非编译 Vue2 的时候，说实话犹豫过。那会儿前后端分离是政治正确，我一个搞非编译内嵌的，说出去都不好意思。但那条路对我来说就是最快的——省掉沟通成本、省掉编译等待，一个人全部搞定。后来我越来越相信一个事：

好架构不一定是最标准的，但一定是最匹配约束的。

V3 是最有意思的。AI 来了之后我突然发现，以前那个决策框架好像又要改了——不是”这东西一个人干不干得了”，是”这东西 AI 干不干得了”。变量换了，答案也得换。

三件事，看着不大，每条都是实打实换来的：

  • 牌不好的时候别瞎打——认清约束比选对框架重要
  • 别为了”主流”走弯路——真正的成本往往不是技术，是沟通
  • 变量变了就认——别抱着旧架构不放，AI 时代有 AI 时代的答案

CMS 教我的，不只是 CMS

最后发现我一直在做的就一件事：让信息更好地被组织、管理和消费。

但 CMS 是个挺传统的产品，正因为传统，它逼你在框架受限、资源有限、需求多变的夹缝里建立起自己的一套打法。

多租户、组件化、三层缓存、性能调优、反复修正问题定义、匹配约束做决策——这些东西后来在我搭个人 Agent 系统、搞工业控制系统的时候，全用上了。

这套东西，比 CMS 本身值钱多了。

十几年下来，其实就攒了三样东西：怎么搭架构、怎么设计产品、怎么让系统自己跑起来。

只不过恰好，承载这些东西的产品叫 CMS。