1. 从"skills"到技能树：一次摸清技能系统的设计与实现

拿到"skills"这个标题的时候，我第一反应是：这大概又是一个游戏项目的技能系统模块。做开发的这些年，我接过不少类似的需求——什么"角色要有技能"、"做个天赋树"、"解锁加点的功能"，听着简单，真正落地才发现里面全是细节。技能系统不像登录注册那样有标准答案，它牵扯到数据结构设计、数值平衡、前端交互、存档兼容，甚至还有服务端校验的边界问题。这篇就围绕技能系统的设计与实现，把我实际做过的方案、踩过的坑、调过的数值，整整齐齐地拆开讲一遍。适合正在做游戏前端、角色养成类Web应用，或者刚接触技能系统、想找个完整参考的同学。

先交代一下我这边的情况。某项目是一个Web端角色养成的小项目，前端用的TypeScript加Canvas渲染，后端是一套常见的Restful API。需求方提了一堆花里胡哨的想法：被动技能、主动技能、技能联动、战斗结算要吃到技能加成。听上去不算复杂，但是一旦把"技能"抽象成一个可配置、可扩展、可持久化的系统，就要先想清楚一件事——你的技能系统到底长什么样。

1.1 核心需求解析：技能系统到底在解决什么问题

技能系统的本质，是把"角色拥有什么能力、能力什么时候生效、生效产生什么结果"这三件事，从业务代码里抽离出来，变成一个可配置的规则集合。换句话说，游戏里那些花花绿绿的技能图标只是表皮，底下实际上是三张表：技能本身、技能效果、效果触发的条件。

我在动手设计之前，先把需求拆成了四层：

• 技能定义层：技能的名字、图标、描述、品级、所属职业、解锁位置。
• 成长数值层：技能等级、升级消耗、成长曲线、解锁前置条件。
• 效果结算层：技能提供了什么加成，是给角色加攻击还是给敌人上减速，数值是多少，持续多久。
• 表现与交互层：前端技能树的展示、加点动画、红点提示、等级进度反馈。

这四层对应到代码里，就是四个独立的模块。千万不要混在一起写，不然到了后期，策划想加一个新技能，你得上千行代码里翻找——血泪教训。

1.2 为什么大多数技能系统都"长成一个样"

市面上角色养成项目的技能系统，不管是暗黑类的技能树、MOBA里的技能面板，还是卡牌游戏里的技能升级，它们的底层结构惊人地相似。原因很简单：技能系统的核心矛盾是"有限资源下的选择与成长"，也就是玩家手上的技能点永远是稀缺的，怎么分配、什么时候能解锁什么技能，这本身就是玩法的驱动力。所以一套通用的技能系统，天生就带着"节点 + 依赖关系 + 成长曲线"这三样东西。

搞清楚这一点，你就能想通为什么技能树那么流行——因为它把"选择"可视化成了"路径"。玩家看到的不是一堆冰冷的数值，而是地图一样的成长路线：走到这里才能点那个，点满前置才能解锁大招。这种结构代码实现起来也不复杂，本质上就是一棵多叉树。

注意：如果你做的项目只需要几个固定主动技能、没有分支选择，那就别硬造一棵技能树。用一张平铺的技能表加一个等级字段就够了。复杂度要用在值得的地方。

2. 数据结构设计：先选好模型，再写功能

我在这个项目里，技能系统的第一步是设计数据结构。这一步做得越扎实，后面的坑越少。技能系统最忌讳的就是需求一变，数据结构推倒重来。因为技能相关的数据常常会被存档、被服务端校验、被客户端渲染，一旦结构变了，三处地方要同步改，还牵扯老玩家的存档兼容问题，非常痛。

2.1 技能定义的存储结构

技能定义我用了"配置 + 实例"分离的模式。配置文件里记录的是某个技能"是什么"，玩家角色身上保存的是"学到了什么程度"。

技能配置（SkillConfig）典型结构如下：

