4、状态跳转表设计：跳转表的定义、二维表结构、跳转条件的优先级处理
状态跳转表，说白了就是一张「地图」。
你想想看，一个嵌入式系统里少说几十个状态，多则上百个。每个状态遇到不同事件，该往哪儿走？靠if-else堆？我见过有人写了三百行的switch-case，最后自己都看不懂了。
跳转表就是来解决这个问题的。它把状态、事件、下一个状态，这三样东西规规矩矩地放进一张表里。查表跳转，清晰明了。
4.1 什么是跳转表
跳转表本质上是一个二维数组。行代表当前状态，列代表触发事件，交叉点就是下一个状态。
嗯，这里要注意：跳转表不是代码，它是一种数据结构。你可以在C语言里用二维数组实现，也可以在状态机工具里用表格配置。我个人习惯用const数组，编译时就定好了，运行时只读，安全又高效。
核心定义：
跳转表 = 状态 × 事件 → 下一个状态
说白了就是：我现在在状态A，收到了事件X，查表就知道该去状态B。
4.2 二维表结构
二维表怎么搭？我直接给个例子，你一看就明白。
假设我们有个简单的门禁系统：
- 状态：IDLE（空闲）、CARD_READ（读卡中）、OPEN（开门中）、ALARM（报警）
- 事件：CARD_IN（刷卡）、CARD_OK（卡有效）、CARD_FAIL（卡无效）、TIMEOUT（超时）
| 当前状态 \ 事件 | CARD_IN | CARD_OK | CARD_FAIL | TIMEOUT |
|---|---|---|---|---|
| IDLE | CARD_READ | IDLE | IDLE | IDLE |
| CARD_READ | CARD_READ | OPEN | ALARM | IDLE |
| OPEN | OPEN | OPEN | OPEN | IDLE |
| ALARM | ALARM | ALARM | ALARM | IDLE |
你看，这张表一出来，所有跳转逻辑一目了然。我在项目中遇到过最头疼的事，就是需求变更时改跳转逻辑。有了这张表，改一个格子就行，不用去翻几百行代码。
小技巧：设计二维表时，建议把「不可能发生」的跳转填上当前状态自身。这样即使代码跑错了，也不会跳到未知状态去。我管这叫「安全兜底」。
4.3 跳转条件的优先级处理
二维表看起来简单，但实际项目中往往没那么理想。为什么？因为事件可能同时发生。
举个例子：门禁系统正在读卡，这时候又有人刷卡，同时超时定时器也到了。三个事件同时来，该处理哪个？
这就涉及到优先级了。我个人习惯的做法是：
- 先分优先级等级：比如紧急事件（报警、故障）优先级最高，普通事件次之，周期性事件最低。
- 同一优先级按FIFO：先到先处理，避免饿死。
- 跳转表中预留「抢占」标记：某些事件可以打断当前状态的处理。
避坑指南：我曾经在一个项目中，没有处理事件优先级，结果两个事件同时触发，状态机直接跑飞了。从那以后，我每个跳转表都会加一列「优先级掩码」，明确哪些事件可以同时处理，哪些必须排队。
代码实现上，我一般这样写：
// 跳转表条目
typedef struct {
uint8_t current_state;
uint8_t event;
uint8_t next_state;
uint8_t priority; // 0最高，255最低
} jump_table_entry_t;
// 查表函数
uint8_t state_transition(uint8_t cur_state, uint8_t event) {
for (int i = 0; i < TABLE_SIZE; i++) {
if (jump_table[i].current_state == cur_state &&
jump_table[i].event == event) {
return jump_table[i].next_state;
}
}
return cur_state; // 没找到就原地不动
}你想想看，这样设计之后，优先级处理就变成了查表时的排序问题。把高优先级的条目放在表前面，查表时先匹配到就先处理。简单粗暴，但有效。
4.4 跳转表的核心逻辑图
下面这张图，是我画的一个跳转表核心逻辑。你看一眼就能明白整个流程：
这张图把整个流程串起来了。你从左边输入当前状态和事件，中间查表，右边输出下一状态。优先级怎么处理？就是在查表之前，先把事件队列按优先级排好序。高优先级的先查，先匹配先跳转。
我的经验：跳转表设计好了，状态机代码基本就完成了一半。剩下的就是事件采集和动作执行。我建议你把跳转表单独放在一个头文件里，用宏定义把状态和事件都命名好。这样后期维护，改表不改代码，舒服得很。
嗯，关于跳转表，核心就这些。记住三件事：二维表结构要清晰、优先级要明确、安全兜底不能少。做到这三点，你的状态机基本就稳了。