一款契合 Next.js 而非与之对抗的无头 CMS

两次 HTTP 请求,都来自缓存。读取客户端不携带任何令牌,因为没有什么需要授权:内容早已公开,也早已构建完成。

清单是分片的,因此一个拥有一万条条目的空间,下载的仍然是一个小文件,而不是一个不断膨胀的索引。

#草稿预览:人人都最后才接、事后又后悔的那一环

编辑期望能看到尚未发布的内容。在 Next.js 中,这意味着一个路由:它校验一个密钥、启用草稿模式,然后重定向。

在大多数手写实现里,它也是一个安全漏洞。两个常见的错误:

用 === 比较密钥。 字符串比较会在第一个不同的字符处短路,从而通过时序泄露密钥的长度和位置。请使用恒定时间比较。

重定向到 slug 所说的任何地址。 ?slug=https://evil.example.com 会把你的预览端点变成你自己域名上的一个开放重定向——对钓鱼很有用,而且会被扫描器发现。

@corpusctl/next 会同时处理这两点:

密钥比较是恒定时间的;绝对 URL、协议相对路径以及反斜杠花招都会被拒绝;重定向目标是 CMS 确认过的值——而不是请求所提供的值。decision.reason 是一个稳定的、机器可读的值,你可以把它映射到你自己任何语言的文案上。

#渲染层,也就是时间真正花掉的地方

获取内容是一个下午的事。把它变成带样式的标记才是整个项目,也正是大多数无头 CMS 落地卡壳的地方。

如果客户端库自带带倾向性的标记,你会把那段时间花在覆盖它上。如果它什么都不带,你会把那段时间花在构建它上——但至少你是在构建,而不是在对抗。

corpusctl 有意选择了后者。块渲染器出厂时零默认样式——一行 CSS 都没有。每一种块类型都可被覆盖。未知的块类型会被优雅地跳过,而不是抛出异常,因此当内容模型跑在前端前面时,页面是降级,而不是崩溃。

核心渲染树与框架无关;React、Vue 和 Next.js 适配器只是其上薄薄的一层。背后的原则是:如果渲染某种块类型需要框架专属的代码,那么抽象就放错了位置。

#重新验证与 webhook

即便内容是预先构建的,你通常仍希望前端知道有东西变了——去刷新一个列表、预热一个路由,或清掉下游的某个缓存。

corpusctl 会在发布、取消发布、更新和删除时触发 webhook。投递被放在一个持久化队列中,带指数退避与抖动,因此接收端宕机一个小时也不会丢失事件。载荷带时间戳并经 HMAC 签名,而且端点 URL 在被调用之前就会做 SSRF 检查——内网地址在注册时即被拒绝。

#一份诚实的候选清单

Payload —— 单个 Next.js 产品、配置即代码、自托管体验舒适。请注意,在被 Figma 收购之后,Cloud 已不再接受新项目。

Strapi —— 社区规模遥遥领先(约 2,800 个 Stack Overflow 问题),自托管免费。Strapi Cloud 则按项目计费。

Sanity —— 该品类中最好的编辑体验、GROQ,以及按席位计费。

corpusctl —— 预构建的不可变读取、不计量、在一个面板中管理多个项目、零样式渲染器。社区较小;没有应用市场;边缘缓存是单区域的。

#这件事出错的三种方式

1. 内容仅在客户端渲染。 你选择 Next.js 是为了服务端渲染,结果却在 useEffect 里拉取数据。搜索引擎看到的只是一个空壳。
2. 预览在切换上线后才接。 编辑在第一天就发现自己看不到自己的草稿。请先把它接好。
3. 没有做出缓存决策。 每一次页面访问都打到 CMS 上,而账单或延迟会在第二个月冒出来。

相关阅读: 什么是无头 CMS? · 无头 CMS 的 SEO · corpusctl 对比 Payload