事件驱动 vs 状态机：核心比较
1. 基本概念
| 维度 | 事件驱动 | 状态机 |
|---|---|---|
| 核心 | 响应外部/内部事件，触发回调 | 基于当前状态和输入决定下一状态 |
| 控制流 | 异步、非阻塞 | 可以是同步或异步 |
| 记忆 | 通常无历史状态 | 显式存储当前状态 |
2. 关键区别
| 对比项 | 事件驱动 | 状态机 |
|---|---|---|
| 状态管理 | 隐式（通过回调/闭包） | 显式（状态变量/状态图） |
| 复杂度控制 | 易失控（回调地狱） | 结构化（状态转换表清晰） |
| 可测试性 | 较难（时序依赖） | 较好（输入-输出确定性） |
| 适用问题 | I/O密集、并发触发 | 协议处理、UI交互、生命周期 |
3. 典型应用场景
事件驱动：
-
GUI 框架（点击、键盘事件）
-
Node.js / Reactor 模式
-
消息队列消费者
-
异步网络服务
状态机：
-
订单状态（待支付→已支付→发货→完成）
-
TCP 协议状态（CLOSED→LISTEN→SYN_RCVD→ESTABLISHED...）
-
游戏角色行为（待机→移动→攻击→死亡）
-
嵌入式系统模式切换
4. 混合使用（推荐）
状态机作为事件驱动的决策核心：
python
# 伪代码示例
class StateMachine:
state = "IDLE"
def handle_event(self, event):
if self.state == "IDLE" and event == "START":
self.state = "RUNNING"
self.on_run()
elif self.state == "RUNNING" and event == "ERROR":
self.state = "ERROR"
self.on_error()
# 事件驱动循环
while event = get_next_event():
state_machine.handle_event(event) # 事件分发到状态机5. 选择建议
| 条件 | 推荐方案 |
|---|---|
| 事件种类少、无复杂状态流转 | 纯事件驱动 |
| 状态转移明确、需要可预测性 | 纯状态机 |
| 异步 + 多状态 + 可维护性要求高 | 事件驱动 + 状态机组合 |
6. 常见误区
-
❌ "状态机只能用于同步系统"------可扩展为异步状态机（如状态机工作流引擎）
-
❌ "事件驱动不需要状态"------大型事件系统往往隐含状态（如会话管理）
-
✅ 正确理解：事件驱动是通信模式，状态机是行为建模工具，二者互补而非互斥