interface SkillConfig { id: string; // 技能唯一标识，比如 "fireball_01" name: string; // 显示名称 icon: string; // 图标路径 description: string; // 技能描述 maxLevel: number; // 最大等级 unlockRequire: { // 解锁前置条件 skillId?: string; // 需要某个技能已解锁 minLevel?: number; // 需要角色等级达到多少 }; effectIds: string[]; // 技能绑定的效果ID列表 upgradeCost: { // 升级消耗 currencyType: string; // 消耗的货币或资源类型 baseCost: number; // 基础消耗 growthRate: number; // 每次升级的增长率 }; }

玩家实例数据则非常简单：

interface PlayerSkillState { skillId: string; level: number; unlocked: boolean; }

这样设计的好处是：配置是死的，玩法调的是配置；实例是活的，玩家所有成长状态都体现在这一个小小的结构里。将来加新技能，只需要往配置里加一条，玩家那边没有任何感觉——这就是配置驱动的核心思想。

我们项目里没有用数据库存技能配置，而是用了以前端维护的JSON配置表为主、服务端同步关键字段为辅的方式。因为技能数值是策划要反复调的东西，放前端改起来最快；但是解锁状态和等级这种关系到玩家资产的数据，必须存服务端，防止被篡改。

2.2 技能树的节点关系与遍历

技能树我用了一个带层级关系的结构，但并没有用真正意义上的树形数据结构。实际开发中，技能树最常见的实现方式其实是"每个节点记录自己的父节点ID"，然后通过依赖关系动态构建出树形关系。这样既方便后端存平铺数据，又方便前端递归渲染。

技能树配置结构：

interface SkillTreeNode { skillId: string; parents: string[]; // 前置技能ID数组，多个时表示需要多个前置都满足 children: string[]; // 后续可解锁的技能ID position: { x: number; y: number }; // 在技能树画布上的坐标 tier: number; // 层级，用于判定解锁进度 }

遍历的时候，玩家当前可解锁的技能就是"所有已解锁技能的children集合中，尚未解锁且前置条件全部满足的那些节点"。这个逻辑是我在项目里用得最频繁的一个函数，几乎没有之一。

function getUnlockableSkills(playerState, skillTree) { const unlockedSet = new Set( playerState.filter(s => s.unlocked).map(s => s.skillId) ); return skillTree.filter(node => { if (unlockedSet.has(node.skillId)) return false; return node.parents.every(parentId => unlockedSet.has(parentId)); }); }

你可能会问，技能树万一不是树而是图怎么办？比如一个技能需要另外两个分支的技能都点满才能解锁，或者某个技能是另一个技能的加强版、解锁后原技能退场。这个需求我在项目后期确实遇到过，解决办法是把树退化成了有向无环图——每个节点保留parents数组来接多个前置，不需要特意用图算法，遍历的时候用拓扑排序的思路，或者干脆简单粗暴地"每次只检测直接前置是否全部满足"，因为技能树规模通常不会超过几十个节点，性能上完全没问题。

2.3 效果系统的抽象：把"技能"和"效果"解耦

这是整个技能系统设计里回报最高的一件事。很多项目把效果写成技能类内部的方法，比如技能A里写一个"给敌人减速30%"，技能B里再写一个"给敌人减速60%"，结果每次加新技能都要复制粘贴，数值调整时还得逐个改。

我用的方案是独立的效果系统。技能只是"效果的容器和触发器"，一个技能可以挂多个效果，效果之间还可以设定触发顺序和概率。效果定义长这样：

interface SkillEffect { effectId: string; type: 'damage' | 'heal' | 'buff' | 'debuff' | 'summon' | 'custom'; target: 'self' | 'enemy' | 'ally' | 'all_enemies'; value: number; // 基础数值 scale: number; // 成长系数，随技能等级变化 duration?: number; // 持续时长，0表示立即生效 tickInterval?: number; // 脉冲间隔，用于持续伤害或持续治疗 triggerCondition?: string; // 触发条件表达式 tags?: string[]; // 自定义标记，比如 "火属性" "暴击可触发" }

效果结算的时候，技能等级会作为参数传入，跑一个统一的"效果解析器"。这样技能和效果就彻底解耦了：以后想做一个"火焰新星"，不需要新写逻辑，只需要配置一个AOE伤害效果再加上一个火属性tag。再想做一个被动技能"火属性伤害加深30%"，也只是配置一个buff效果，挂到玩家身上，结算系统检测tag后自动加成。

这一层抽象是我个人认为整个技能系统里最值得抄作业的部分。哪怕你只做一个小项目，把技能效果和技能本身分开，后面扩展的时候都会感激自己。

3. 数值成长与升级公式：让玩家有"爽感"而不是"疲劳感"

技能系统做得再好，数值要是没调好，玩家分分钟流失。技能的成长曲线直接影响了玩家的体验节奏——升级太慢，玩家觉得肝；升级太快，内容一下子被吃完。这一章聊聊我在项目里是怎么设计升级消耗和成长公式的。

3.1 升级消耗模型：指数增长的思路与代码实现

技能升级消耗，我用的是一个"基础消耗 + 指数增长率"的模型。公式是：

第n级升到第n+1级的消耗 = baseCost × growthRate^level

举个具体的例子，假设某个技能baseCost是10，growthRate是1.15，那么升到2级需要 10×1.15^1 ≈ 12 点资源，升到3级需要 10×1.15^2 ≈ 13 点资源，第10级则需要 10×1.15^9 ≈ 35 点资源。

这样设计的原因是：早期的技能升级成本低、反馈快，玩家能迅速感受到变强；越往后升级越贵，自然会引导玩家去点开其他技能分支，探索更多玩法。如果改成线性增长，比如每级固定加10，那么后期玩家的资源会大量溢出，养成系统就失去意义了。

代码实现也很简单：

function getUpgradeCost(skillLevel: number, config: SkillConfig): number { return Math.floor( config.upgradeCost.baseCost * Math.pow(config.upgradeCost.growthRate, skillLevel) ); }

这里有两个细节值得注意：

• 用Math.pow而不是循环累乘，是为了防止浮点误差累积。
• 结果一定要Math.floor取整。我在项目里吃过亏——有一版忘了取整，发现技能升级消耗出现了小数点，玩家截图上全是"升级需要 41.85 个碎片"，瞬间出戏。

3.2 成长曲线：技能强度与等级的映射关系

技能数值成长，我最常用的模型是"线性成长 + 关键节点跃迁"。也就是技能效果数值随等级线性增长，但在某些关键等级（比如5级、10级）会有一个比较大的跳跃，让玩家在升级时感受到"质变"。

这里用一个例子说明。假设火球术的伤害 = 基础伤害 100 + 等级 × 25，基础值是100，每升一级多25点。线性成长的好处是平滑、可预期，方便数值策划估算总伤害；坏处是没有惊喜感。

所以我在5级和10级各加了一个跃迁加成：

function getSkillDamage(skillLevel: number): number { let base = 100 + skillLevel * 25; if (skillLevel >= 5) base += 80; // 5级特殊加成 if (skillLevel >= 10) base += 200; // 10级质变 return base; }

这种"小平滑、大跳跃"的双层曲线，是我在做数值策划时比较喜欢的手法。它的好处是玩家在5级和10级会有明显的目标感——"我要攒资源把技能点到大关"，这是留存的一个隐形动力。

3.3 资源总量规划：判断技能树是否合理的数学方法

技能树的合理性与资源总量有非常直接的关系。你在设计表的时候，一定要先算清楚：玩家毕业需要总资源的期望值是多少？这个数值应该和项目的内容量、资源投放节奏配套，否则就会出现"玩家技能全点满了但剧情才过一半"或"游戏通关了技能还没点满三分之一"的尴尬。

我在项目里做了一次数值推演，把整棵树的技能全部拉到最大等级，统计总消耗。假设三个技能分支，每支5个技能，每个技能10级，每个技能平均消耗是1.2万——总耗就是大约18万。再对照日常产出，如果玩家每天稳定产出1000资源、周常额外给2000，那一个普通玩家大概需要5到6个月才能毕业。这个时间对于长线养成项目来说是合理的。

这里有一个公式可以直接用：

技能树总消耗 = Σ(每个技能从1级到满级的累计消耗)

每日可投入资源 = 日常产出 + 周常产出/7

毕业周期 = 总消耗 / 每日可投入资源

我强烈建议你在开发中期就做这个推演，不要等上线了再发现数值崩了。数值推演不需要很复杂的工具，Excel或者脚本算一遍就行。我在项目里第一次算完发现总消耗超了预期三倍，赶紧调低了growthRate，避免了上线后的数值事故。

4. 效果结算流程：技能放出去之后发生了什么

前面那些数据结构设计好了，只是搭好了架子。技能真正"活"起来靠的是结算流程——技能释放、命中目标、触发效果、产生数值变化、反馈到前端画面。这一块最容易出bug，因为涉及的服务很多：客户端表现、服务端逻辑、数据库存档，三方必须对齐，否则就会出现"客户端显示暴击1000，服务端记录只有500"这种对不上的扯皮。

4.1 结算流程拆解：从释放到结果反馈

我们的技能结算流程分为六个步骤：

1. 技能释放。玩家按下技能键，客户端向服务端发送技能释放请求。
2. 服务端校验。校验技能是否已解锁、冷却是否结束、资源是否足够、目标是否合法。
3. 效果解析。服务端读取技能配置，拿出所有绑定的效果数据。
4. 数值计算。根据技能等级、角色属性、目标防御、buff状态，计算最终数值。
5. 应用结果。扣血/加血/上buff/召唤单位，同时记入战斗日志。
6. 结果同步。服务端把结算结果推给客户端，客户端播放表现、更新UI。

这六步看起来平平无奇，但每一步都有坑。我先讲校验和计算这两步，因为最容易出安全问题。

服务端校验的核心原则是：客户端永远不可信。你的前端再怎么校验，也只是为了交互体验；真正的校验必须在服务端再来一遍。我在项目里就遇到过玩家通过改请求参数，把自己一个没解锁的高阶技能发出来的情况——服务端没校验就放行了，结果后台数据直接异常。从那以后，服务端校验逻辑就成了铁律。

4.2 伤害计算公式与随机性处理

伤害计算是最容易被各种需求改来改去的部分。我们项目经历了三个阶段：固定数值、简单公式、多因子公式。

最终稳定下来的一套公式大致是：

最终伤害 = 技能基础伤害 × (1 + 攻击力加成) × 技能等级系数 × 属性克制系数 × 随机浮动

随机浮动 = 0.9 ~ 1.1

其中攻击力加成是角色面板攻击除以某个基准值得到的，属性克制系数根据攻击方属性和防守方属性的克制关系产生1.2、1.0或0.8的倍率。随机浮动控制在正负10%，既保留了随机性的刺激感，又不会让伤害数值波动过大造成玩家困惑。

代码里实现随机浮动的时候，有一个小技巧：

function randomDamageFactor(): number { return 0.9 + Math.random() * 0.2; // 0.9 ~ 1.1 }

注意别写成1 + (Math.random() - 0.5) * 0.2，虽然数学上等价，但前者可读性更好，策划看到就能懂。

另外一个细节是：随机数要不要参与战斗校验？如果服务端和客户端的随机数种子不一样，两边计算结果就会不一致。我们的做法是服务端生成随机种子，随结算结果一起下发给客户端，客户端用同一个种子做表现层预测。这样两边对得上，不会出现"客户端显示暴击但服务端已判定失败"的错乱。

4.3 技能效果叠加与刷新策略

buff和debuff的叠加，是结算系统里最容易翻车的点。比如一个减伤30%的buff和一个减伤20%的buff同时存在，是加法叠加成50%，还是乘法叠加成1-(0.7×0.8)=44%？

我在项目里的原则是：同类效果用"刷新"而不是"叠加"，不同类效果用"独立结算"。驯服这么做的原因是：同类效果叠加很容易数值爆炸。比如五个减伤20%的debuff如果用加法叠，就是100%减伤，直接无敌，游戏彻底失衡。

实现策略上，我为每个buff分配了一个唯一ID列表：

interface BuffInstance { buffId: string; // buff模板ID sourceSkillId: string; // 来源技能 remainingTicks: number; // 剩余持续时长 value: number; // 当前生效数值 maxStacks: number; // 最大叠层数 currentStacks: number; }

同类buff再上时，不是新建一个实例，而是刷新已有实例的剩余时间和叠加层数。叠层上限通常设3层，防止无限叠加。这套逻辑写清楚之后，再也没出过"玩家身上挂了一千层buff"的笑话。

5. 前端技能树交互与视觉呈现

技能系统的后端逻辑再完善，玩家接触到的始终是前端界面。所以前端技能树的交互体验，在项目里占的分量很重。这里聊聊我在实现技能树UI时积累的经验，包括布局、状态展示、加点和动画效果。

5.1 技能树的布局方案对比

技能树的布局主要有三种方案：Canvas自由绘制、DOM绝对定位、DOM加SVG连线。

我们项目最初用了Canvas，因为技能树节点多、连线自由，Canvas绘制灵活。但后来发现一个问题：Canvas树没有天然的DOM事件机制，节点点击、悬浮提示、红点位置全靠手动计算。每次加新技能都要调坐标和层级，迭代成本太高。

后来我们改成了"DOM绝对定位 + SVG连线"的方案：

<div class="skill-tree-container"> <svg class="tree-lines"> <!-- 用SVG画节点连线 --> <path d="M... L..." stroke="#aaa" /> </svg> <div class="tree-node" style="left: 120px; top: 80px;"> <!-- 技能图标、等级、红点 --> </div> </div>

每个技能节点是一个绝对定位的div，通过配置里的position数据确定位置。连线用SVG的path绘制，从父节点中心拉到子节点中心。SVG的path天然支持曲线和平滑过渡，视觉效果比直线好很多，而且事件系统、动画系统都白嫖DOM的，比Canvas省了一大堆事。

提示：如果你要做的是横版刷图游戏里的技能面板，节点数量在20到30个以内，DOM加SVG完全撑得住。只有节点上百、需要自由拖拽缩放的大型技能盘，才值得回到Canvas。

5.2 状态机驱动的节点UI

技能节点的UI状态，我分了六种：未解锁、可解锁、已解锁未满级、已解锁满级、待升级、不可用（前置未满足）。每一种状态对应的样式完全不同。

这个状态切换我并没有逐节点手写if else，而是做了个状态机：

type NodeStatus = 'locked' | 'unlockable' | 'unlocked' | 'maxed' | 'upgradable' | 'disabled'; function getNodeStatus(skill, playerState): NodeStatus { if (!skill.unlocked && isUnlockable(skill, playerState)) return 'unlockable'; if (!skill.unlocked && !isUnlockable(skill, playerState)) return 'locked'; if (skill.level >= skill.maxLevel) return 'maxed'; if (hasUpgradeResource(skill, playerState)) return 'upgradable'; return 'unlocked'; }

状态机的好处是：无论玩家的操作多混乱——先点A再点B、把资源花光后又解锁了新技能——界面状态始终是自洽的。每次玩家操作后，我只需要重新计算一遍所有节点的状态，UI就会正确地刷新。这个"重算全部状态"的策略看着笨，但实际用起来极其稳，根本不会出现某个节点状态残留在错误态的问题。

5.3 加点操作与红点系统的实现

技能加点前端交互有一个容易忽略的点：加点的前后置动画。玩家点了一下"+1"，如果只是数字变一下，反馈很弱。我们在项目里加了"加点进度条 + 粒子效果 + 技能图标短暂放大"的三连反馈，整个手感立刻上了一个档次。

至于红点系统，实现上比想象中简单：什么时候显示"可升级"红点？就是当前资源足够升级某个技能、且该技能已被解锁。不需要复杂算法，遍历所有技能状态判断一遍即可。但是有两点要注意：

• 红点不要显示在已满级技能上。有些项目的红点是"可升级就亮"，但满级了还亮着，特别蠢。
• 红点计算要放在状态刷新里一起跑，不要单独写一套逻辑，否则状态和红点容易对不上。

6. 常见问题与排查实录

技能系统我前前后后做了好几个版本，踩过的坑加起来能写一大篇。这里挑几个典型的、很多人肯定会碰到的，写成排查实录，省得大家再淌一遍。

6.1 技能树循环依赖导致无法解锁

这个坑听起来低级，但真实发生概率不低。比如A技能的前置是B，B的前置是C，C的前置又写了A，三个技能互相等待，结果玩家的技能树从此锁死。

排查方法其实很简单：每次修改技能配置后，跑一遍拓扑排序，检查是否有环。项目里我写了这么个校验函数：

function hasCycle(skillTree): boolean { const visited = new Set(); const visiting = new Set(); const nodes = new Map(skillTree.map(n => [n.skillId, n])); const dfs = (id: string): boolean => { if (visiting.has(id)) return true; if (visited.has(id)) return false; visiting.add(id); for (const parentId of nodes.get(id)?.parents || []) { if (dfs(parentId)) return true; } visiting.delete(id); visited.add(id); return false; }; return [...nodes.keys()].some(id => dfs(id)); }

把这个函数加进CI或者配置检查流程里，只要有人改了技能配置，自动校验，循环依赖一冒头就被拦截，根本走不到线上。

6.2 升级消耗溢出与数值爆炸

升级消耗用了指数增长，指数太大的时候有一个隐蔽问题：JavaScript的number精度。当消耗计算值超过2^53时，精度会丢失，出现"升级消耗变成负数"这种诡异情况。

我项目里有一个40级的技能，growthRate设到1.35，计算到30级以后消耗已经是天文数字。排查时发现这数字在Math.pow后出现了浮点误差，最终结果干脆用了一个"封顶"逻辑：当计算消耗超过某个阈值，直接返回一个特殊的封顶值（比如999999），并且UI上显示为"MAX"或者"不可升级"。这个处理方式避免了一大堆浮点精度问题，也防止玩家看到一个荒谬的数字。

6.3 存档版本兼容：加了新技能，老玩家崩了

技能系统最容易被忽视的问题就是存档兼容。玩家已经有一份存档了，里面没有新技能的数据，前端代码却尝试读取新技能的等级，直接报undefined错误。这个问题我印象太深了，有一次上线新版本，老玩家登录后技能树整个白屏，一查就是因为新技能在玩家的旧存档里没有初始化。

解决办法有两个：一是在前端读取技能状态时，对所有配置里的技能做一次"默认值补齐"；二是写一个迁移逻辑，玩家登录时检测到存档版本旧，自动为新技能写入默认状态。

function normalizePlayerSkills(skillConfigs, playerSkills): PlayerSkillState[] { return skillConfigs.map(config => { const exist = playerSkills.find(s => s.skillId === config.id); return exist ?? { skillId: config.id, level: 0, unlocked: false, }; }); }

这个函数是我存档版本兼容的保命符，每次新增技能后都要确保跑一遍。

6.4 客户端与服务端数值不一致

前面说过，战斗结算在服务端，表现预测在客户端。如果两边用的公式不一致，就会闹出"客户端显示打了1000，服务端说只打500"的笑话。

排查这类问题，我的经验是：把数值计算抽成完全独立的纯函数，客户端和服务端共用同一套核心代码。如果你们项目的后端是Node.js，那前端和后端都可以用同一份TypeScript代码；如果后端是Java/Python之类的，就要保证两边用完全相同的公式和操作顺序，特别是取整和随机浮动的时机，一定要精确到每一步。

注意：求值顺序不同，结果就会不同。比如先加攻击力再乘属性克制，和先乘属性克制再加攻击力，结果完全不一样。这种细节一定要在文档里写死。

7. 技能系统的扩展方向：从一个模块变成一个玩法框架

技能系统做完并跑通后，我发现它的价值远不止"给角色加技能"这么简单。当你把技能抽象成"可配置的被动与主动效果集合"之后，很多玩法都可以顺势长在这个框架上。

装备系统就是一个典型的例子。装备洗练出的词条，本质上就是一个个技能效果——"攻击力+5%""暴击率+2%"。你完全可以复用技能效果系统，给装备挂上同样的effectIds，战斗结算时统一处理。这样装备、技能、buff、天赋，四套系统共用一套效果解析器，开发量一下子省了一大半。

符文系统同理。符文石的组合可以设计成触发某种特殊效果，本质上就是给角色挂一个自定义tag。我在项目后期，把符文、装备词条和技能效果全部统一到效果系统里，新需求来了基本就是配表，不再写新代码。这种"一次抽象，处处复用"的稳定性，才是技能系统最有价值的地方。

如果你正在做一个技能系统，我的建议是：先花时间把数据结构定扎实——技能配置与实例分离、技能与效果解耦、效果与结算独立，这三个设计决策决定了你系统的上限。数值上，把成长曲线和总消耗提前推演清楚，别等上线了再补救。前端状态机大胆用，状态重算比手写一堆if else可靠得多。最后别忘了一些细枝末节——存档兼容、客户端服务端对齐、循环依赖校验，这些看似不起眼的点，才是在生产环境真正决定你能不能睡个好觉的地方。

我个人在实际项目里最大的体会是：技能系统不是一个"功能"，而是一个"框架"。你把它当成框架来设计，后面所有玩法扩展都是顺水推舟；你把它当一个功能来做，后面每加一个技能都是一次高风险的改动。这两者之间的差别，全在最初那几张表的设计里。