关键词：时序图、Sequence Diagram、UML、系统交互图、接口设计文档
导语
时序图（Sequence Diagram）是 UML 交互图中最常用的一种，用于描述对象之间消息传递的时间顺序。在接口设计、系统交互分析、技术方案评审中，一张清晰的时序图往往比几千字文字描述更高效。
然而在实际工作中，很多时序图存在消息类型混用、生命线管理混乱、异常分支缺失等问题，导致图表不仅没有降低沟通成本，反而增加了理解负担。
本文从核心概念、符号规范、绘制步骤、常见错误四个维度，提供一套可直接落地的时序图绘制方法论。
一、时序图的核心概念
时序图回答一个核心问题：系统中多个对象，在时间维度上如何协作完成一个功能？
| 概念 | 说明 | 类比 |
|---|---|---|
| 生命线（Lifeline） | 代表一个对象或参与者，从上到下延伸 | 剧本中的一个角色 |
| 激活条（Activation Bar） | 生命线上的矩形区域，表示对象正在执行操作 | 角色正在说话的时间段 |
| 消息（Message） | 对象之间的通信，用箭头表示 | 角色之间的对话 |
| 组合片段（Combined Fragment） | 用矩形框包裹一段交互，标注条件/循环/并行 | 剧本中的场景说明 |
理解这四个概念，就掌握了时序图的基本骨架。
二、消息类型规范（最容易出错的地方）
时序图中最常犯的错误就是消息类型混用。以下是四类消息的严格区分：
| 消息类型 | 符号样式 | 适用场景 | 代码对应关系 |
|---|---|---|---|
| 同步消息 | 实线 + 实心箭头 → | 调用方等待返回后才继续 | 方法调用（阻塞） |
| 异步消息 | 实线 + 开放箭头 ⤳ | 调用方不等待返回 | 事件触发、消息队列发送 |
| 返回消息 | 虚线 + 开放箭头 ⇠ | 方法返回值 | return 语句 |
| 自调用 | 嵌套激活条 | 对象调用自身方法 | 递归、内部方法调用 |
高频错误：将 HTTP 请求标为同步消息。实际上大多数 HTTP 客户端采用异步回调机制，应使用异步消息箭头。又如 Ajax 请求、WebSocket 推送、消息队列消费，都属于异步消息。
核心原则：每个同步消息都应有对应的返回消息，即使方法返回 void。遗漏返回箭头是时序图最常见的缺陷。
三、组合片段：处理复杂逻辑
当业务流程包含条件判断、循环、并行处理时，需要使用组合片段来清晰表达。
| 片段类型 | 标签 | 用途 | 示例 |
|---|---|---|---|
| 条件分支 | alt | 互斥的多选一 | 库存充足走下单流程，不足走提示流程 |
| 可选执行 | opt | 满足条件才执行 | 优惠券有效时执行扣减 |
| 循环 | loop | 重复执行 | 批量验证购物车中每个商品 |
| 并行 | par | 同时执行多个操作 | 并行调用风控服务和库存服务 |
使用建议：
- alt 内部用虚线分隔多个分支，每个分支标注条件（如
[余额充足]、[余额不足]）
- loop 标注循环条件（如
[对每个商品]）
- 组合片段可以嵌套，但建议不超过两层，否则图表可读性急剧下降
四、绘制步骤：五步法
第一步：识别参与者（1分钟）
列出所有参与交互的对象，包括：
- 外部角色（用户、第三方系统）
- 系统内部组件（前端、API网关、服务层、数据库）
- 第三方服务（支付网关、短信平台）
技巧：用 < 构造型标记外部系统，与内部组件视觉区分。
第二步：确定布局顺序（1分钟）
遵循"核心对象居中原则"：
- 发起交互的主控对象置于最左侧
- 核心业务对象沿对角线向右下方排列
- 外部服务置于最右侧
- 保持相邻对象间交互密度均衡
反模式：消息跨越多条生命线交叉传递，导致线条混乱。调整对象顺序形成"消息瀑布流"即可解决。
第三步：绘制主干消息流（2分钟）
先画出正常路径（Happy Path）的消息流，从上到下按时间顺序排列。暂不处理异常分支。
第四步：补充异常分支和组合片段（2分钟）
在主干流程基础上添加：
- alt 片段处理条件分支
- loop 片段处理循环逻辑
- 异常路径（如超时重试、降级处理）
第五步：校验完整性（1分钟）
逐项检查：
- 每个同步消息是否有对应返回消息
- 消息类型是否正确（同步/异步/返回）
- 激活条是否正确对应方法执行时段
- 生命线是否在对象不再参与交互时终止
- 组合片段是否完整（条件标注、分隔线）
五、常见错误清单
| 错误 | 后果 | 正确做法 |
|---|---|---|
| 消息类型混用 | 开发者误判调用方式，导致线程阻塞 | 严格区分同步/异步/返回消息 |
| 遗漏返回箭头 | 流程不完整，开发者不知道方法何时结束 | 每个同步调用都画返回消息 |
| 生命线过早终止 | 对象还在交互却已消失 | 生命线延伸到最后一次消息之后 |
| 过度细节 | 画出每个 getter/setter 调用 | 只保留业务关键消息，省略技术细节 |
| 异常分支缺失 | 只画 Happy Path，异常场景无指引 | 用 alt 片段补充异常处理路径 |
| 组合片段嵌套过深 | 图表复杂到无法阅读 | 嵌套不超过两层，复杂逻辑拆成多张图 |
六、工具选择建议
| 工具 | 特点 | 适合场景 |
|---|---|---|
| PlantUML | 用代码写图，版本控制友好 | 开发团队、技术文档 |
| Draw.io | 免费开源，拖拽式 | 个人使用、快速绘制 |
| ProcessOn | 国内模板丰富，支持协作 | 团队协作、模板复用 |
| Mermaid | Markdown 内嵌，实时预览 | 技术博客、README 文档 |
PlantUML 快速示例：
七、最佳实践总结
- 先列参与者，再画消息：顺序不能反，否则容易遗漏关键对象
- 主干优先，异常补充：先画 Happy Path，再添加异常分支
- 消息类型严格区分：同步实线、异步虚线、返回虚线箭头，不可混用
- 复杂逻辑拆图：超过 8 条生命线或 3 层嵌套，拆成多张子图
- 配套文字说明：时序图不能完全替代文字，关键决策点需补充说明
- 纳入版本控制：用 PlantUML 或 Mermaid 将图表代码化，纳入代码仓库管理
本文为可视化知识库系列文章，更多内容请关注：架构图绘制指南、流程图设计规范、原型图实操教程、思维导图方法论。