内容系统为何偏爱EAV模型

“内容系统偏爱 EAV 模型（Entity–Attribute–Value，实体–属性–值）”这个说法，常见于CMS、电商商品、低代码平台、元数据驱动系统等场景。并不是所有内容系统都“偏爱”EAV，但在结构高度不确定、字段频繁变化、需要通用建模的内容系统中，EAV 确实很常见。

下面从“为什么用”和“代价是什么”两方面说清楚。

一、内容系统为什么常用 EAV

1. 内容结构高度不稳定

内容系统往往要管理：

• 文章
• 视频
• 商品
• 表单
• 用户自定义字段

不同内容类型的字段差异极大，而且业务方经常要加字段。

如果用传统表结构：

article(
  id,
  title,
  body,
  author,
  seo_keyword,
  ...
)

每加一个字段就要 ALTER TABLE，在大型系统中成本很高。

EAV 的做法是：

entity = 内容ID
attribute = 字段名
value = 字段值

新增字段只是插入数据，不需要改表结构。

2. 支持“内容类型可配置”

很多内容系统希望：

• 运营自己定义内容模型
• 不用开发介入
• 一个系统支持无数种内容

EAV 天然适合这种元数据驱动思路：

内容类型 = 属性集合
内容实例 = (entity, attribute, value)

低代码、Headless CMS、电商中台几乎都走这条路。

3. 多类型内容统一存储

内容系统经常要存：

• 新闻
• 课程
• 商品
• 活动

它们的字段完全不一样，但都希望：

• 统一检索
• 统一权限
• 统一版本

EAV 可以用一张表“装下所有内容”。

4. 便于扩展国际化和多版本

例如：

• 同一字段多语言
• 同一内容多版本

EAV 很容易扩展成：

(entity, attribute, locale, version, value)

传统宽表反而很难。

二、EAV 不是“银弹”

内容系统“偏爱”EAV，但也常踩坑。

1. 查询复杂、性能差

比如取一篇文章的所有字段：

SELECT attribute, value
FROM eav
WHERE entity = 123

再拼成对象，逻辑重。

聚合查询（如“价格 > 100 的内容”）也很痛苦。

2. 类型安全弱

value 通常是字符串或 JSON：

• 数字、日期、布尔都靠应用层保证
• 容易脏数据

3. 索引和校验困难

• 唯一约束难做
• 必填校验要靠代码
• 联合查询成本高

三、现实中的折中方案

成熟内容系统通常不是“纯 EAV”，而是混合：

✅ 核心字段用宽表

content(
  id,
  type,
  title,
  status,
  created_at
)

✅ 扩展字段用 EAV / JSON

content_attr(
  content_id,
  attr_key,
  attr_value
)

或

content.extra JSONB

✅ 搜索引擎补查询

• MySQL / PG 存
• ES / Solr 查

四、一句话总结

内容系统“偏爱”EAV，本质是因为内容结构不可预测、变化频繁、需要通用建模；
但它用灵活性和扩展性，换来了查询复杂度和性能成本。

如果你愿意，我也可以：

• 用“电商商品”举例对比 EAV vs 宽表
• 画一张 EAV 存储结构图
• 讲什么时候不该用 EAV