AzerothCore学习笔记·数据库06：conditions表——万能胶水串联逻辑
《道德经》里写：“道生一，一生二，二生三，三生万物。”
conditions表就是这样一张表——十几个字段，却把游戏里几乎所有条件判断收纳了进去。接任务要看前置任务，买东西有等级要求，进副本有完成进度限制……这些原本散落在几十个系统里的条件逻辑，被它统一成了几种可组合的类型。
这篇专门聊它。
先看表结构
conditions表只有十几个字段：
| 字段 | 说什么 |
|---|---|
SourceTypeOrReferenceId | 这个条件挂在"谁"身上（任务？物品？NPC？） |
SourceGroup | 分组 ID |
SourceEntry | 具体条目 ID |
ConditionTypeOrReference | 条件类型（声望？等级？完成任务？） |
ConditionValue1~ConditionValue4 | 条件参数 |
NegativeCondition | 是否取反 |
ErrorType/ErrorTextId | 条件不满足时给玩家的提示 |
ScriptName | 数据表达不了时，挂一段脚本 |
两个核心字段
SourceTypeOrReferenceId决定"这个条件挂在什么身上"：
| SourceType | 挂在哪里 | 典型场景 |
|---|---|---|
| 1 | 任务 | 接任务的前置条件 |
| 2 | 对话 | 某个选项只对特定种族显示 |
| 3 | 物品 | 使用物品需要特定等级 |
| 4 | 法术 | 施法需要特定条件 |
| 5 | 地图 | 进入地图的条件 |
| 14 | 成就 | 成就完成条件 |
ConditionTypeOrReference决定"判断什么"：
| ConditionType | 判断什么 | 典型参数 |
|---|---|---|
| 1 | 玩家等级 | 最小/最大等级 |
| 2 | 玩家职业 | 职业掩码 |
| 5 | 已完成任务 | 任务 ID |
| 8 | 声望等级 | 阵营 ID + 最低声望 |
| 29 | 技能等级 | 技能 ID + 最小等级 |
每种条件类型的 Value1~4 含义不同：类型=8（声望）时 Value1 是阵营ID，类型=1（等级）时 Value1 是最小等级。字段含义是"动态的"。
一个具体例子
假设有一个任务，要求：
- 玩家等级 ≥ 20
- 已完成前置任务（ID=132）
- 声望达到"尊敬"（声望等级 4）with 阵营（ID=72）
在conditions表里是三条记录，都指向同一个任务ID：
SourceType=1, SourceEntry=133, ConditionType=1, Value1=20, Value2=255 SourceType=1, SourceEntry=133, ConditionType=5, Value1=132 SourceType=1, SourceEntry=133, ConditionType=8, Value1=72, Value2=4三条是与的关系——全部满足，条件才通过。有一条不满足，任务 NPC 的对话框里不会出现这个任务，ErrorTextId指向的提示文字会告诉玩家哪里不满足。
为什么叫"万能胶水"
没有这张表时，任务系统要写一套条件判断（等级、前置、声望），物品系统要写一套（使用条件、职业限制），对话系统再写一套……代码里到处是重复的 if 判断。
有了conditions表之后，所有系统共用同一套读取逻辑——过滤SourceType=X AND SourceEntry=具体ID的记录，用 ConditionType 判断"满足什么条件"。新增一种条件类型，只需要加一个 ConditionType 定义，所有系统自动支持。
这就是"万能胶水"：它不绑定任何特定业务，任何表、任何记录都可以挂条件。
代价：可读性
conditions表的代价很明显：数据可读性极差。
看一行数据，光看字段值完全读不懂——必须结合代码里的 SourceType 和 ConditionType 常量定义，才能还原出业务语义。这也是为什么 AzerothCore 的 dbdocs 系统对这张表格外重要。
这个问题的根源在于：通用设计牺牲了可读性。conditions 表的设计者选择了"让所有系统共用同一张表"，代价是这这张表本身失去了具体的业务语义——它变成了一套"条件 DSL"，需要查文档才能读懂。这在软件设计里是常见的权衡：通用性和可读性往往不能兼得。
条件判断 + 行为脚本
conditions表负责"能不能做"，smart_scripts表（篇3 提过）负责"做了之后发生什么"。
两个表配合，撑起了 AzerothCore 里绝大部分的游戏逻辑——这也是为什么 AzerothCore 里写 C++ 代码的机会不多，大部分逻辑用这两张表就能配出来。条件判断和游戏行为，两套数据驱动系统相互配合，构成了 AzerothCore 的核心逻辑层。
这套逻辑，同样体现在 AzerothCore 的节日活动系统里——game_event系列表用叠加层的思路，在不改任何基础数据的前提下，让节日活动结束后世界自动恢复原状。