一、为什么需要状态机#

想象你在写一个网络请求模块。请求有几种状态：空闲、加载中、成功、失败。你用布尔变量来标记：isLoading、isSuccess、isError。一开始只有三四个标志，逻辑还算清晰。但很快你会发现，这些布尔变量之间存在隐含的约束——isLoading 和 isSuccess 不可能同时为真，加载中不应该再次触发请求，成功之后不能再变成失败。

这些约束散落在各个 if-else 分支里，没有集中管理。一旦遗漏某个检查，就会出现「加载中还能点击」「成功后还能报错」之类的 bug。更糟糕的是，当你需要加一个「重试」状态时，所有涉及状态判断的地方都要改，漏改一个就是线上事故。

用布尔标志写出来的代码大概长这样：

1
// 用布尔标志管理请求状态——典型的反面模式
2
let isLoading = false;
3
let isSuccess = false;
4
let isError = false;
5

6
function fetch() {
7
  if (isLoading) return;        // 防止重复请求
8
  if (isSuccess) return;        // 成功了还请求？
9
  isLoading = true;
10
  isError = false;
11
  // ...发起请求
12
}
13

14
function onSuccess() {
15
  isLoading = false;
16
  isSuccess = true;             // 忘了重置 isError？bug 就来了
17
}
18

19
function onError() {
20
  isLoading = false;
21
  isError = true;
22
  isSuccess = false;            // 又要记得重置 isSuccess
23
}
24

25
function retry() {
26
  if (!isError) return;         // 只有出错才能重试
27
  isError = false;
28
  fetch();                      // 但 fetch 里又检查 isSuccess...
29
}

这段代码的问题一目了然：每个函数都要手动维护多个布尔变量的联动关系，onSuccess 里忘了重置 isError，retry 调用 fetch 时 isSuccess 可能还是 true 导致请求被跳过。三个布尔变量有 8 种组合，但合法的只有 4 种。剩下的 4 种是不可能状态——它们不该出现，但代码没有任何手段阻止它们出现。

更具体的场景：一个订单系统。订单有「待支付」「已支付」「已发货」「已完成」「已取消」五种状态。如果用布尔标志，你需要 isPaid、isShipped、isCompleted、isCancelled 四个变量，组合出 16 种可能。其中「已支付且已取消」「已发货且未支付」这类不可能状态占了大多数。每写一个业务判断，你都在跟这些幽灵状态搏斗。

问题的根源在于：布尔标志的组合空间远大于合法状态的数量。3 个布尔变量有 8 种组合，但你只需要 4 种合法状态；4 个布尔变量有 16 种组合，但可能只有 5 种合法状态。那些多余的组合是不可能状态——它们不该出现，但代码没有阻止它们出现。状态机从根本上解决这个问题：把合法状态和状态之间的转移规则显式定义出来，让不可能的状态不可表达。

二、现实类比#

自动售货机。它有明确的状态：空闲、已投币、正在出货。不投币就不能出货，正在出货时不能再投币。每个按钮只在特定状态下有效——你不会在出货时还能按退币键。售货机不需要一堆 if-else 来判断「当前能不能做这个操作」，它只需要一张状态转移表。

再想想十字路口的红绿灯。它永远在红、黄、绿之间循环，不可能出现「红绿灯同时亮」的情况，因为硬件电路本身就是一张硬编码的转移表。现实世界里的嵌入式设备几乎都用状态机来建模控制逻辑——电梯、洗衣机、微波炉，哪个不是按状态和转移来运转的？

三、核心思想#

状态机把实体的生命周期建模为一组有限状态和显式转移。任何时刻，实体恰好处于一个状态。转移由事件触发，只有定义过的转移才能发生。

上面这张状态图只画了合法的转移路径。注意 success 和 error 之间没有箭头——这不是遗漏，而是设计：这两个状态之间不存在合法转移，状态机从结构上杜绝了这种可能。

威力所在：不存在的转移不可能发生。你无法从 success 跳到 error，因为没有定义这样的转移。这比在代码里到处加 if (!isSuccess) 判断要可靠得多——你不可能忘记加检查，因为根本不需要检查。

四、变体与对比#

五、多语言实现#

1
// StateMachine 用转移表管理状态生命周期
2
type StateMachine struct {
3
    current     string
4
    transitions map[string]map[string]string // state -> event -> next
5
}
6

7
func New(initial string) *StateMachine {
8
    return &StateMachine{
9
        current:     initial,
10
        transitions: make(map[string]map[string]string),
11
    }
12
}
13

14
// AddTransition 注册一条合法的状态转移
15
func (sm *StateMachine) AddTransition(from, event, to string) {
16
    if sm.transitions[from] == nil {
17
        sm.transitions[from] = make(map[string]string)
18
    }
19
    sm.transitions[from][event] = to
20
}
21

