1. 状态与事件基础：状态的定义、事件的定义、状态机模型入门
好，咱们开始第一课。状态与事件，这两个词听起来挺抽象，但说白了，它们就是软件世界里最基础的两个概念。你写的每一行代码，几乎都在跟它们打交道。
我记得刚入行那会儿，带我的老大哥跟我说过一句话，我一直记到现在：「没有状态的程序是玩具，没有事件的系统是死水」。当时不太理解，后来踩的坑多了，才慢慢品出味道来。
1.1 状态的定义：程序在某个时刻的「快照」
什么是状态？我的理解很简单——状态就是程序在某一时刻所有「值得记住」的信息的总和。
你想想看，一个用户登录了系统，系统需要记住「当前用户是谁」「他的权限级别是什么」「他有没有未完成的订单」。这些信息加在一起，就是系统在那一刻的状态。
核心要点：状态 = 数据 + 数据之间的约束关系
不只是变量的值，还包括这些值必须满足的规则。比如「订单状态为'已支付'时，支付金额必须大于0」——这就是约束。
我在项目中遇到过一种常见误区：很多人把状态等同于数据库里的记录。其实不对。状态可以是瞬时的，比如一个按钮的「按下/弹起」；也可以是持久的，比如用户的账户余额。关键区别在于——状态的生命周期由业务逻辑决定，而不是由存储介质决定。
| 状态类型 | 生命周期 | 典型例子 | 存储位置 |
|---|---|---|---|
| 瞬时状态 | 请求级别 | HTTP请求的认证 | 内存/局部变量 |
| 会话状态 | 用户会话期间 | 购物车内容 | Redis/Session |
| 持久状态 | 永久（直到被修改） | 用户注册信息 | 数据库 |
| 派生状态 | 由其他状态计算得出 | 「订单总金额」 | 不存储，实时计算 |
我的习惯：设计状态时，先问自己三个问题——这个状态必须存在吗？它的生命周期有多长？如果丢失了会怎样？这三个问题能帮你筛掉至少一半不必要的状态。
1.2 事件的定义：让状态发生变化的「触发器」
状态本身是静态的。那状态怎么变？靠事件。
事件就是「已经发生的事情」的记录。它携带了「发生了什么」「什么时候发生的」「相关的数据是什么」这些信息。
举个例子：用户点击了「提交订单」按钮。这个点击动作本身不是事件——事件是「点击已经发生」这个事实。事件一旦发生，就不可撤销，不可修改。这是事件最重要的特性：不可变性。
// 一个典型的事件对象结构
{
"eventType": "OrderSubmitted", // 事件类型
"timestamp": 1712345678000, // 发生时间（毫秒时间戳）
"payload": { // 事件携带的数据
"orderId": "ORD-2024-001",
"userId": "U-10086",
"totalAmount": 299.00,
"items": [
{ "productId": "P-001", "quantity": 2 }
]
},
"metadata": { // 元数据（可选）
"source": "web-frontend",
"traceId": "trace-abc-123"
}
}
为什么事件必须是不可变的？我踩过这个坑。曾经有个系统，事件生成后允许后续流程修改事件里的字段。结果排查线上问题时，根本搞不清「这个字段到底是事件发生时就是这个值，还是后面被人改过」。从那以后，我定了一条铁律：事件一旦生成，只读不写。
⚠️ 避坑指南：千万不要把「事件」和「命令」混为一谈。
- 命令：告诉系统「去做某事」（将来时）
- 事件：告诉系统「某事已经发生」（过去时）
我曾经见过一个团队把「DeleteUserCommand」当事件处理，结果事件溯源时发现「用户被删除了」这个事件居然可以被撤销——逻辑上就说不通。
1.3 状态与事件的关系：鸡生蛋还是蛋生鸡？
状态和事件，其实是互相定义的：
- 事件改变状态：一个事件被处理，状态就发生一次跃迁
- 状态决定事件能否发生：比如「已取消」的订单不能再触发「支付成功」事件
这种关系，用一张图就能看得很清楚：
这张图想表达的核心就一句话：状态是事件处理的结果，事件是状态跃迁的原因。两者缺一不可。
1.4 状态机模型入门：让复杂逻辑变得可预测
好了，现在有了状态和事件，怎么把它们组织起来？这就轮到状态机登场了。
状态机（State Machine）是一种数学模型，它规定了：在什么状态下，接收到什么事件，应该转移到什么新状态，以及执行什么动作。
说白了，状态机就是一张「如果…那么…」的规则表。我特别喜欢用状态机来处理那些「状态多、分支多、容易乱」的业务逻辑。比如订单流程、工作流审批、游戏角色行为——这些场景用 if-else 写出来，代码能绕地球三圈，但用状态机，一张表就讲清楚了。
一个经典的例子：订单状态机
咱们拿电商订单来举例。一个订单从创建到完成，会经历这些状态：
状态集合：{ 待支付, 已支付, 已发货, 已签收, 已取消, 已退款 }
事件集合：{ 支付成功, 发货, 签收, 申请取消, 确认取消, 申请退款 }
状态转移规则（部分）：
1. 待支付 + 支付成功 → 已支付
2. 待支付 + 申请取消 → 已取消
3. 已支付 + 发货 → 已发货
4. 已支付 + 申请取消 → 申请取消中（中间状态）
5. 已发货 + 签收 → 已签收
6. 已签收 + 申请退款 → 已退款
为什么用状态机？三个理由：
- 可预测性：给定当前状态和事件，下一个状态是确定的
- 可追溯性：所有状态跃迁都有记录，方便排查问题
- 可维护性：新增一个状态或事件，只需要改规则表，不用动业务逻辑
我记得有一次接手一个遗留系统，订单状态逻辑散落在十几个 Service 方法里，每个方法里都有三四个 if-else 判断「如果当前状态是X，才能执行Y」。改一个需求，要翻遍所有代码，还经常漏掉某个分支。后来我花了两天时间，把所有状态转移逻辑抽成一个状态机配置表——从那以后，改订单流程再也没出过线上事故。
状态机的三个核心要素
| 要素 | 说明 | 举例 |
|---|---|---|
| 状态（State） | 系统在某个时刻的稳定局面 | 待支付、已支付、已发货 |
| 事件（Event） | 触发状态转移的外部输入 | 支付成功、发货、签收 |
| 转移（Transition） | 状态 + 事件 → 新状态 + 动作 | 待支付 + 支付成功 → 已支付（发送通知） |
一个小技巧：设计状态机时，先画出所有「正常流程」的转移，再补上「异常流程」的转移。很多人只画了 happy path，结果线上出现「已取消的订单还能发货」这种 bug——就是因为忘了定义异常路径的转移规则。
状态机的两种实现方式
实际编码中，状态机有两种主流实现方式：
- 表驱动状态机：用二维表（状态 × 事件）来定义转移规则。适合状态和事件数量有限、规则明确的场景。
- 状态模式（State Pattern）：每个状态封装成一个类，状态之间的转移通过多态实现。适合状态行为复杂、每个状态有独立逻辑的场景。
我个人习惯：业务逻辑简单的用表驱动，业务逻辑复杂的用状态模式。没有银弹，看场景选。
// 表驱动状态机的核心数据结构（伪代码）
const stateMachine = {
currentState: 'pending',
// 转移规则表
transitions: {
'pending': {
'pay_success': { to: 'paid', action: 'sendNotification' },
'cancel': { to: 'cancelled', action: 'refundStock' }
},
'paid': {
'ship': { to: 'shipped', action: 'updateLogistics' },
'cancel': { to: 'refunding', action: 'startRefundProcess' }
},
'shipped': {
'confirm': { to: 'completed', action: 'markAsDone' },
'return': { to: 'returning', action: 'createReturnOrder' }
}
},
// 处理事件
handle(event) {
const rule = this.transitions[this.currentState]?.[event.type];
if (!rule) {
throw new Error(`不允许的转移: ${this.currentState} + ${event.type}`);
}
this.currentState = rule.to;
// 执行动作...
}
};
⚠️ 注意：表驱动状态机虽然简洁，但有一个隐藏陷阱——状态爆炸。当状态和事件数量都超过10个时，转移规则表会膨胀到100+条。这时候就要考虑用层次状态机（HSM）或者状态模式来拆分了。
1.5 本章小结
这一章咱们把最基础的概念捋了一遍：
- 状态是程序在某个时刻的快照，有瞬时、会话、持久、派生四种类型
- 事件是已经发生的事实的记录，不可变、不可撤销
- 状态机用「状态 + 事件 → 新状态」的规则，让复杂逻辑变得可预测