一、状态机基础：从生活到代码的思维模型
大家好，我是你们的老朋友。今天咱们聊聊状态机——这个听起来有点高大上，其实每天都在用的东西。
说实话，我刚开始做嵌入式那会儿，对状态机也是一头雾水。总觉得这东西是理论家搞出来的，跟实际开发没啥关系。直到有一次，我写一个按键处理程序，用了一堆if-else嵌套，结果bug多到我自己都看不懂……嗯，从那以后，我彻底服了状态机。
1.1 什么是状态机？
状态机，全称是有限状态机（Finite State Machine, FSM）。说白了，它就是一个“有记忆”的模型。
你想想看，我们平时写程序，大部分逻辑都是“输入→处理→输出”。但有些场景下，同样的输入，在不同时刻会产生不同的输出。为什么？因为系统内部的状态变了。
举个例子：你按一下遥控器的电源键，电视如果是关着的，它就打开；如果是开着的，它就关闭。同一个按键，结果完全相反。这就是状态在起作用。
状态机的核心思想：系统在任何时刻都处于一个确定的状态，当某个事件发生时，系统根据当前状态和事件，执行相应的动作，并可能转移到下一个状态。
我个人习惯把状态机想象成一个“有记忆的自动售货机”。你投币（事件），它根据当前有没有货（状态），决定是出货还是退钱（动作）。
1.2 状态机的三要素
状态机有三个核心要素，缺一不可。我当年面试新人，就爱问这个——能把这三点说清楚的，基本功一般都不差。
| 要素 | 定义 | 生活中的例子 |
|---|---|---|
| 状态（State） | 系统在某一时刻所处的稳定情形 | 红绿灯的“红”、“黄”、“绿” |
| 事件（Event） | 触发状态转移的外部或内部输入 | 定时器超时、按键按下 |
| 动作（Action） | 状态转移时执行的操作 | 点亮红灯、关闭电机 |
状态——这是系统的“记忆”。我在项目中遇到过最典型的例子是通信协议解析：一个数据帧有帧头、长度、数据、校验、帧尾。解析器必须记住当前读到哪一步了，这就是状态。
事件——这是系统的“刺激”。说白了，就是“发生了什么”。按键按下、定时器溢出、串口收到一个字节……这些都是事件。
动作——这是系统的“反应”。事件来了，状态变了，总得干点啥吧？动作就是干的那点事。可以是输出一个信号，也可以是启动一个定时器，甚至可以是啥也不干。
我的小技巧：设计状态机时，先把所有可能的状态列出来，再画事件。顺序别搞反了。状态是骨架，事件是血肉。
1.3 状态机的应用场景
状态机到底能用在哪儿？说实话，范围比你想象的大得多。
我随便列几个我亲手做过的项目：
- 按键消抖与长按检测——这是状态机的入门级应用。一个按键有按下、弹起、抖动、长按等多个状态，用状态机写出来清晰得不得了。
- 通信协议解析——比如UART接收一帧数据，从等待帧头到接收长度，再到接收数据体和校验，每一步都是一个状态。
- 任务调度器——RTOS里的任务状态（就绪、运行、阻塞、挂起），本质上就是一个状态机。
- UI界面切换——菜单系统的进入、退出、返回，用状态机管理，再也不用担心界面跳转乱套了。
- 电机控制——启动、停止、正转、反转、过流保护……每个状态都有明确的进入条件和退出条件。
你可能会问：这些用if-else也能写啊，为啥非要用状态机？
嗯，问得好。我刚开始也这么想。但后来发现，当状态超过3个、事件超过5个时，if-else的复杂度是指数级增长的。而状态机是线性的——每个状态只管自己的事，互不干扰。
避坑指南：我曾经在一个项目里用if-else写了20多个嵌套层级的按键处理逻辑。后来加了一个新功能，改了一处，崩了三处。从那以后，凡是涉及“不同时刻不同行为”的逻辑，我必用状态机。
1.4 状态机的图形化表示
光说理论太枯燥。我习惯用图来画状态机。下面这张图，展示了一个最简单的两状态按键消抖状态机：
这张图里，两个椭圆代表两个状态，箭头代表事件触发的转移。你看，是不是一目了然？
我个人习惯在设计阶段先用纸笔画这种图，画清楚了再写代码。代码写起来就跟填空一样简单。
1.5 状态机的两种实现方式
代码怎么写？主要有两种流派。
方式一：switch-case 法
这是最直观的方式。每个case对应一个状态，里面处理该状态下的事件。
typedef enum {
STATE_IDLE,
STATE_PRESSED,
STATE_RELEASED
} KeyState_t;
KeyState_t currentState = STATE_IDLE;
void KeyFSM_Process(Event_t event) {
switch (currentState) {
case STATE_IDLE:
if (event == EVENT_KEY_DOWN) {
currentState = STATE_PRESSED;
Timer_Start(10); // 启动10ms消抖定时器
}
break;
case STATE_PRESSED:
if (event == EVENT_TIMEOUT) {
currentState = STATE_RELEASED;
Key_ReportPress(); // 报告按键按下
} else if (event == EVENT_KEY_UP) {
currentState = STATE_IDLE; // 抖动，回到空闲
}
break;
case STATE_RELEASED:
if (event == EVENT_KEY_UP) {
currentState = STATE_IDLE;
Key_ReportRelease(); // 报告按键释放
}
break;
}
}
方式二：状态表法
这种方式更高级一点。把状态转移关系做成一张表，用查表代替switch-case。
typedef struct {
State_t currentState;
Event_t event;
State_t nextState;
void (*action)(void);
} Transition_t;
Transition_t keyTransitions[] = {
{STATE_IDLE, EVENT_KEY_DOWN, STATE_PRESSED, Timer_Start10ms},
{STATE_PRESSED, EVENT_TIMEOUT, STATE_RELEASED, Key_ReportPress},
{STATE_PRESSED, EVENT_KEY_UP, STATE_IDLE, NULL},
{STATE_RELEASED, EVENT_KEY_UP, STATE_IDLE, Key_ReportRelease},
// 终止标记
{STATE_NONE, EVENT_NONE, STATE_NONE, NULL}
};
我的建议：初学者先用switch-case，逻辑清晰，容易调试。等状态多了（比如超过10个），再考虑状态表法。状态表法的好处是增删改查方便，但调试时不如switch-case直观。
1.6 状态机的设计原则
最后，分享几条我踩坑踩出来的经验：
- 状态要互斥——任何时刻，系统只能处于一个状态。别搞出“半按半松”这种模糊状态。
- 事件要完整——每个状态下，所有可能的事件都要有处理逻辑。哪怕只是“忽略”，也要明确写出来。
- 动作要纯粹——动作里不要改变状态。状态转移由事件驱动，动作只负责“干活”。
- 状态数要可控——如果一个状态机有超过20个状态，考虑拆分成多个子状态机。
我曾经犯过的错：在一个通信协议解析的状态机里，漏掉了“接收超时”这个事件。结果设备在异常情况下卡死在某个状态，再也收不到数据了。从那以后，我每个状态都会加一个“超时”或“异常”处理分支。
好了，状态机的基础就聊到这儿。说白了，状态机就是一个“有记忆的决策系统”。它让复杂的逻辑变得有序，让混乱的代码变得清晰。下一节，咱们聊聊怎么把状态机真正用到项目里去。