22
// Send 触发事件，若转移合法则更新状态
23
func (sm *StateMachine) Send(event string) string {
24
    if next, ok := sm.transitions[sm.current][event]; ok {
25
        sm.current = next
26
    }
27
    return sm.current
28
}
29

30
// Can 检查当前状态下该事件是否有效
31
func (sm *StateMachine) Can(event string) bool {
32
    _, ok := sm.transitions[sm.current][event]
33
    return ok
34
}
35

36
func (sm *StateMachine) State() string { return sm.current }

1
type StateConfig<S extends string, E extends string> = {
2
  [state in S]: { on: Partial<Record<E, S>> };
3
};
4

5
class StateMachine<S extends string, E extends string> {
6
  private current: S;
7

8
  constructor(
9
    private config: StateConfig<S, E>,
10
    initial: S,
11
  ) {
12
    this.current = initial;
13
  }
14

15
  get state(): S {
16
    return this.current;
17
  }
18

19
  // 触发事件，查转移表决定下一状态
20
  send(event: E): S {
21
    const next = this.config[this.current].on[event];
22
    if (next !== undefined) {
23
      this.current = next;
24
    }
25
    return this.current;
26
  }
27

28
  // 当前状态下该事件是否有效
29
  can(event: E): boolean {
30
    return this.config[this.current].on[event] !== undefined;
31
  }
32
}

六、生产验证#

• XState —— StateMachine.ts#L58-L120 JavaScript/TypeScript 工业级状态机库。它不仅实现了基本的状态转移，还支持层级状态（嵌套状态机）、并行状态（正交区域）、延迟转移和守卫条件。Netflix 用它管理复杂的多步注册流程，Microsoft 在 VS Code 的某些扩展中用它编排交互逻辑，AWS 在 Step Functions 中用状态图语言（本质是状态机）定义工作流。
• Linux 内核 —— tcp_input.c#L4865-L4920 TCP 连接状态机。TCP 协议定义了 11 种状态（从 CLOSED 到 ESTABLISHED 到 TIME_WAIT），Linux 内核用 switch (sk->sk_state) 实现状态分发，每个 case 处理该状态下合法的入站报文。这个状态机运行在全球每台联网设备的内核里，是状态机模式最广泛的生产部署之一。TCP 状态机的设计精妙之处在于：TIME_WAIT 状态持续 2MSL 后自动转移到 CLOSED，这是一种带超时的自转移，保证连接资源最终被回收。
• Kubernetes —— Pod 生命周期状态转移，从 Pending 到 Running 到 Succeeded/Failed，通过状态机保证不会出现非法中间状态。Kubernetes 的 Pod 状态虽然看起来简单，但背后涉及容器运行时、调度器、kubelet 三方协作。状态机确保了比如一个 Failed 的 Pod 不会突然变成 Running——即使 kubelet 误报了状态，API Server 也会根据转移规则拒绝非法变更。

七、小结#

何时使用：

• 协议实现——TCP、HTTP、WebSocket 等有明确状态转移规范的场景。TCP 状态机是教科书级案例，11 个状态、数十条转移规则，用布尔标志根本无法管理。
• UI 流程管理——多步表单、认证流程、模态框，需要约束用户操作顺序。XState 在前端社区被广泛采用正是因为这类需求。
• 游戏逻辑——角色状态（待机、行走、攻击、死亡），每种状态下可执行的动作不同。死亡状态不接受任何输入，这靠状态机天然保证。
• 工作流引擎——审批链、部署流水线，状态的推进必须遵循规则。Kubernetes 的 Pod 生命周期就是典型的工作流状态机。

何时不用：

• 简单布尔切换——true/false 不需要状态机，一个变量够了。一个开关灯的按钮用状态机是过度设计。
• 无界状态——连续状态空间（位置、分数）用普通变量。角色的坐标是连续值，不可能为每个坐标建一个状态。
• 无非法转移——如果任何状态可以转到任何其他状态，约束没有意义。一个简单的缓存标记（命中/未命中），两个状态之间可以随意切换，状态机不会带来收益。
• 组合爆炸——5 个独立开关等于 32 种状态；应该将正交关注点分别建模为并行状态机。XState 的并行状态（orthogonal states）就是为解决这个问题设计的。

八、参考资料#

• XState 官方文档 - JavaScript 状态机与状态图库
• RFC 793 - TCP 协议规范 - TCP 状态机的形式化定义
• Kubernetes Pod 生命周期 - Pod 状态转移图
• Statecharts: A Visual Formalism for Complex Systems - Harel 提出 Statechart 的原始论文，解决了 FSM 的状态爆炸问题