corpusctl vs WordPress：你得到什么，又放弃什么

corpusctl 没有插件市场——这是一个真实的损失，下文会诚实列出。它取而代之的，是一套由 CI 强制执行规则的模块系统：

• 每个功能都是一个模块：媒体、搜索、webhooks、SEO、GraphQL、导入、分析。
• 模块之间不得互相 import。 服务注册表和事件总线是它们之间唯一的通道，一旦这条规则被打破，pnpm check:isolation 就会让构建失败。
• 移除一个模块不会弄坏构建。这正是这条规则的全部意义所在。

而关闭一个功能不会摧毁任何东西：disabled 会保留数据并在重新启用时继续，uninstalled 会在二次确认后清除数据，而计划降级永远只会把模块设为disabled。

#多个站点，一个面板

WordPress Multisite 是存在的，也能用，但带着运维者都清楚的那些附加条件：跨网络行为异常的插件、一个共享的数据库、一次升级同时落到每一个站点上，以及一套并非为“这位编辑负责品牌一和品牌三、但绝不能看到品牌二”而设计的权限模型。

corpusctl 的多租户在核心之中，紧挨着 auth 和模块注册表：

• 一个面板，无限个 space。
• 一个用户在每个 space 中携带各自独立的角色。
• 隔离由PostgreSQL 行级安全（RLS）强制执行——在数据库中，位于那个存在被遗忘过滤条件的应用层之下。

支持 RLS 的理由很窄：应用层的隔离一直有效，直到那条漏掉过滤条件的查询出现——而那条查询终究会被写出来，由某个赶时间的人，在某个没人仔细审查的模块里写下。RLS 让泄漏在错误发生的层之下就变得不可能。

#结构化内容，以及设计归谁所有

WordPress 的内容是一篇文章或一个页面，再用自定义字段和一个插件来管理它们进行扩展。它能用，但这个模型暴露了它的出身。

在 corpusctl 中没有内置的内容类型。你从面板或 API 定义它们，字段携带角色——title、slug、body——因此系统无需依赖你给它起的名字就知道哪个字段是标题。本地化是逐字段的。每条记录都有版本，旧版本可恢复，发布也可以定时。

在前端，块渲染器带着零默认样式发布。一行 CSS 都没有。每种块类型都可覆盖，未知的块类型会被优雅地跳过而不是抛出异常。核心渲染树与框架无关；React、Vue 和 Next.js 适配器作为薄薄的一层坐落其上。

把这与 WordPress 主题对比一下——后者是一个你先继承、再去覆盖的设计决定。

#继续留在 WordPress 的三个好理由

招聘。 你能在任何城市、以任何预算、下周就找到一个懂 WordPress 的人。这一点你在 corpusctl 上做不到，装作能做到就太傻了。

生态。 表单、预订、会员、电商、SEO 工具、迁移工具——有一个插件已经存在、久经沙场，而且只要 59 美元。针对 API 构建等效功能则是一个项目。

它是免费的。 WordPress 核心一直分文不取。如果预算是那个决定性的约束，那讨论到此为止。

再加上第四个、不那么令人舒服的理由：corpusctl 还很年轻。 SSO 和合同化的 SLA 都还在路线图上，这是“它们还不存在”的委婉说法。没有市场，也没有全球 CDN——边缘缓存是单区域的。如果你的采购清单上有任何一项，那这场对比到此为止。

#诚实的总结

如果一个团队编辑一个站点、生态正在为你做实打实的活儿，或者由预算说了算，那就继续留在 WordPress 上。

如果你在运营多个项目、多个前端，或者一个你已无法审计的插件面——并且你希望读取路径不再是一个缓存难题，那就迁移到 corpusctl。

要迁移吗？ 导入模块会读取 WordPress 的 WXR 导出文件：文章、页面、标签和媒体。字段角色会被映射，正文会被转换成块模型。凡是插件在做的事情，都要预留出实打实的时间——那部分逻辑是不会被导出的。

查看架构 → · 阅读文档 →