为什么 Domai CMS 比 WordPress 更适合企业网站？

很多做网站的朋友都很熟悉 WordPress。WordPress 最大的优势之一，就是成熟、灵活，几乎什么类型的网站都可以通过主题和插件搭建出来。但如果长期用 WordPress 做企业网站，你应该也会经常遇到一个非常熟悉的操作：安装缓存插件。

比如 WP Super Cache，为什么 WordPress 网站经常需要缓存？因为 WordPress 本质上是一个动态 CMS。用户访问一个页面之后，需要经过 PHP、数据库、主题、插件以及各种 Hooks，最后才生成 HTML。

如果每一次访问都重新执行这一整套流程，服务器自然会产生额外的压力。所以缓存插件做的事情其实很简单：第一次生成页面，保存下来；下一次访问，直接返回已经生成的页面。这样可以减少 PHP 和数据库的重复执行。这个方案当然非常有效。

但我后来慢慢发现缓存能够让页面生成得更少，却不一定能够解决 CMS 本身的问题。

为什么自己开发一个CMS

其实在做 Domai CMS 之前，我自己就长期在研究 WordPress 的性能问题。当年为了实现 WordPress 的纯静态缓存，我还专门开发过一个插件叫Super Static Cache。这个插件累计下载超过 2 万次。

在开发和研究这个插件的过程中，我对 WordPress 的运行方式也有了比较深入的了解。然后我发现一个越来越明显的问题：缓存解决的是“页面生成之后怎么更快返回”，但它并没有改变 WordPress 本身的数据结构、查询方式以及运行机制。

网站规模比较小时，这些问题可能并不明显。但当网站内容越来越多，数据库、索引、查询、插件调用，以及 WordPress 本身长期积累下来的架构，就可能逐渐成为新的瓶颈。

这个时候继续增加缓存，很多问题依然存在。因为缓存优化的是结果，不是产生结果的整个过程。

所以我后来开始想一个问题,如果重新做一个 CMS，不需要继续背负这些历史包袱，而是从数据库、接口、缓存，到整个系统的运行方式，一开始就按照企业网站的实际需求设计，会怎么样？于是，后来就有了 Domai CMS。

从数据库开始设计

我在 Domai CMS 上投入比较多精力的一个地方，就是数据库。我自己长期使用 MySQL，所以在做 CMS 的时候，从数据结构、索引设计、SQL 查询，到实际的数据访问路径，都做了大量调整。不同的数据场景，也会采用不同的处理方式，包括索引优化、查询优化，以及必要时进行分表。

因为对于一个 CMS 来说，数据库就是整个系统的基础。如果底层数据结构不合理，后面即使增加再多缓存，也只是不断给上层打补丁。所以 Domai CMS 的性能，并不是单纯依赖缓存，而是从数据层开始考虑。

缓存本身就是系统的一部分

WordPress 很多时候的使用方式是，先把网站搭起来，再通过插件解决缓存问题。这也是 WordPress 生态灵活的一个体现。但 Domai CMS 从系统设计的时候，就把缓存考虑进去了。哪些数据适合缓存，什么时候应该缓存，内容更新以后，哪些缓存需要失效，哪些数据不应该进入缓存？这些并不是网站开发完成之后再额外解决的问题，而是 CMS 本身的一部分。

对于企业网站来说，这种设计比较重要。因为企业网站通常有一个比较明显的特点是平时访问比较稳定，但内容会长期积累，也可能因为广告、搜索或者某个热点突然出现大量访问。

缓存应该为这样的使用方式服务，而不是网站出了性能问题之后，再去想办法补上。

重新考虑接口和整个运行方式

WordPress 的优势是生态成熟。但生态成熟的另一面，就是历史包袱。十几年积累下来的主题、插件、Hooks 以及兼容性，都需要继续考虑。很多东西即使今天重新来看已经不够理想，也不能轻易推倒重来。

而 Domai CMS 没有这个历史包袱。从第一行代码开始，我就可以重新考虑一个请求到底应该做什么？数据应该怎么查询？模块之间应该怎么调用？哪些事情可以提前完成？哪些事情没有必要在用户请求的时候执行？

所以 Domai CMS 的接口和运行方式，可以直接围绕现在的企业网站来设计，而不是为了兼容过去已经存在的大量插件和开发方式。

但做到这里，我觉得还不够。因为企业网站真正长期使用下来，除了性能，还有一个问题更加实际：运营人员到底好不好用？

企业网站真正消耗的，往往不是服务器资源

服务器不够快，可以升级配置。访问量增加，可以增加缓存。再大的流量，也可以继续扩容。但对于一个长期运营的企业网站来说，我更加关注另外一种成本是人的时间。

WordPress 最初是博客系统，经过这么多年的发展，它已经成为一个非常强大的通用 CMS。但很多企业网站的日常工作，并不是简单地发布一篇文章。可能有不同的运营人员，需要长期维护：产品、文章、案例、SEO、营销活动……这些事情每天都会发生。

如果一个操作需要多几个步骤，单独看可能只浪费十几秒。但一个网站长期运营下来，这些零碎的时间会不断累积。所以我在做 Domai CMS 的时候，除了性能，也一直比较关注两个东西：操作是不是足够简单，以及团队协作是不是方便。

操作上，尽量减少不必要的步骤，让运营人员能够更快完成日常工作。

协作上，则需要考虑不同角色之间怎么配合，包括权限、内容管理和实际运营流程。

因为 CMS 真正长期使用下来，省下来的可能不只是几百毫秒的服务器响应时间，更重要的是节省运营人员的精力，这才是最宝贵的财富。

所以我理解的企业 CMS，并不只是一个“网页内容管理后台”。它应该同时解决三件事情：网站怎么跑得稳定，内容怎么管理，团队怎么协作。

WordPress 是一个非常成熟的通用 CMS，它的优势在于开放、成熟和庞大的生态。而 Domai CMS，是我从企业网站长期运营的角度重新做的一套系统。从数据库、缓存、接口和运行机制，到后台操作和团队协作，我更希望它解决的是企业网站长期使用过程中真正遇到的问题。