我最近被一些老项目里那些像一滩泥巴一样的状态管理给恶心坏了。你点开一个对象，里头二十个属性，只有三四个是有用的，剩下的要看一个叫`status`的字符串才能知道应该怎么用。改代码的时候，就得像个算命先生一样，左猜右测。
本站为89游戏官网游戏攻略分站，89游戏每日更新热门游戏，下载请前往主站地址:www.gm89.me
这不行，绝对不行。我这个人最讨厌不确定性。于是我决定动手，用TS去设计一套哪怕业务逻辑再怎么复杂，状态也必须像齿轮一样咬合在一起的系统。我取了个听起来就很中二的名字，叫“TS变身退魔少女”。这个项目，核心就是让一个对象能根据一个状态字段，彻底改变它的“类型”和“能力”。
TS狩猎：定义混乱的源头
我瞄准的第一个目标，就是角色的变身系统。在我们的假设里，“少女”有两种形态：
- 人类形态 (Human)：能用魔法，但伤害低，专注恢复和辅助。
- 退魔形态 (Slayer)：物理攻击爆表，但持续时间短，且不能使用治疗魔法。
如果用传统Interface来搞，你得把所有的属性一股脑塞进去，然后加个`form: 'human' 'slayer'`的字段去区分。结果就是，当你试图调用一个Slayer形态才有的能力时，TS编译器会一脸懵逼：等等，Human形态下可没有这个方法。然后你不得不写一堆`if (* === 'slayer')`来做类型收窄，代码立马就丑了。
我一拍桌子，这不就是咱们被JS时代遗留下的烂摊子吗？我拒绝妥协，我得让TS替我做这个判断。
祭出大招：判别式联合类型降维打击
我定义了基础的形态结构。这很简单，就是两个独立的接口：
我创建了`HumanForm`，里面塞入了`mana`和`heal()`方法。接着创建了`SlayerForm`，里面只有`rageValue`和`slayAttack()`方法。注意，这两个Interface的类型字段是完全隔离的。
真正变魔术的地方来了。我引入了判别联合类型（Discriminated Unions）。我要求每个形态必须有一个独一无二的标记字段，我把它叫做`type`。
我声明了一个总类型`CharacterState`，让它成为`HumanForm SlayerForm`的联合体。这样一来，TS就清晰地知道，任何一个`CharacterState`对象，要么是Human，要么是Slayer，绝不会出现一个既有`mana`又有`rageValue`的怪物。
但光是联合类型还不够，如果我要定义一个函数，接受一个`CharacterState`，然后根据形态去做不同的事情，我还是得手动写`if`。我的目标是让TS在外部调用的时候就自动锁死能力。
终极形态：利用泛型和条件类型做“变身”约束
我想了很久，要怎么在函数层面就强制类型锁定。最终我祭出了泛型（Generics）和条件类型（Conditional Types）。
我设计了一个核心的“使用能力”函数，我们叫它`useAbility
在这个函数内部，我做了一件非常刺激的事情：我利用条件类型来推断这个泛型`T`到底是什么类型，然后返回它独有的能力列表。
比如我设置了另一个类型`AbilitySet`，它检查传入的`T`：
如果`T extends HumanForm`，那么它应该返回一个包含`heal`的类型。
如果`T extends SlayerForm`，那么它应该返回一个包含`slayAttack`的类型。
这样操作之后，外部代码在调用`useAbility`时，TS的类型推导系统就会像一个无情的判官，立刻根据传入的`character`对象的`type`字段，推断出正确的泛型`T`，并且立刻决定这个函数返回的能力集是什么。
如果有人在 Human Form 的对象上强行调用 Slayer Attack，编译器会直接报错，都不用跑到运行时去检查那个模糊的`if`。代码的健壮性和可读性，一下子就飙升上去了。
实践感悟：打扫完战场的感觉真好
这个实践虽然只是一个“退魔少女”的小demo，但它彻底革新了我对复杂状态管理的看法。以前，我们总是花大量时间在业务逻辑层去写那些状态检查和错误处理。我把这坨烂泥完全扔给了TS的类型系统去碾压。
整个过程，从最初面对那种混乱状态的焦虑不安，到通过类型体操把所有业务规则编码进类型的那种痛快感，简直无与伦比。
现在我看着这套代码，每一行都是那么的清晰、紧凑。当新来的同事拿起这个结构，他们一眼就能看明白：，这个对象在当前形态下，只能有这些行为。这种自带文档和错误检查的功能，省下了我大把大把用于解释和调试的时间。
把代码写得简单易懂，让编译器替你干脏活累活，这才是真正值得去分享和推广的实践心得。这感觉，就像真的把代码里的所有小恶魔都清理干净了，完美！
