-
buo4 技术教程组 用户
官网要一份内容，App 要一份，小程序还要一份。改一次文案，三个地方各发一遍。
问题不在于"系统不够多"，而在于内容和页面绑死了。Strapi 这类无头 CMS 的做法是：内容只维护一份，通过 API 给所有前端用。
内容和页面绑死之后
传统 CMS（比如直接建站的那种）把内容和页面模板放在一起，好处是上手快，代价是：
- 内容只能在那一套页面里用，换个终端就得重来
- 前端技术栈被固定住，想换框架基本等于重做
- 改文案要登录后台改模板，改版风险高
- 内容没法给 App、小程序、第三方渠道复用
Strapi 怎么用
内容与展示分离。 内容在 Strapi 里维护，通过 API 提供给任意前端——官网用 Next.js、App 用原生、小程序另接，都读同一份内容。
可视化建内容模型。 不写代码就能定义"文章有哪些字段、什么类型"，改结构也不用迁移数据库。
自动生成 API。 REST 和 GraphQL 都支持，模型建好接口就有了，不用额外写后端。
媒体库管理。 图片、视频集中管理，可以存本地也可以接对象存储。
权限与角色。 内容编辑、审核、发布按角色分权，多人协作不会互相覆盖。
可自托管。 Docker 或 Node 部署，内容数据在自己手里。
什么时候该用，什么时候不该用
| 场景 | 是否合适 |
|---|---|
| 多终端共用一套内容 | 非常适合 |
| 需要自定义内容结构 | 非常适合 |
| 只想快速搭个博客 | 偏重，可考虑更轻的方案 |
| 强依赖可视化建站 | 不合适，它不负责页面 |
关键认知：Strapi 不管你的页面长什么样。它只负责内容的结构、存储和分发，页面完全由你的前端决定。想要"拖拖拽拽就能建站"的话，它不是那类工具。
上手流程
- 部署 — 本地用脚手架初始化，服务器用 Docker 部署
- 建模型 — 在管理后台定义内容类型和字段结构
- 接前端 — 调 REST 或 GraphQL 接口拿内容，前端自由呈现
一点提醒
前期把内容模型想清楚。 模型改起来不难，但改完前端也要跟着改，尤其是内容已经积累之后。
媒体存储早期就要规划。 默认本地存储在多实例部署时会出问题，量一大建议直接接对象存储。
权限别默认全开。 API 默认可能允许公开读取，正式上线前务必检查角色的权限配置。
对"一份内容供多个终端"这个需求，Strapi 是目前最主流也最成熟的自托管方案之一——搭建一次，之后所有终端都受益。