序列图：是什么以及如何创建（2026 指南）
了解序列图是什么，UML 符号如何工作，以及何时将其用于 API 设计、微服务和认证流程。包含分步创建指南。
当分布式系统出现问题时，第一个问题通常是"什么与什么通信了，顺序是什么？"这正是序列图所回答的。它们显示对象、服务或用户如何随时间相互交互——使不可见的通信模式变得可见。
序列图是软件团队最实用的 UML 图表类型之一。它们弥合了高层架构和实际代码之间的差距，使其在 API 设计、调试微服务调用、记录认证流程和让工程师熟悉不熟悉的系统方面具有极高价值。
什么是序列图？
序列图是一种交互图，显示参与者（对象、服务、用户或系统）在特定场景中如何相互通信，按时间排序。垂直轴表示向下流动的时间。水平轴列出参与者。
与专注于单个流程逻辑的流程图不同，序列图专注于多个参与者之间交换的消息以及这些交换发生的顺序。
基本结构：
客户端 认证服务 数据库
| | |
|──── login() ────>| |
| |── findUser() ──>|
| |<── userData ────|
| |── verifyPwd() |
|<── JWT token ────| |
| | |
每条垂直线是一个生命线。每条水平箭头是一条消息。时间从上到下流动。
序列图的 UML 符号
生命线
生命线代表交互中的参与者。它由顶部的框（显示参与者名称）和向下延伸的虚线组成。
┌──────────┐ ┌──────────────┐ ┌──────────┐
│ 客户端 │ │ API 服务器 │ │ 数据库 │
└────┬─────┘ └──────┬───────┘ └────┬─────┘
│ │ │
│ （虚线向下延伸） │
命名约定：
- 系统/服务：大驼峰命名（
PaymentService、AuthAPI） - 角色/用户：普通名称（
User、Admin、Customer） - 实例：
objectName:ClassName符号（order:Order）
消息
消息是生命线之间的水平箭头。四种类型：
| 消息类型 | 箭头样式 | 含义 |
|---|---|---|
| 同步调用 | ────────> |
调用者等待响应 |
| 返回消息 | - - - - -> |
对同步调用的响应 |
| 异步消息 | ────────> |
调用者不等待（通常带开放箭头） |
| 自调用 | 箭头循环回来 | 对象调用自己的方法 |
激活条
激活条（或执行发生）是生命线上的窄矩形，显示该参与者何时处于活动状态——处理请求或执行逻辑。
│ │
│──── 调用 ───>│
│ ██ <- 激活条（参与者正在处理）
│<── 返回 ─────│
│ │
组合片段
组合片段允许你在序列图中显示条件和重复逻辑。它们显示为在左上角有标签的矩形框。
| 片段 | 标签 | 用途 |
|---|---|---|
| 循环 | loop |
重复序列（指定条件或计数） |
| 替代 | alt |
替代路径——类似 if/else 块 |
| 可选 | opt |
可选序列——仅在条件为真时执行 |
| 并行 | par |
并行执行——序列同时发生 |
| 引用 | ref |
引用另一个序列图 |
替代片段示例：
┌─ alt ─────────────────────────────────────┐
│ [凭据有效] │
│ AuthService ──── 发放 token ───> Client │
├────────────────────────────────────────────┤
│ [凭据无效] │
│ AuthService ──── 401 错误 ────> Client │
└────────────────────────────────────────────┘
循环片段示例：
┌─ loop [购物车中的每个商品] ─────────────────┐
│ OrderService ── 检查库存 ──> Inventory │
│ Inventory ─── 有货？ ──> OrderService │
└────────────────────────────────────────────┘
序列图 vs. 流程图
两种图表都对流程建模，但回答不同的问题。
| 方面 | 序列图 | 流程图 |
|---|---|---|
| 主要焦点 | 参与者之间的通信 | 单个流程内的逻辑流 |
| 轴 | 时间（垂直）+ 参与者（水平） | 通过方向箭头连接的步骤 |
| 显示 | 消息、顺序、时序 | 决策、分支、循环 |
| 多个参与者 | 原生支持——每个都有生命线 | 可以但没有泳道时很别扭 |
| 最适合 | API、协议、分布式系统 | 算法、业务流程 |
| 并行行为 | 通过 par 片段支持 |
难以表示 |
| 常见用户 | 软件工程师、架构师 | 业务分析师、产品团队 |
当关键问题是"系统 A 对系统 B 说了什么，何时说的？"时使用序列图。当问题是"这个流程的下一步决策是什么？"时使用流程图。
何时使用序列图
API 设计和文档
在写一行代码之前，序列图让你验证 API 合同。为功能绘制调用序列，然后与团队一起审查。你会在 bug 出现在生产环境之前发现缺失的端点、不正确的数据依赖关系和模糊的响应格式。
微服务通信
微服务架构很难推理，因为单个用户动作的流程通常跨越五个或更多服务。序列图使其可见：
用户 网关 OrderSvc InventorySvc PaymentSvc NotifySvc
| | | | | |
|── POST /order ───────>| | | |
| | |── check() ──>| | |
| | |<── ok ───────| | |
| | |── charge() ──────────────────>| |
| | |<── receipt ──────────────────| |
| | |── send() ──────────────────────────────────>|
|<── 201 Created ───────| | | |
认证流程
认证流程涉及多方（用户、浏览器、身份提供者、资源服务器）和严格的顺序要求。序列图是记录 OAuth 流程、SAML 断言和 JWT 验证链的标准方式。
调试生产事故
当事故发生时，重建发生的事情需要跨服务追踪调用。从日志和追踪数据绘制的序列图帮助团队比阅读原始日志更快地理解故障序列并找到根本原因。
入职和知识转移
加入团队的新工程师可以在几分钟内阅读序列图并理解复杂流程。对于交互密集的系统，这比阅读代码或散文文档更高效。
分步创建指南
第一步：定义场景
选择一个特定场景，而不是整个系统。好的范围：
- "用户使用 Google OAuth 登录"
- "客户以被拒绝的卡下订单"
- "服务 A 调用服务 B，服务 B 超时"
避免："认证系统"（太宽泛）。每个图表一个场景。
第二步：识别参与者
列出这个场景中涉及的每个角色或系统。常见参与者：
- 外部角色：用户、浏览器、移动应用
- 服务：API 网关、认证服务、订单服务
- 数据存储：数据库、缓存、消息队列
- 第三方：Stripe、Twilio、SendGrid
从左到右按它们首次出现的顺序排列，发起者在最左边。
第三步：列出消息
对于场景中的每个步骤，写下：
- 谁发送消息
- 谁接收
- 消息是什么（方法名、事件名或描述）
- 是否是同步还是异步
第四步：绘制序列
将参与者作为生命线放在顶部。按时间顺序（从上到下）绘制水平箭头的消息。添加激活条显示处理时间。将条件或重复逻辑分组到组合片段中。
┌──────────┐ ┌──────────────┐ ┌──────────┐
│ 浏览器 │ │ 认证服务器 │ │ 用户DB │
└────┬─────┘ └──────┬───────┘ └────┬─────┘
│ │ │
│──── POST /login ─────>│ │
│ ██ │
│ │── SELECT user ───────>│
│ │<── user record ────────│
│ ██ │
│<── 200 + JWT ─────────│ │
│ │ │
第五步：添加片段和注释
在序列有条件或重复逻辑的地方添加 alt、loop 或 opt 片段。对于无法整洁地放入消息标签的重要约束或解释，添加注释（在 UML 中显示为折叠矩形）。
第六步：与利益相关者验证
与拥有每个参与者的工程师或架构师一起走查图表。验证：
- 消息顺序正确吗？
- 在需要的地方包含返回消息了吗？
- 错误路径有体现吗？
- 有遗漏的内容吗？
常见模式
请求-响应
最基本的模式。调用者发送同步消息并等待返回。
客户端 服务器
│ │
│──── 请求 ────>│
│ ██
│<─── 响应 ─────│
│ │
带队列的异步消息
用于事件驱动架构。生产者不等待消费者处理消息。
生产者 消息队列 消费者
│ │ │
│── publish() ──>│ │
│<── ack ────────│ │
│ │── deliver() ──>│
│ │ ██
│ │<── done ───────│
错误处理模式
始终在正常路径旁边建模失败路径。
┌─ alt ──────────────────────────────────────────┐
│ [成功] │
│ Service ──── 200 OK ────────────────> Client │
├─────────────────────────────────────────────────┤
│ [未找到] │
│ Service ──── 404 Not Found ──────────> Client │
├─────────────────────────────────────────────────┤
│ [服务器错误] │
│ Service ──── 500 Internal Error ─────> Client │
└─────────────────────────────────────────────────┘
超时和重试
┌─ loop [重试次数 < 3] ─────────────────────────────┐
│ Client ──── 请求 ───────────────> Service │
│ ┌─ opt [5 秒内无响应] ────────────────────────┐│
│ │ Client ──── 检测到超时 ││
│ └───────────────────────────────────────────────┘│
└────────────────────────────────────────────────────┘
最佳实践
每个图表一个场景。 试图覆盖所有可能路径的序列图变得不可读。为正常路径、错误路径和边缘情况分别绘制图表。
将参与者限制在 5-7 个。 超过七条生命线会使水平空间成为问题。如果你有更多参与者，将相关服务组合为单个参与者，并为该组的内部创建单独的图表。
同步调用始终包含返回消息。 缺少返回箭头意味着调用者永远得不到响应。要明确。
精确标记消息。 "getMessage()" 比"获取数据"好。包括方法名、HTTP 动词和路径，或事件名称。避免"请求"或"响应"等模糊标签。
显示发起角色。 从触发序列的用户或外部系统开始，而不是从流程中间开始。
谨慎使用注释。 注释对约束很有用（"必须在 200 毫秒内完成"），但如果过度使用会使图表杂乱。
绘制错误路径。 正常路径是显而易见的。当图表也显示出错时发生什么时，它才变得有价值。
常见错误
在一个图表中建模整个系统。 这会产生一个太复杂以至于无法读取或维护的图表。将每个图表范围限制在一个特定的交互场景。
跳过返回消息。 只显示出去的调用而没有返回会创建不完整的图片。包括同步调用的返回消息。
混淆序列图和流程图。 添加决策菱形和分支箭头会将图表变成流程图混合体。用 alt 和 opt 片段代替条件。
错误的时间顺序。 图表上方的消息被认为发生得更早。将响应放在对应请求上方是常见错误。
消息标签中细节过多。 消息标签中的完整 JSON 负载使图表不可读。用消息标签表示名称；如果负载细节重要则添加注释。
忽略异步交互。 将每条消息都视为同步会隐藏重要的架构特性。明确标记异步消息。
使用 Flowova 创建序列图
手动记录 API 流程和服务交互很慢。Flowova 的序列图制作工具让你用纯文本描述你的流程并生成一个可以与团队一起视觉化编辑的结构化图表。粘贴描述，例如"用户提交登录表单，认证服务根据数据库验证凭据，成功时返回 JWT"，然后得到一个可以与你的团队优化的工作图表。
总结
当你需要理解或传达多个参与者之间的消息顺序和方向时，序列图是正确的工具。它们在 API 文档、微服务交互设计、认证流程规范和事件后期复盘方面表现出色。关键是将每个图表范围限制在一个场景，包括正常和错误路径，并与拥有每个参与者的人一起验证结果。从简单的请求-响应模式开始，只有在场景需要时才增加复杂性。
