Collection / Single / Component 怎么选？Strapi 字段大全一篇讲透
做 Strapi 项目，最容易让人纠结的事情之一，就是建模。
文章要建成 Collection Type，还是 Single Type？导航栏和页脚能不能共用一个模型？页面里的图片、文字、按钮，究竟应该拆成字段，还是做成 Component？
一开始觉得差不多就行，等页面多了、内容复杂了，才发现模型设计不合理：字段重复、数据难维护、前端查询越来越复杂，甚至改个公共模块都要折腾半天。
这篇文章就把 Strapi 最核心的三种内容结构，以及常用字段和 Dynamic Zone 一次讲清楚。示例基于 Strapi 5。
一、先搞懂三种核心结构
Strapi 的 Content-Type Builder 主要提供 Collection Type、Single Type 和 Component 三种结构。它们解决的问题并不一样。
1. Collection Type：一类内容，多个条目
适合所有需要持续新增、查询和管理的内容。
例如设计公司官网中的文章、项目案例、服务项目：
-
Article：新闻、博客文章
-
Project：设计案例、作品集
-
Service：服务项目
-
Team Member：团队成员
假设你创建一个 Article 模型：
| 字段 | 类型 | 示例 |
|---|---|---|
| title | Text | 如何设计一个好网站 |
| slug | UID | how-to-design-a-website |
| cover | Media | 文章封面 |
| publishedAt | DateTime | 发布时间 |
| category | Relation | 技术分享 |
创建完成后，就可以不断新增文章，而不需要每次创建新的模型。
在 Strapi 后台中，它通常会表现为一张可管理多条记录的列表。
判断标准：如果这种内容未来可能有很多条，就优先考虑 Collection Type。
2. Single Type：只有一份的内容
Single Type 适合一个站点只需要维护一份的配置或页面。
例如：
-
首页配置 Home
-
关于我们 About
-
网站设置 Site Setting
-
联系方式 Contact
以 Site Setting 为例：
| 字段 | 类型 | 示例 |
|---|---|---|
| siteName | Text | My Design Studio |
| logo | Media | 网站 Logo |
| favicon | Media | 浏览器图标 |
| footerText | Text | 版权所有 |
| contactEmail | hello@example.com |
这些内容通常不需要维护几十条记录，只需要一份当前生效的数据。
这里有个容易误解的地方：Single Type 不代表只能有一个字段，而是这种内容类型只管理一个条目。
比如首页可能包含标题、Banner、介绍、推荐项目等多个字段，但首页本身仍然可以是 Single Type。
不过，如果你的网站有多个独立页面，或者需要动态创建页面，就不应该把所有页面都塞进一个 Single Type。
3. Component：可复用的字段组合
Component 不是独立的内容条目，而是一组可以重复使用的字段结构。
例如，网站里经常出现这样的组合：
-
图片 + 标题 + 描述
-
姓名 + 职位 + 头像
-
按钮文字 + 跳转链接
-
地址 + 电话 + 邮箱
如果每个模型都单独创建这些字段，不仅重复劳动，后续修改也很麻烦。
这时就可以创建 Component。
例如创建 shared.button：
| 字段 | 类型 |
|---|---|
| label | Text |
| url | Text |
| variant | Enumeration |
然后在首页、服务页面、文章页面中复用它。
Component 还支持两种使用方式：
-
Single Component：只允许放一个组件实例。
-
Repeatable Component：允许放多个相同结构的组件实例。
比如一个页面只有一个主按钮，可以使用 Single Component；如果需要配置多个快捷入口，就可以考虑 Repeatable Component。
需要注意，Component 必须被其他内容类型或组件引用，不能像 Collection Type 一样独立创建、管理一批内容。
二、Strapi 字段大全：常用字段怎么选？
模型确定之后，接下来就是字段设计。字段类型选得合适，后续 API 返回的数据也会更符合业务需求。
| 字段类型 | 主要用途 | 使用示例 |
|---|---|---|
| Short Text / String | 短文本 | 标题、姓名、标签 |
| Long Text / Text | 较长的纯文本 | 简介、备注 |
| Rich Text | 富文本内容 | 文章正文、详细介绍 |
| 邮箱 | 联系邮箱 | |
| Password | 密码类数据 | 特定的密码字段 |
| UID | 唯一标识或 URL 标识 | slug |
| Enumeration | 固定选项 | 状态、类型 |
| Boolean | 是 / 否 | 是否推荐 |
| Integer | 整数 | 排序值、数量 |
| Big Integer | 大整数 | 较大的整数值 |
| Float | 浮点数 | 评分、测量值 |
| Decimal | 精确小数 | 需要精确小数表达的数值 |
| Date | 日期 | 活动日期 |
| Time | 时间 | 每日营业时间 |
| DateTime | 日期和时间 | 发布时间 |
| Timestamp | 时间戳 | 特定时间记录 |
| Media | 图片、视频、文件 | 封面、附件 |
| Relation | 关联其他内容 | 文章关联分类 |
| Component | 可复用的字段组合 | 按钮、作者信息 |
| Dynamic Zone | 多种组件组成的灵活区域 | 页面内容区 |
| JSON | 灵活的 JSON 数据 | 特殊配置 |
| Custom Field | 扩展字段类型 | 颜色选择器等 |
其中，Media、Relation、Component、Dynamic Zone 是 Strapi 建模中比较有特色的字段类型。
另外，Rich Text 的具体编辑能力和返回结构可能因 Strapi 版本及编辑器配置而不同；JSON 虽然灵活，但不建议把所有业务数据都装进去，否则字段校验和内容管理会变得困难。
几个容易选错的字段
Text 还是 Enumeration？
如果内容由编辑人员自由填写，使用 Text；如果只有几个固定选项，例如 draft、published、archived，可以考虑 Enumeration。
Text 还是 UID？
如果字段需要作为内容的 URL 标识，例如 /articles/how-to-design，优先考虑 UID。实际使用时，还要注意标识冲突及修改 URL 后的跳转策略。
Relation 还是 Component？
如果关联对象需要独立管理、被多处引用，就更适合 Relation；如果只是当前内容的一组固定属性，则通常更适合 Component。
例如，文章的分类适合关联 Category，而文章中一个只使用一次的提示框，可以直接设计成 Component。
三、Dynamic Zone：为什么它是页面搭建神器？
假设你要做一个设计公司官网。
首页需要 Banner、项目展示、服务介绍；关于我们页面需要团队介绍、公司历程；服务详情页又需要图片、文字和 FAQ。
如果为每种页面创建大量固定字段，模型很快就会变得臃肿。
例如：
bannerTitle、bannerImage、serviceTitle、serviceImage、teamTitle......
页面越多，字段越多。更麻烦的是，内容顺序也难以灵活调整。
Dynamic Zone 的作用，就是允许编辑人员在一个内容区域里自由组合不同类型的 Component，并调整顺序。
例如，创建以下组件：
-
sections.hero：主视觉区域 -
sections.text-image：图文介绍 -
sections.project-list：项目列表 -
sections.faq：常见问题
然后在 Page Collection Type 中添加一个 Dynamic Zone 字段 sections，允许使用以上四种组件。
编辑人员就可以按照页面需要组合内容：
首页：
Hero → Project List → Text Image → FAQ
关于我们：
Hero → Text Image → FAQ
服务详情页：
Hero → Text Image → Project List → FAQ
不必为每种页面创建一套完全不同的字段。
需要注意，Dynamic Zone 里的组件字段名和类型要保持兼容，尤其不要在不同组件中定义同名但类型不一致的字段。
Dynamic Zone 适合什么场景？
适合官网页面搭建、落地页、营销页面、活动页面等内容结构灵活的场景。
但它并不是万能的。
如果一个内容结构长期固定，使用普通字段或 Component 会更清晰；如果内容需要独立的查询、分类、权限或复用关系，则应考虑单独建模。
Dynamic Zone 的自由度越高，前端渲染逻辑也越需要做好类型判断。
四、实战：设计公司官网应该怎么建模？
假设我们正在开发一个设计公司官网，可以先从下面这套结构开始：
| 模型 | 类型 | 作用 |
|---|---|---|
| Article | Collection | 文章列表 |
| Project | Collection | 设计案例 |
| Service | Collection | 服务项目 |
| Page | Collection | 可扩展的普通页面 |
| Home | Single | 首页固定配置 |
| Site Setting | Single | Logo、页脚、全站配置 |
| Button | Component | 公共按钮 |
| Hero | Component | 主视觉模块 |
| Text Image | Component | 图文模块 |
| FAQ | Component | 常见问题模块 |
其中，Page 可以包含标题、slug 和 sections Dynamic Zone；Home 则可以使用固定配置字段，也可以包含适量的 Dynamic Zone，用于自由组合首页模块。
如果 FAQ 需要在很多页面复用，且每个问题需要独立管理，那么可以进一步把问题设计成 Collection Type，再通过 Relation 关联；如果 FAQ 只是页面内部的一组内容，Component 通常更简单。
建模时不要急着追求复杂。先根据真实业务创建最小可用结构，后续再按需要扩展。
五、几个建模避坑建议
1. 不要把所有东西都建成 Collection。
独立内容才值得独立建模，简单的字段组合优先考虑 Component。
2. 不要把所有页面都建成 Single Type。
Single Type 适合唯一内容；需要不断新增的页面通常应使用 Collection Type。
3. 不要把所有东西都塞进 Dynamic Zone。
固定结构优先使用普通字段或 Component，只有确实需要灵活排列时才使用 Dynamic Zone。
4. 不要忽略字段修改的影响。
Strapi 的字段重命名可能涉及旧字段删除和新字段创建，已有数据需要提前评估和备份。修改生产模型前，务必先在测试环境验证。
5. 不要把模型设计和 API 查询割裂开。
Relation、Media、Component 和 Dynamic Zone 在 API 查询时可能需要额外配置 populate。模型建得再漂亮，如果没有规划好前端所需的数据结构，接口调用依然可能很复杂。
写在最后
记住这四句话，基本就能解决大多数 Strapi 建模问题：
-
多条独立内容，用 Collection Type。
-
全站唯一配置，用 Single Type。
-
可复用的字段组合，用 Component。
-
需要自由组合、调整顺序的页面模块，用 Dynamic Zone。
这套思路并不复杂，关键是先想清楚内容的业务关系，再决定字段怎么组织，而不是看到一个字段就急着创建一个模型。
下一篇，我们继续解决一个实际问题：中英双语网站怎么做？Strapi i18n 从配置到 API 取数。