布尔爆炸 —— 为什么需要状态机

本课导读

新单元从一类你迟早会写出来的 bug 讲起：页面同时显示着加载动画和错误提示，或者按钮转着圈却还能再点一次。这类 bug 的根源惊人地一致——用一堆布尔变量描述状态，而布尔的组合里混着大量"不可能的状态"。本课先解剖惨案现场，再给出解药的名字：状态机——把"当前处于哪种情况"收纳成一个变量，把"什么情况下能变成什么"写成明确的规则。这个思想比 TypeScript 古老得多（红绿灯就是台状态机），但 TS 恰好是把它写出来最舒服的语言之一。预计 45 分钟。

惨案现场：三个布尔，八种组合

做一个数据加载页面，很自然地写下三个变量：

// 一个"看起来很合理"的数据页面状态
let isLoading = false;
let isError = false;
let hasData = false;

// 模拟一次倒霉的执行顺序：
isLoading = true;          // 开始加载
isError = true;            // 请求失败，设了错误……
// 但忘了把 isLoading 关掉！

// 界面渲染逻辑一脸懵：
if (isLoading) {
  console.log("显示：转圈动画");
}
if (isError) {
  console.log("显示：错误提示");
}
// 转圈和报错同时出现——用户看到一个精神分裂的页面

问题不在"忘了关"这一行——谁都会忘。问题在结构：3 个布尔有 2×2×2 = 8 种组合，而业务上合法的情况只有 4 种（空闲、加载中、成功、失败）。剩下 4 种"不可能的状态"（又加载又报错、又成功又加载……）在类型上全部合法，编译器帮不上任何忙，只能靠每个开发者每次都记得手工维护布尔之间的默契。变量再多一个，组合翻倍，默契迟早崩。

这类 bug 有个学名叫不可能状态可表示（impossible states are representable）。对应的治疗原则也是一句话，值得背下来：让不可能的状态不可表示（make impossible states unrepresentable）。

解药第一步：一个变量收纳所有情况

四种合法情况，就用一个变量、四个值：

// unit-1 学过的字面量联合，正式上岗
type Status = "idle" | "loading" | "success" | "error";

// 渲染逻辑瞬间清醒：status 只能是一个值——
// 转圈和报错在结构上不可能同时出现
function render(status: Status): void {
  if (status === "loading") {
      console.log("显示：转圈动画");
  }
  if (status === "error") {
      console.log("显示：错误提示");
  }
}

let status: Status = "idle";
status = "loading";        // 开始加载
status = "error";          // 请求失败——loading 自动"不在了"，没有第二个变量要关

render(status);
// status = "eror";        // 取消注释：TS2322——拼错都进不来

变化的本质：8 种组合塌缩成 4 个值，不可能的状态在类型层直接灭绝。没有需要维护的默契，没有需要记得关的开关——不是你变细心了，是错误失去了藏身之处。

解药第二步：转移也要有规矩

光收纳还不够。看这个 bug 的另一半：

type Status = "idle" | "loading" | "success" | "error";

let status: Status = "success";

// 数据都加载成功了，某个残留的回调又把状态改成……
status = "loading";        // 类型完全合法！但业务上这合理吗？

// 还有更常见的：用户在 loading 时狂点提交按钮
// 每次点击都触发一次请求——因为没有任何规则说"loading 时不接受提交"
console.log("当前状态：" + status);

status 的每个值都合法，但从哪个值变到哪个值不是随便的：success 不该无故跳回 loading；loading 中再收到"提交"应该被无视。这些"变化的规矩"就是状态机的第二半：

**状态机 = 有限的状态集合 + 明确的事件 + "什么状态遇到什么事件变成什么状态"的转移规则。**规则之外的变化，一律不发生。

生活里你天天在用状态机：红绿灯（红→绿→黄→红，谁也别想从红直接跳黄）、地铁闸机（锁定—刷卡→放行—通过→锁定，放行时再刷卡不会开两次）、洗衣机（脱水时按"启动"没反应）。它们的共同气质：任何时刻你都说得清它处于哪个状态、接下来只有几种确定的可能——这份"说得清"，正是我们要搬进代码里的东西。

状态与数据：先分清一对角色

最后铺一块下一课的地基。"success 之后拿到的列表数据"算状态吗？——不算。状态（state）是"处于哪种情况"，取值有限、可枚举；数据（context）是伴随状态的内容，取值无限（列表内容千变万化）。混着放会退回布尔爆炸的老路（hasData 就是把数据问题硬编码成了状态布尔）。正确的姿势是"有限的状态 + 各状态携带各自的数据"——比如 success 状态必然带着数据、error 状态必然带着错误信息。这件事用 TS 表达得极其漂亮，主角叫判别联合，下一课整课就是它。

✍️ 练习

练习 1：数一数不可能状态

某音乐播放器用了四个布尔：isPlaying、isPaused、isBuffering、isStopped。① 一共多少种组合？② 业务上合法的情况有哪几种（列出来）？③ 写出两个"不可能却可表示"的组合，并各配一个它会导致的界面 bug。最后用一个字面量联合替换这四个布尔。

练习 2：找出身边的状态机

写出两台你今天接触过的现实状态机（电梯、微波炉、共享单车锁、外卖订单……任选），各列出：状态集合、事件集合、两条转移规则、一条"被无视的事件"（某状态下发生了也不起作用的事件——比如洗衣机脱水时按启动）。

📝 随堂测验

本课小结

• 布尔爆炸：n 个关联布尔 = 2 的 n 次方种组合，合法的只有几种——不可能状态可表示是一类 bug 的总根源
• 治疗原则：让不可能的状态不可表示——一个字面量联合收纳所有情况
• 状态机 = 有限状态 + 事件 + 转移规则；规则之外的变化不发生（含"被无视的事件"这层自我防御）
• 上状态机的三个信号：第二个关联布尔出现、"这时候点了会怎样"答不上来、修一个显示 bug 引出另一个
• 状态是"情况"（有限），数据是"内容"（无限）——别混

下一课主菜：判别联合——让每个状态携带自己的数据，success 必有 data、error 必有 message、loading 想带 data 都带不了，编译器全程站岗。