corpusctl 对比 Strapi:一个面板、N 个项目、无请求计量器

#100,000 个请求比听上去要小

Starter 的额度换算下来大约是每天 3,300 个请求。

一个典型页面会由不止一次调用渲染而成——条目本身、导航、相关文章。按每次页面浏览三次调用计,你会在大约每天 1,100 次页面浏览时触顶。然后再加上爬虫、预览请求、在线监控,以及部署期间忘了缓存的前端。

在那之后,每 25,000 个请求花费 $1.50。这不是个大数字。它只是一个恰恰在一切顺利时就上涨的数字,而且是一个你无法预测的数字,因为它是由陌生人驱动的。

而在 Starter 上,实例会在空闲时休眠。那意味着安静一段时间后的第一个请求会遇到冷启动——而这正发生在你花钱买“快”的那个营销站点上。

corpusctl 没有请求额度,因为已发布的内容从不由 API 供给。一旦点击发布,就会把渲染好的内容写入对象存储中一个不可变的、哈希寻址的文件,并刷新一份清单。访客的客户端在本地把 slug 解析到某个清单分片,再从 nginx 边缘缓存中获取那个不可变的地址——可缓存三十天,因为同一个地址永远不可能返回不同的内容。

两次 HTTP 请求,都来自缓存。都不会到达 API。都不会到达 PostgreSQL。根本没有什么可计数的。

#自托管 Strapi 是免费的——而这才是诚实的对比

如果你自托管 Community 版,上述一切都不适用,而你应该认真权衡这一点。那时你对比的就是运维量。

自托管的 Strapi 给你 CMS。其余的东西你仍需自己拼装和运维:数据库、媒体的对象存储、如果需要的搜索后端、用于 webhook 投递的队列、缓存、反向代理,以及跨主版本的升级路径。

corpusctl 把整套东西作为一次部署交付——PostgreSQL、Valkey、Typesense、Garage、nginx——并在 Enterprise 套餐上提供自托管安装。每个组件都运行在你自己的基础设施上。整个技术栈中没有按用量计费的第三方服务;这是一个产品约束,而非当下的定价决策。

这两者哪个更好,完全取决于你是否想自己拥有那部分运维量。有些团队确实想,那他们就应该选 Strapi。

#只会在第四个月才显现的那些部分

关闭一个功能。 在 corpusctl 中,每个功能都是一个模块——媒体、搜索、webhook、SEO、GraphQL、导入、分析。disabled 会保留数据并从中断处恢复;uninstalled 会清除它,并会确认两次。套餐降级会把模块设为 disabled,而且绝不删除数据。这是代码库里的一条规则,而非一项支持政策。

客户端库强加的东西。 corpusctl 的块渲染器出厂时零默认样式——一行 CSS 都没有。任何块类型都可被覆盖,而未知的块类型会被跳过而不是抛出异常。核心渲染树与框架无关;React、Vue 和 Next.js 适配器只是其上薄薄的一层。一个自带带倾向性标记的 CMS 并没有解决“渲染 API 响应”这个问题,只是给它换了个名字。

Webhook 投递。 投递被放在一个持久化队列中,带指数退避与抖动。如果你的接收端宕机一个小时,事件在它恢复时仍然在那里。

错误码。 每个 API 错误都携带一个永久码(CORPUS_E_9127)和一个文档链接。消息被翻译成七种语言;码则不会。客户端代码绑定的是码,因此改进一条消息永远不会破坏集成。

#Strapi 胜出的地方

社区。 大约 73,000 个 GitHub star 和 2,800 个 Stack Overflow 问题,对比 corpusctl 小得多的影响面。当你在凌晨两点撞上一个边界情况时,有人早已把它写下来的概率,在 Strapi 上要高得多。这是一个真实的优势,而且会复利。

插件生态。 Strapi 有一个插件和提供商的市场。corpusctl 则没有——集成是针对 webhook 和 API 编写的。

成熟度。 Strapi 已经迭代了好几个主版本,拥有庞大的安装基数。corpusctl 则很年轻;SSO 和合同 SLA 在路线图上,这是客气的说法,实际意思是它们尚不存在。

永久免费、自托管。 Community 版分文不取,一直如此。这一点很难反驳,我们也不打算去试。

#诚实的总结

如果你想免费自托管、看重庞大的社区,或需要一些否则就得自己编写的插件,那就选 Strapi。

如果你在一处运行多个项目、想要由数据库强制执行的隔离,并且希望一张不会因一篇文章表现好而波动的账单,那就选 corpusctl。

Strapi Cloud 价格取自 strapi.io/pricing-cloud,时间为 2026 年 8 月 17 日,不含当地税费。价格会变——引用前请核对。

查看架构 → · 阅读文档 →