企业官网建设流程全解析

做嵌入式这些年，我见过太多项目被 switch-case 状态机拖垮。一开始确实爽：一个枚举变量、一个 switch，事件来了改改状态，代码看起来清清楚楚。可一旦状态超过几十个，事件越来越多，改一个分支就要在大段 case 里翻半天，改完还要提心吊胆，生怕影响别的状态。也就是从那时候开始，我认真研究 QP 状态机——准确说是 Quantum Leaps 的 QP/C 框架。它不是简单帮你封装几个宏的小库，而是一整套事件驱动的状态机架构，专门解决嵌入式复杂项目里“状态多、迁移乱、逻辑散”的难题。这篇文章我把自己的实践过程、踩坑记录、移植配置都整理出来，供同样被状态逻辑折磨的人参考。

1. 为什么 switch-case 状态机会把项目拖垮

1.1 写起来一时爽，维护起来火葬场

先看一段最典型的 switch-case 状态机代码：

typedef enum { APP_IDLE, APP_RUNNING, APP_PAUSED, APP_STOPPED } AppState; static AppState appState = APP_IDLE; void app_handle_event(uint8_t evt) { switch (appState) { case APP_IDLE: if (evt == EVT_START) { motor_on(); appState = APP_RUNNING; } break; case APP_RUNNING: if (evt == EVT_PAUSE) { motor_off(); appState = APP_PAUSED; } else if (evt == EVT_STOP) { motor_off(); appState = APP_STOPPED; } break; case APP_PAUSED: if (evt == EVT_RESUME) { motor_on(); appState = APP_RUNNING; } break; // ... } }

这段代码很容易看懂，我并不是要否定它。问题是它只能撑住很小的项目规模。假设你只有三五个状态、三四种事件，那 switch-case 完全够用。但真实项目不是这样：状态会随着需求不断叠加，事件会从按键、串口、定时器、网络模块源源不断涌进来。今天加一个“参数保存中”，明天加一个“蓝牙配置模式”，后天再来一个“异常恢复确认”。很快你会发现，状态变量被几十个地方修改，每个分支里塞满了if (flag && evt == X)之类的组合判断，最后没人说得清楚系统当前到底处于什么状态。

我见过一个通信网关项目，main 函数里一个 switch-case 长到两千多行，为了支撑“挂起、恢复、升级、配置回滚”这些功能，工程师用了大量布尔标志位去绕开现有状态分支。结果是什么呢？增加一个新功能要同时改五六个地方，测试工程师来问“这个状态下那种事件到底应该怎么表现”，代码作者自己也答不上来。这就是 switch-case 状态的典型晚景。

1.2 二维的状态关系被拍扁成了一维代码

状态机原本是一个二维模型：纵轴是状态，横轴是事件，格子里面写着“转移到哪个状态、执行什么动作”。比如一个简单系统有 20 个状态、10 种事件，理论上最多有 200 条转移关系，用 switch-case 表达就是 200 个散落的分支判断。你只能在脑子里把这一大堆分支重新拼成一张表，才能理解全貌。

更重要的是，switch-case 把所有判断都堆在同一个函数里，状态之间的共性无法复用。比如很多状态退出时都要执行“保存现场”“关掉外设”“恢复默认参数”这些动作，在 switch-case 里就只能复制粘贴，一个状态一份。后期需求变更，想在这些公共动作里加一个操作，你就得遍历所有分支，漏掉一个就埋下一个 bug。

为了更直观，我把 switch-case 和状态机的表达方式做了个对比：

所以与其说 switch-case 是“不够优雅”，不如说它把二维关系强行压扁成一维，导致复杂度随状态数指数上升。状态机恰恰是让代码结构重新回到二维关系上。

1.3 状态机的三个基本概念其实不玄

很多嵌入式工程师听到状态机就想起 UML 图、理论教材，觉得离工程很远。实际上状态机就三个核心概念：状态、事件、转移。状态是系统当前稳定待在的阶段；事件是触发变化的信号，比如按键按下、串口收到一帧数据、定时器超时；转移是收到事件后从一个状态进入另一个状态，同时会执行对应动作。

用空调遥控器类比最直观。空调有“待机”“制冷”“制热”几个状态。你按下“开机”键，这是一个事件，空调从待机转移到制冷，同时执行压缩机启动动作。在制冷状态收到“温度到了”事件，压缩机停，但风机继续吹。这些描述用 switch-case 也能写，但状态机把“你现在在哪”和“什么事件会把你带到哪”变成第一公民，思路清晰很多。这也解释了为什么 QP 状态机能在嵌入式领域流行——它做的就是把这种思想变成可以落地的 C 代码框架，而不是停留在理论层面。

2. QP 状态机到底做对了什么

2.1 QP 不是“一个库”，而是四个组件的组合

QP 是 Quantum Leaps 公司的开源事件驱动框架系列，常见的是 QP/C 和 QP/C++，还有面向资源受限芯片的 QP-nano。很多人误以为 QP 就是一个“状态机库”，其实它由四个组件组成，各自负责不同的事：

我最开始只用了 QEP，因为我的需求很简单：一个按键模块，十几个状态，不需要多个任务并发。后来做协议解析和菜单系统时，发现多个状态机之间需要通信，才引入 QF 的事件队列。如果你只有一个状态机，完全可以只裁剪 QEP，把 QF/QK 放一边。这也是 QP 灵活的地方。

2.2 每个状态一个函数，把 case 打散成独立模块

QP 最核心的代码组织方式，是把“状态”从int appState变成一个状态处理函数。事件来临时，调度器调用当前状态函数，状态函数内部对这个事件做判断，如果发生转移就返回Q_TRAN(&下一个状态函数)。这样写的代码长这样：

static QState Button_idle(Button *me, QEvt const *e) { switch (e->sig) { case BTN_PRESSED: { start_timer(me, DEBOUNCE_MS); return Q_TRAN(&Button_debounce); } case Q_ENTRY_SIG: { me->clickCount = 0; return Q_HANDLED(); } } return Q_SUPER(&Button_root); }

这里虽然还有 switch，但结构已经完全变了：每个状态一个独立函数，函数内部只关心这个状态下各种事件应该怎么处理。状态与状态之间不再通过修改一个公共变量耦合，而是通过Q_TRAN显式声明转移关系。你不再需要在一坨 case 里搜索“谁修改了 state 变量”，因为每个状态自己负责自己的行为。

函数指针看起来比switch(appState)多了一次间接跳转，在 Cortex-M 上开销可以忽略。换来的是模块化：每个状态函数可以单独 review、单独测试，可以放在不同的源码文件里。这比在一个五千行函数里翻 case 健康得多。

2.3 层次状态机：公共逻辑往上提，差异逻辑往下沉

QP 另一个杀手锏是层次状态机，也就是 HSM。平面状态机里，所有状态平铺，每一个状态都要完整处理自己关心的全部事件。HSM 则允许一个状态有父状态，子状态没有处理的事件会自动交给父状态。父状态里的进入、退出动作，子状态也会继承。

用生活类比：公司里所有员工都要遵守“离开公司要刷卡”的制度。如果按平面状态机建模，每个员工角色状态都得写一遍“刷门禁”的动作；按层次状态机建模，把“员工”当父状态，把“开发工程师”“测试工程师”“产品经理”当子状态，刷卡逻辑只在父状态写一次，子状态只管自己特有的“写代码”“跑测试”“催进度”就行。

在代码里，这种继承通过Q_SUPER实现：

static QState Button_root(Button *me, QEvt const *e) { switch (e->sig) { case Q_EXIT_SIG: { cancel_all_timers(me); return Q_HANDLED(); } case BTN_RELEASED: { return Q_TRAN(&Button_idle); } } return Q_SUPER(&QHsm_top); // 谁也没处理，交给顶层 } static QState Button_debounce(Button *me, QEvt const *e) { switch (e->sig) { case BTN_RELEASED: { return Q_TRAN(&Button_idle); // 去抖期间松手，回到空闲 } } return Q_SUPER(&Button_root); // 其他事件交给父状态 }

想象一下：如果项目有十多个子状态，每个退出时都要做同样的事情，用 switch-case 就要在每个 case 里复制一遍。用 HSM 把公共逻辑放在父状态，需求变更时只改父状态一次，这种收益在维护阶段非常明显。

2.4 事件驱动加事件队列：状态机不再害怕突发事件

状态机本身是被动的，关键是谁来喂事件。在前后台裸机程序里，事件可能来自 GPIO 中断、串口空闲中断、定时器溢出中断。如果直接在中断里改变状态机的状态，很容易出现重入问题：前一个事件还没处理完，后一个事件又来了。

QP 的 QF 组件提供了事件队列机制。中断里只负责把一个事件对象投递到目标活动对象的队列尾部，然后立即返回。主循环或调度器依次取出事件，调用当前状态处理函数。事件队列实际上起到了“缓冲”和“隔离”的作用，中断上下文只做最轻量的事，复杂逻辑全部放到主循环上下文处理。

如果一个事件必须延迟处理，你也不需要自己维护一堆围绕状态机的布尔标志。可以创建一个时间事件，让它在一段时间后触发；时间事件也走事件队列，不会干扰当前状态机。这套机制让事件来源可以随意增加，状态机本身却始终保持“单线程、不重入、可预期”。

3. 用 QP 重写一个多功能按键控制器的全过程

3.1 先设计状态图，不急着写代码

我经常用一个多功能按键来演示 QP 的实战过程，因为按键逻辑不算复杂，却包含了去抖、短按、长按、连击、双击等典型状态问题，非常适合练手。

需求是这样：一个 GPIO 按键，要支持短按、长按、双击。短按触发一次单击事件，长按超过 1 秒后进入重复触发模式，每 200ms 触发一次长按事件，松手退出；双击需要在第一次松开后的 300ms 内再次按下才算。

先把事件列出来：按下BTN_PRESSED、松开BTN_RELEASED、去抖结束BTN_DEB_TIMEOUT、长按判定BTN_LONG_TIMEOUT、重复触发BTN_REPEAT_TIMEOUT、双击等待超时BTN_CLICK_TIMEOUT。状态则包括：空闲idle、去抖中debounce、按下保持pressed、重复触发repeat、等待第二击wait_second_click。父状态root负责公共逻辑，比如所有计时器清零、松手后回到空闲。

这个状态图不需要很复杂，但画出来之后，所有迁移关系就一目了然了。凡是想不清楚“双击超时期间又按下”的情况，看状态图就能解决。

3.2 搭建一个最小 QP/C 工程

QP/C 的源码可以直接从官网仓库拿到，目录里包含 qep、qf、qk、qs 四个核心子目录，以及 include 目录下的头文件。嵌入式移植时，通常只需要把用到的源码文件加入工程，再配一个qp_port.h。以 STM32F103 裸机工程为例，我一般这样做：

1. 将 qep/qf 的全部源文件加入工程，如果不用 QK 调度，可以不编译 qk 下的源文件。
2. 在qp_port.h里定义芯片相关的临界区。最简单的方式是关中断/开中断，比如#define QF_CRIT_STAT_TYPE uint32_t、#define QF_CRIT_ENTRY() (stat = __get_PRIMASK())，这些宏在每个版本的 QP/C 里略有差异，参考官方移植说明即可。
3. 配置事件池大小、活动对象数量等宏。
4. 在启动文件里为SysTick_Handler调用QF_TICK_X(0)，作为 QF 的心跳。

如果只使用 QEP，不引入 QF，那更简单：不需要事件池，不需要队列，只需要把 QEP 的状态处理器接好，在main里直接调用QHsm_dispatch()。我建议新手第一次使用时先走这个最小路径，把精力放在状态函数上，不要一上来就研究 QF 的订阅发布。

3.3 定义结构体和状态处理函数

在 QP/C 里，一个状态机实例是一个结构体，第一个成员是QHsm或QActive，后面可以带自己的业务数据。按键模块的定义大致如下：

typedef struct Button Button; struct Button { QHsm hsm; // 继承 QHsm，使用 hsm 分发 uint32_t pressTick; // 按下时的系统 tick，用于长按判定 uint8_t repeatCount; // 重复触发次数 }; enum ButtonSignals { BTN_NO_MSG = 0, BTN_PRESSED, BTN_RELEASED, BTN_DEB_TIMEOUT, BTN_LONG_TIMEOUT, BTN_REPEAT_TIMEOUT, BTN_CLICK_TIMEOUT };

然后是构造函数和状态函数。以根状态和空闲状态为例：

void Button_ctor(Button *me) { QHsm_ctor(&me->hsm, Q_STATE_CAST(&Button_root)); } static QState Button_root(Button *me, QEvt const *e) { switch (e->sig) { case Q_EXIT_SIG: { me->repeatCount = 0; cancel_timer(me, BTN_DEB_TIMEOUT); cancel_timer(me, BTN_LONG_TIMEOUT); cancel_timer(me, BTN_REPEAT_TIMEOUT); cancel_timer(me, BTN_CLICK_TIMEOUT); return Q_HANDLED(); } case Q_INIT_SIG: { return Q_TRAN(&Button_idle); } case BTN_RELEASED: { post_event(EVT_BTN_CLICKED); return Q_TRAN(&Button_idle); } } return Q_SUPER(&QHsm_top); } static QState Button_idle(Button *me, QEvt const *e) { switch (e->sig) { case Q_ENTRY_SIG: { me->repeatCount = 0; return Q_HANDLED(); } case BTN_PRESSED: { me->pressTick = get_tick(); start_timer(me, BTN_DEB_TIMEOUT, 5); return Q_TRAN(&Button_debounce); } } return Q_SUPER(&Button_root); }

代码里用到的QHsm_ctor、Q_STATE_CAST、Q_TRAN、Q_SUPER都是 QP/C 的标准宏，不同小版本的名称可能有出入，但语义一致。对于不想和宏细节纠缠的开发者，可以使用 QM 建模工具自动生成这些代码，这也是官方推荐的姿势。

3.4 用 QM 工具画图生成代码，省掉手写宏

QM 是 Quantum Leaks 提供的免费建模工具，支持画状态图、定义事件、生成 C 代码。我在真实项目里基本都是用 QM 建模再生成骨架，然后在生成的Button_idle()这类函数填里填业务动作。流程大概是：

1. 新建一个模型文件，添加一个类，比如Button。
2. 在类下面添加状态图，创建root、idle、debounce、pressed、repeat、wait_second_click状态。
3. 在状态图里画转移：从idle到debounce的箭头，选中它，在属性面板里写触发事件BTN_PRESSED，动作填写启动定时器。
4. 点击生成代码，QM 会输出一份包含所有状态函数的 .c/.h 文件。
5. 之后业务逻辑发生变化，比如双击时间从 300ms 改成 500ms，只需修改图中属性再重新生成，手动维护的部分很少。

用 QM 的最大好处是状态图本身就是文档，团队 review 代码时直接看图，比读几百行 case 高效太多。当然，QM 不是必须的，但用了之后你会很难再回到手动画分支。

3.5 在主循环里喂事件

如果只跑 QEP，没有 QF，最简单的事件投递方式是轮询扫描：

while (1) { if (gpio_pin_read(BTN_PIN) == 0) { QEvt e; e.sig = BTN_PRESSED; QHsm_dispatch(&button.hsm, &e); } else { QEvt e; e.sig = BTN_RELEASED; QHsm_dispatch(&button.hsm, &e); } service_timers(&button.hsm); delay_ms(5); }

这种方式适合入门，但不够严谨：轮询周期里可能出现多次按下事件，去抖逻辑还得自己加。更专业的做法是 GPIO 中断里只设置标志位，主循环每 5ms 扫描一次标志，再构造事件。如果上了 QF，可以直接在中断里QACTIVE_POST_ISR()投递事件，状态机的事件处理全部放在主循环里，逻辑上更干净。

实际操作中，我强烈建议在状态机里不要调用任何阻塞式的delay()。一个状态处理函数执行时间过长，整个事件循环都会被卡住。要么用短超时重发事件，要么把耗时操作拆成子状态机，用时间事件驱动进度。这条经验救我很多次。

4. 迁移到 QP 的实操要点：从 switch-case 平滑过渡

4.1 迁移前先做一张事件转移表

从 switch-case 迁移到 QP，最大的坑不是写不好状态函数，而是没想清楚状态和事件关系就动手。我建议先把旧代码里的 state 枚举值全部提取出来，作为转移表的行；把触发状态变化的所有事件提取出来，作为列；然后一格一格填写“目标状态和动作”。

填完这张表，哪些状态需要父状态、哪些公共动作可以上提就清楚了。比如从三个状态退出时都要取消所有定时器，那就应该放到父状态的Q_EXIT_SIG里处理，而不是每个状态重复。迁移时这张表就是你的蓝图，代码只是把表翻译成 QP 的函数指针。

4.2 增量迁移，保留旧实现做对比

别做“大爆炸式重写”，一次把整个项目的 switch-case 全换掉风险太高。我的做法是选一条相对独立的模块，比如按键、串口命令解析、菜单显示，先给这个模块建立 QP 状态机。然后写一个测试台，让新旧两份实现接收同样的事件序列，对比最终输出和处理轨迹。这在事件驱动系统里很实用：开关量输入、串口数据帧、定时器超时都可以录下来，回放给两份实现。

等新模块跑稳了，再替换下一个。增量迁移的好处是问题定位范围小，而且每个模块都能单独验证。我有个同事当时三个月没写完一个项目重构，就是因为第一天就把整个系统推翻重来，最后陷入新旧逻辑混在一起的泥潭。我自己的项目也只是花了两周时间，一个功能一个功能搬，搬完一个测试一个，整体风险很小。

4.3 关键参数怎么算：事件池、队列长度和 RAM 开销

很多工程师担心 QP 这种框架会吃掉大量 RAM。我用下来，只要配置合理，开销完全可控。以 STM32F103、20KB 内存的设备为例，如果只有一个按键状态机，只跑 QEP 几乎不额外占多少 RAM。即使跑完整 QF，典型配置也只需要几百字节。

QP/C 的 QF 里有两个关键容量配置：事件池的事件数量，以及每个活动对象的队列长度。事件池数量可以按最坏情况下同时存在的事件数来估算，包括中断里还没被处理的、主循环里排队的事件，以及时间事件。队列长度则取决于某个活动对象瞬时能接收多少事件。对大多数裸机项目，8 个事件池、每个活动对象队列 4 个事件已经足够。

粗略算一下：假设每个事件结构体是typedef struct { QEvt super; uint32_t param1; uint32_t param2; } MyEvt;，其中 QEvt 通常包含了一个信号成员和一个动态标志，32 位对齐后总共 16 字节或 20 字节。8 个事件池就是 160 字节左右；4 个队列，每个队列里面放事件指针，4 个指针一共 16 字节，总共也就是 200 字节上下。对于常见的 Cortex-M0/M3 芯片，这点开销换取代码结构和调试能力，非常划算。

4.4 中断里投递事件的正确姿势

在中断和主循环之间传递事件，最容易出问题。若直接用普通函数在中断里操作状态机，风险很大；QF 里则要区分普通上下文和中断上下文。

普通上下文可以用QActive_post()投递事件到活动对象，中断上下文必须用QActive_postX_ISR()或对应的QACTIVE_POST_ISR()宏。两者的区别在于，普通版本可能会触发调度器切换任务，在中断里这么做轻则造成死锁，重则栈溢出。

一个基本的 GPIO 按键中断处理可以这样写：

void EXTI2_IRQHandler(void) { static QEvt const pressEvt = { BTN_PRESSED, 0 }; QACTIVE_POST_ISR(QS_OBJ_PTR(&button_ao->super), &pressEvt); EXTI_ClearITPendingBit(EXTI_Line2); }

如果只用 QEP 不用 QF，没有队列的保护，就得更小心：中断里可以设置一个 volatile 标志，主循环扫描到标志后再构造事件给QHsm_dispatch()。事件驱动不等于所有东西都要在中断里传递，关键是保证状态机执行上下文单一。

4.5 代码审查清单

在代码进入 review 之前，我习惯按下面几项自查，能避免大部分低级问题：

• 状态函数最后是否调用了Q_SUPER(&父状态)，有没有被粗心返回成Q_HANDLED()。
• 发生转移时是否在Q_TRAN后立即 return，避免继续执行当前状态后续代码。
• 父状态的Q_EXIT_SIG和子状态的Q_EXIT_SIG是否重复释放同一个资源。
• 事件结构体里的信号值是否从 1 开始，0留给Q_ENTRY_SIG等内部伪信号。
• 状态函数里有没有调用阻塞延时。
• 所有时间事件在退出状态时是否都被取消，防止状态机离开后定时器还往队列里投递事件。

这些清单看着琐碎，但都是真实项目中踩出来的经验。

5. 常见问题与避坑实录

5.1 状态“卡死”多半是事件被吞了

我在用 QP 写协议栈时遇到过状态卡死：某个状态收到指定事件后应该迁移，但程序毫无反应。排查了很久，最后发现状态函数里有一行return Q_HANDLED()返回得太早，把事件“吞掉了”，父状态根本没机会处理。QP 的事件处理有一个明确约定：事件被当前状态处理后返回Q_HANDLED()，没处理则继续向父状态传递；如果一路传递到顶层还没有状态处理，事件就被丢弃。看起来像卡死，其实是事件已经“静默消失”了。

遇到这类问题，最有效的办法是开 QS 软件追踪，看每个事件进入状态机的路径和返回码。没有 QS 的情况下，也可以在状态处理函数入口加调试打印，记录事件信号和当前状态名，这样很快能定位到事件是被谁吞掉，还是压根没有投递进来。

5.2 双击变成两次单击：典型的“少了一个中间状态”

还有一个高频问题：多功能按键里，双击会被识别成两次单击。原因很简单——第一次松手后状态直接回到空闲状态，第二次按下就被当作新单击。正确设计是第一次松手后进入“等待第二击”状态，同时启动一个双击窗口定时器。如果定时器超时，才上报单击事件并回到空闲；如果在超时前又收到按下事件，就上报双击事件。这个“等待第二击”的暂态，就是 switch-case 里很难自然表达的中间状态。用 QP 画状态图时，这类逻辑关系一目了然，不容易漏。

5.3 编译宏不匹配带来的挫败感

QP/C 每次大的版本更新，宏名可能调整，比如Q_STATE_CAST、Q_TRAN的写法在不同版本里偶尔会有差异。新手第一次抄代码时经常因为宏不匹配编译不过。我的建议是不要抱着旧文章里的代码死磕，直接看官方仓库里的移植模板和示例工程。如果只想要稳定的体验，可以用 QM 生成代码，跟着工具版本走，避开手写宏带来的版本风险。

5.4 队列溢出怎么定位

如果用了 QF，偶尔会遇到事件丢失或队列溢出断言。定位思路分两步：先看最坏情况下的事件产生速率是否超过处理速率，再看是不是某个状态处理函数执行时间过长，导致事件积压。我实际遇到过一种情况：串口接收中断以每字节一个事件的频率投递，但状态机里为了解析一帧数据做了一次 10ms 的阻塞延时，结果中断持续投递，队列瞬间满了。事后把解析改成状态机内部循环，每次事件只处理一部分，问题就消失了。

5.5 哪些场景不建议用 QP

QP 再香，也不是万金油。如果芯片 Flash 只有几 KB，RAM 只有几百字节，那完整 QF 可能放不下。这种情况可以退而求其次，只引入 QEP 的手写状态处理器，或者干脆继续用 switch-case。还有一种情况：状态只有三五个，业务逻辑几乎不会增长，那 switch-case 就是最直接可靠的方案，没必要为了“优雅”引入框架。我的判断标准很简单：如果需求清单里明确写着“模式增加”“协议扩展”“多步骤流程”，那值得用 QP；如果功能封闭、交互简单，那就别折腾。

6. 写在最后的个人经验

6.1 我实际获得的收益有多大

老实说，无论是用 QP 还是继续用 switch-case，代码量并不会显著减少。真正减少的是“状态迁移散落在各个模块、改一个需求要牵一发动全身”的心智负担。我用 QP 重写过一个串口指令解析加菜单系统，原本逻辑相关代码大概一千多行，重写后结构类似，但后来加“蓝牙命令行模式”“出厂参数恢复”“OTA 升级确认”三个需求时，每次只用新增两三个状态和对应处理函数，几乎没有碰过旧状态。要是在旧 switch-case 版本里，这三个需求很可能又要引入三四个标志位。

性能方面，函数指针间接跳转带来的开销在 MCU 上完全可以忽略。真正要注意的是事件拷贝和队列操作。事件结构体尽量保持小巧，能放指针就放指针，不要拷贝一大块数据到事件里，否则高频事件的队列操作会消耗不必要的 CPU。

6.2 给嵌入式新手的上手路线

如果你准备开始学 QP，我给的建议是：先别直接啃源码，先弄懂 UML 状态图和层次状态机的概念，然后装一个 QM，画一个按键状态机，生成代码，跑在 PC 上。PC 上跑通了，再移植到开发板。移植时先用 QEP，不要一上来就上 QF 的订阅发布。等理解“事件->状态函数->转移”这条主线之后，再研究 QF 的事件队列、活动对象、时间事件。这样一步步走，大约三到五天就能上手。

6.3 别神化状态机，也别再被 switch-case 绑架

状态机说到底是一种工具，QP 是把这种工具工程化的框架。你可以选择完整 QF，也可以只借鉴 QEP 的状态函数思路，甚至在自己封装的调度循环里用类似的函数指针表。真正需要改变的，是面对复杂逻辑时第一反应不再是“再加一个 case、再定义一个标志位”，而是先想清楚状态、事件、转移。我自己现在无论写裸机还是 RTOS 项目，凡是状态多一点的地方，第一反应都是开 QM 画图，而不是打开编辑器写 switch。这个习惯帮我少熬了很多个改 bug 的夜，也让我对代码的掌控感强了很多。