AzerothCore学习笔记·数据库08：技能数据设计——为什么没有spell_template
有一个东西，WoW 里人人都会用，但你几乎从没见过有人抱怨它"设计得太烂"——
那就是技能。
法师的寒冰箭，点出来会飞向目标，命中了造成伤害，暴击了伤害翻倍，有碎冰天赋时对冻结目标额外溅射，配合冰冷智慧还能叠冰指 buff。一套combo，涉及施法、伤害计算、天赋联动、触发机制——四个系统同时运转，没有哪个玩家觉得"寒冰箭怎么这么难理解"。
但如果你去翻 AzerothCore 的数据库，会发现一个有意思的事：没有spell_template表。
creature_template有一张，item_template有一张，偏偏技能数据散落在七八张spell_*表里。为什么？
spell_dbc：技能的底座
技能数据最核心的一张表是spell_dbc。
这个名字本身就是答案——DBC 是暴雪客户端用的二进制数据格式，World 库里这张表其实就是从官方 DBC 文件导入的原始数据。AzerothCore 基本没改，保持原样。
spell_dbc有两百多个字段，涵盖了技能的全部基础属性：
- 施放时间、冷却、能耗
- 施法距离、有效目标
- 效果描述（每级最多3个效果：Effect1/2/3）
- 状态标志（Attributes、AttributesEx……大量位掩码，控制技能的各类行为开关）
两百多个字段，够宽了吧。但这不是全部。
技能的特殊性：它不是一个对象，是一套效果组合
回到篇5说的设计决策：宽表适合"读多写少、配置驱动"的场景。怪物模板适合宽表，因为一只怪物的属性集合是相对稳定的——它不会因为天赋不同而多出一套效果，也不会因为装备不同而改变施法距离。
技能不一样。拿寒冰箭来说：
- 基础效果：
spell_dbc定义了施放动作 + 伤害数值 + 暴击倍率 - 天赋联动：点出"碎冰"天赋后，对冻结目标施放寒冰箭，会额外触发一个溅射伤害——这个触发关系存在
spell_linked_spell表里 - 被动叠加：冰冷智慧被动，寒冰箭有概率给目标附加"冰指"buff——这也是一条
spell_linked_spell记录 - 等级链：寒冰箭有多个等级，从1级到13级，每级伤害递增——等级链关系存在
spell_ranks表里
三件事，三个表。spell_dbc定义基础，spell_linked_spell定义触发，spell_ranks定义等级。
如果硬塞进一张spell_template宽表，这张表会变成什么样？两百多个基础字段，加上条件性极强的触发字段、天赋字段、等级字段——大量字段只在特定天赋组合下有意义，空值极多，维护成本极高。
这不是设计失误。技能不走宽表路线，因为技能的本质是多维度效果组合，而不是单一对象的属性集合。
spell_ranks：等级链
spell_ranks表解决的是技能等级的问题。
寒冰箭1级、2级、3级……一直到13级。每升一级，施法时间、伤害值、能耗都可能变化。传统方案是每个等级单独一行数据，但 AzerothCore 用等级链把它们串起来：
spell_id=133, first_rank_id=142, second_rank_id=143, third_rank_id=144……这套链式结构支撑了三个功能：
- 学习逻辑：学会低等级，高等级自动解锁
- 效果计算：代码读链动态算属性加成，不需要每级单独配
- 天赋联动：部分天赋效果只对特定 rank 生效
等级链的存在让技能数据不需要为每个等级写完整的一行——定义基准值，其他等级通过关系推算。
spell_linked_spell：触发链
这张表是技能系统里最容易被忽略的一张表，但它极其重要——它把"施放 A 技能时，可能附带 B 效果"这件事从 C++ 代码里搬到了数据库。
格式很简单：
| 字段 | 说什么 |
|---|---|
spell_id | 触发源技能 |
spell_trigger | 被触发的目标技能 |
type | 触发类型（0=施放时，1=命中时，2=进入目标区域……） |
举个例子：圣骑士的"命令圣印"施放时，自动触发"命令圣印审判"的伤害。代码不需要硬编码这个逻辑，spell_linked_spell里插一条记录就够了。改触发关系只需要改表，不需要改代码。
这就是数据驱动设计——把行为关系外置化。
spell_proc：触发机制
触发机制（Proc System）是 WoW 里大量机制的基础：平砍暴击触发、闪避后反击、受到治疗后有概率叠增益……
spell_proc表配置每个技能的 Proc 参数：
- ProcFlags：什么事件能触发（暴击、闪避、格挡、施法完成……）
- ProcChance：触发概率
- ProcCharges：触发次数上限（0=无限）
- ppmRate：每分钟触发次数
最后这个 PPM 值得多说一句。传统做法是"每次暴击有10%概率触发"——但快速武器攻击频率高，同等触发概率下实际触发次数远多于慢速武器，引发职业平衡灾难。PPM 的思路是"平均每分钟触发N次"，触发频率与攻速解耦，快速武器和慢速武器在相同 PPM 下实际触发次数接近平衡。WoW 主流的触发配置方式已经全面转向 PPM。
技能为什么比物品难改
回头看，技能数据分布在七八张表里，每张表负责一个维度：基础属性、等级链、触发关系、Proc 机制、区域联动……
对比一下item_template就明白了。物品的属性集是封闭的——护甲值、耐久度、随机词缀——这些字段基本固定，组合在一起描述一个物品的所有属性，不需要跨表协同。
技能的行为是开放的——同一个技能，被天赋影响、被装备加成、被目标状态触发——不同维度叠在一起才构成完整行为。维度多，关联多，每改一个维度都可能影响其他维度。这就是为什么 WoW 里技能系统的调试比物品系统复杂得多——出问题的地方往往不在当前维度，而在跨维度的交互里。
回头看 AzerothCore 的技能数据结构，有一条主线很清晰：没有宽表，是因为技能天然就是多维度的。七八张spell_*表，每张表负责一个维度，维度之间相对独立。这套设计让技能行为可以被灵活组合——天赋可以改触发关系，装备可以改触发概率，不需要动基础数据本身。
这条主线，往前接篇7的叠加层思路，往后连系列二的 AI 系统——那里会讲到spell_scripts表怎么把技能和 C++ 脚本处理关联起来。