Sanity vs Directus：选内容湖还是数据库外壳？

很多搞 Next.js 的朋友在选 Headless CMS 的时候容易陷入误区，觉得它们都一样。其实 Sanity 和 Directus 的底层逻辑完全是两码事，选错了真的会让自己在后续开发中痛苦死。我之前在处理一个对数据主权要求极高的项目时就栽过跟头，当时没想透这一点，结果到后期迁移数据迁移得我想撞墙。

简单来说，Sanity 是一个托管的“内容湖”，而 Directus 是一个给 SQL 数据库套壳的“数据平台”。

数据所有权： Sanity 的数据在它自己的云端，你得依赖它的 CDN 和 API。虽然方便，但如果你接的是那种对数据 residency 有死要求的大客户，这可能是个硬伤。而 Directus 是直接挂在你自己的 Postgres 或 MySQL 上的，数据库在你手里，就算哪天不用 Directus 了，你的数据还是干干净净的 SQL 表，这种掌控感真的太重要了。

Schema 定义方式： 这点是我最上头的地方。Sanity 是 TypeScript 驱动的，Schema 直接写在代码里，跟着 Git 走，PR 审核完直接部署，配合 TypeGen 能实现端到端的类型安全，简直是 Next.js 开发者的福音。Directus 则是在管理后台点点点，或者跑 JSON 迁移文件。如果你习惯了“代码即配置”，你会觉得 Directus 的方式有点啰嗦。

查询语言： Sanity 用的是 GROQ，刚开始学的时候觉得怪，但一旦上手你会发现它处理嵌套文档和关联查询比 REST 舒服得多。Directus 则是标准的 REST 和 GraphQL，没有任何学习成本，但处理复杂关联时还是得回归到 SQL 思维。

如果你现在的情况是：
1. 已经有一个现成的 Postgres 数据库，想快速给它加个管理后台 → 闭眼选 Directus。
2. 追求极速开发、热爱 TypeScript、内容结构经常变动且不需要自己管服务器 → 冲 Sanity。

对我个人而言，如果是快速迭代的初创项目，我会倾向于 Sanity 的灵活；但如果是要给客户交付的商业项目，我绝对选 Directus，因为“数据在自己手里”这一个点就能省掉以后无数的扯皮。