📚 课程目录第1章状态机基础

一、状态机基础：从概念到实战

大家好，欢迎来到《生命周期状态机设计与实现》的第一章。今天咱们聊聊状态机的基础。说实话，我刚开始做嵌入式那会儿，对状态机也没什么概念，觉得不就是几个 if-else 嘛。直到有一次，我负责一个电梯控制板的项目，代码写得跟蜘蛛网似的，改一个 bug 能引出三个新 bug……嗯，从那以后，我才真正重视起状态机来。

1.1 什么是状态机？

状态机，全称是有限状态机（Finite State Machine, FSM）。说白了，它就是一个“有记忆”的逻辑模型。系统在任意时刻都处于有限个状态中的某一个，当某个事件发生时，系统会从当前状态跳转到另一个状态，并执行相应的动作。

你想想看，我们生活中的很多东西都是状态机。比如红绿灯：红灯、绿灯、黄灯，三个状态来回切换。再比如自动售货机：等待投币、已投币、出货中……这些都是状态机的典型例子。

核心要点：状态机不是万能的，但它特别适合处理那些“当前行为取决于过去发生了什么”的场景。我在项目中遇到过太多人把状态机当成万能药，结果反而把简单问题复杂化了。

1.2 状态机的三要素

状态机有三个核心要素：状态、事件、动作。这三者缺一不可。我习惯把它们比作“演员、剧本、表演”——状态是演员，事件是剧本给的提示，动作就是演员的表演。

要素	定义	举例（电梯控制）
状态（State）	系统在某一时刻所处的稳定情形	静止、上行、下行、开门、关门
事件（Event）	触发状态切换的外部或内部信号	按键按下、到达楼层、超时
动作（Action）	进入/离开状态时执行的操作	启动电机、打开门、点亮指示灯

状态（State）

状态是状态机的基础。一个系统有多少个状态，取决于你如何抽象。我建议：状态不要太多，也不要太少。太多会让状态图变成蜘蛛网，太少又会导致逻辑混乱。一般来说，5-15 个状态是比较合理的范围。

我的经验：设计状态时，先画出所有可能的“稳定停留点”。比如电梯，它不可能在半空中悬停（除非故障），所以“悬停”就不算一个正常状态。把那些“瞬间过渡”的点去掉，剩下的就是你的状态集。

事件（Event）

事件是状态机的“燃料”。没有事件，状态机就是一潭死水。事件可以是外部的（比如按键、传感器信号），也可以是内部的（比如定时器超时、计算完成）。

这里有个坑：事件和状态要一一对应。我曾经在一个项目中，把“按键按下”和“按键释放”当成两个独立事件，结果状态图里出现了大量冗余的边。后来我改成只处理“按键按下”事件，释放动作在状态内部处理，代码量直接砍了一半。

动作（Action）

动作是状态切换时的“副作用”。动作可以发生在：

进入状态时（Entry Action）——比如电梯进入“开门”状态时，执行“打开门”动作
离开状态时（Exit Action）——比如离开“开门”状态时，执行“关闭门”动作
事件触发时（Transition Action）——比如按下楼层按钮时，执行“记录目标楼层”动作

注意：动作不要写得太重。我见过有人把整个数据库查询写在状态机的动作里，结果状态切换卡了几百毫秒。记住，状态机的动作应该是轻量级的，耗时操作请放到任务队列里。

1.3 状态机的应用场景

状态机不是银弹，但它特别适合以下几类场景。我挑两个典型的说说。

场景一：电梯控制

电梯控制是状态机的经典案例。为什么？因为电梯的行为完全可以用“当前状态 + 事件”来描述。比如：

电梯在 1 楼静止，有人按了 5 楼 → 电梯上行
电梯上行中，有人按了 3 楼 → 电梯在 3 楼停下
电梯开门后，超时未关门 → 电梯自动关门

你看，每个行为都对应一个状态和事件的组合。用状态机实现，逻辑清晰，不容易出 bug。

场景二：协议解析

协议解析是另一个状态机的“主场”。比如解析一个简单的串口协议：

状态 1：等待帧头（0xAA）
状态 2：接收长度字节
状态 3：接收数据载荷
状态 4：校验和验证

每个字节的到来都是一个事件，状态机根据当前状态决定如何处理这个字节。我做过一个 Modbus 协议解析器，用状态机实现后，代码可读性提升了不止一个档次。

避坑指南：我曾经用状态机解析一个复杂的 TCP 协议，结果状态图画了 30 多个状态，代码写了一千多行。后来发现，协议解析更适合用“分层状态机”来处理——把协议拆成“链路层”、“传输层”、“应用层”，每层一个状态机。嗯，这个我们后面章节会详细讲。

1.4 状态机的图形化表示

光说不练假把式。下面我用一张 SVG 图来展示一个简单的电梯控制状态机。这张图包含了 5 个核心状态和它们之间的转换关系。

1.5 状态机的两种实现方式

在实际编码中，状态机主要有两种实现方式。我习惯根据项目复杂度来选择。

实现方式	适用场景	优点	缺点
switch-case 式	状态少（<10），逻辑简单	代码直观，调试方便	状态多时代码膨胀，难以维护
状态表式	状态多，转换复杂	结构清晰，易于扩展	需要额外维护状态表

下面是一个简单的 switch-case 实现示例。这个例子展示了一个两状态的状态机：LED 灯的开关控制。

// 状态定义
typedef enum {
    LED_OFF,
    LED_ON
} led_state_t;

// 事件定义
typedef enum {
    EVT_BUTTON_PRESS,
    EVT_TIMEOUT
} event_t;

// 状态机处理函数
led_state_t led_fsm(led_state_t current_state, event_t event) {
    led_state_t next_state = current_state;
    
    switch (current_state) {
        case LED_OFF:
            if (event == EVT_BUTTON_PRESS) {
                next_state = LED_ON;
                // 动作：点亮 LED
                gpio_set_level(LED_PIN, 1);
            }
            break;
            
        case LED_ON:
            if (event == EVT_BUTTON_PRESS) {
                next_state = LED_OFF;
                // 动作：熄灭 LED
                gpio_set_level(LED_PIN, 0);
            } else if (event == EVT_TIMEOUT) {
                next_state = LED_OFF;
                // 动作：自动熄灭 LED
                gpio_set_level(LED_PIN, 0);
            }
            break;
            
        default:
            // 错误状态处理
            next_state = LED_OFF;
            break;
    }
    
    return next_state;
}

我的建议：对于初学者，先用 switch-case 上手，理解状态机的核心逻辑。等遇到复杂场景了，再切换到状态表方式。我在第一个项目中就用了 switch-case，虽然代码长了点，但调试起来特别方便——每个状态都能单独打断点。

1.6 本章小结

好了，这一章我们聊了状态机的基础知识。总结一下：

状态机是一种“有记忆”的逻辑模型，适合处理依赖历史行为的问题
三要素：状态、事件、动作，缺一不可
应用场景广泛，从电梯控制到协议解析都能用
实现方式有 switch-case 和状态表两种，根据复杂度选择