状态图绘制规范：UML标准与命名艺术
状态图这东西，说白了就是状态机的「设计蓝图」。我见过太多工程师，代码写得飞起，但一画状态图就乱成一锅粥。嗯，今天我们就来聊聊，怎么把状态图画得既规范又漂亮。
一、UML状态图标准：别自己发明轮子
UML（统一建模语言）早就给我们定好了规矩。我个人习惯，画状态图一定遵循UML 2.5标准。为什么？因为团队里每个人都能看懂，不用猜。
先看一个标准的状态图骨架：
┌─────────────┐
│ 初始状态 │
└──────┬──────┘
│
▼
┌─────────────┐ event1/action1 ┌─────────────┐
│ State_A │ ──────────────────────► │ State_B │
│ │ ◄────────────────────── │ │
└─────────────┘ event2/action2 └─────────────┘
│
│ event3/action3
▼
┌─────────────┐
│ State_C │
└─────────────┘
│
▼
┌─────────────┐
│ 终止状态 │
└─────────────┘UML状态图的核心元素就这几个：
- 初始状态：实心圆点，表示状态机从哪里开始跑
- 状态：圆角矩形，里面写状态名
- 转移：带箭头的线，上面标注「事件/动作」
- 终止状态：实心圆点加个圈，表示状态机结束
⚠️ 我曾经踩过的坑： 有次画状态图，把初始状态画成了空心圆，结果新来的同事以为是「可选入口」。从那以后，我规定团队：初始状态必须是实心圆，终止状态必须是「牛眼」——实心圆外套个圈。
二、状态命名规范：让名字自己说话
状态命名这件事，我见过最离谱的是用S1、S2、S3... 你想想看，三个月后你自己都分不清S1是干啥的。
我建议的命名原则：
- 动词+名词：比如 Idle（空闲）、Receiving（接收中）、Processing（处理中）
- 形容词+状态：比如 Ready（就绪）、Error（错误）、Timeout（超时）
- 统一时态：要么全用现在分词，要么全用过去分词，别混着来
| 推荐命名 | 不推荐命名 | 说明 |
|---|---|---|
| Idle | S1 | 一看就知道是空闲状态 |
| Receiving | Recv | 完整单词，避免缩写歧义 |
| ErrorDetected | Err | 明确是「检测到错误」的状态 |
| WaitForAck | WA | 缩写让人猜谜 |
💡 我的小技巧： 状态名控制在3个单词以内，太长就考虑拆成子状态。我在做物联网网关项目时，有个状态叫「WaitingForServerResponseAndTimeoutHandling」——后来被同事骂惨了。
三、事件命名规范：动词开头，清晰明了
事件就是「什么东西触发了状态转移」。我习惯用动词过去式或名词+动词的格式。
举个例子：
// 好的事件命名
evPacketReceived // 数据包已收到
evTimeout // 超时发生
evButtonPressed // 按钮被按下
evDataReady // 数据已就绪
// 不好的事件命名
ev1 // 鬼知道是什么
packet // 是收到还是发送？
doSomething // 太模糊了为什么会这样？因为事件是「已经发生的事情」，用过去式最自然。你想想看，「按钮被按下」这个事件，用 evButtonPressed 是不是比 evPressButton 更符合直觉？
📌 命名规范总结：
- 事件名：ev + 动词过去式 + 名词（如 evPacketSent）
- 动作名：do + 动词原形 + 名词（如 doSendPacket）
- 状态名：名词/形容词（如 Idle、Error）
四、动作标注规范：入口、出口、转移动作
UML状态图里，动作可以挂在三个地方：
- 入口动作：进入状态时执行，标注为 entry / do
- 出口动作：离开状态时执行，标注为 exit
- 转移动作：转移过程中执行，标注在箭头上
看个实际例子：
┌─────────────────────┐
│ Receiving │
│ │
│ entry/ initBuffer │
│ do/ readData │
│ exit/ checkCRC │
└──────────┬──────────┘
│
│ evPacketComplete / doProcessPacket
▼
┌─────────────────────┐
│ Processing │
│ │
│ entry/ startTimer │
│ exit/ stopTimer │
└─────────────────────┘这里要注意：
- 入口动作：每次进入状态都会执行，适合做初始化
- 出口动作：每次离开状态都会执行，适合做清理
- 转移动作：只在特定转移路径上执行
⚠️ 我曾经犯过的错： 有次把出口动作写成了转移动作，结果状态正常退出时没做清理，导致内存泄漏。排查了两天才找到原因。所以记住：「退出必清理，进入必初始化」。
五、实战：一个完整的状态图示例
我们来看一个串口接收状态机的完整例子：
┌──────────┐
│ Idle │
│ entry/ │
│ reset() │
└────┬─────┘
│
│ evStartBitDetected / doSampleStartBit
▼
┌──────────┐
│ Receiving│
│ entry/ │
│ clrBuf()│
│ do/ │
│ readBit │
│ exit/ │
│ chkParity│
└────┬─────┘
│
│ evStopBitReceived / doAssembleByte
▼
┌──────────┐
│ Ready │
│ entry/ │
│ notify()│
└──────────┘这个图里，每个状态都有明确的入口/出口动作，转移事件清晰，动作标注规范。拿到这个图，任何工程师都能写出对应的代码。
💡 我的经验： 画状态图时，先画大框架，再补细节。我一般先用白板画草稿，确认逻辑没问题了，再用工具画正式图。千万别一上来就纠结箭头画得直不直。
六、常见错误与避坑指南
这些年我评审过的状态图，少说也有上百张。总结几个高频问题：
- 缺少初始状态：状态机从哪开始？别让读者猜
- 状态名重复：同一个名字出现在不同位置，容易混淆
- 事件名太抽象：evDo 这种名字，跟没写一样
- 动作标注位置错误：把转移动作写成入口动作，逻辑就乱了
- 缺少终止状态：状态机什么时候结束？不是所有状态机都需要终止，但需要时别漏了
嗯，规范这东西，一开始觉得麻烦，但养成习惯后，你会发现团队沟通效率翻倍。我带的团队，现在画状态图都遵循这套规范，代码review时基本不用问「这个状态是干啥的」这种问题。
记住：好的状态图，自己会说话。