时序图 vs 流程图：什么时候该画时序图？（判断规则 + 典型例子）

先给结论：你在回答的问题不一样

如果你只记一句话：

• 流程图回答的是：“事情怎么走（步骤/分支/决策）”——把一个流程从开始到结束的节点画清楚。
• 时序图（UML 序列图）回答的是：“谁在什么时候对谁说了什么（交互/消息/调用顺序）”——把多个参与者之间的消息往来按时间顺序画清楚。

所以，“什么时候该画时序图？”其实等价于：

当你的问题核心是 多参与者交互、调用先后顺序、同步/异步、超时重试/回调、并发、边界与异常——流程图很难把这些讲明白时，就该用时序图。

接下来我会把判断规则讲得更可执行，并给你一套交付时的组合用法：流程图管“流程”，时序图管“交互”，两张图一起用，往往比单张图更省沟通成本。

你也可以用在线工具快速把文字交互变成规范图：手打时序图 - 时序图在线制作

一张对比表背后的本质差异（别只背结论）

很多文章会用表格对比“时序图 vs 流程图”，但真正能帮你做决策的是：你要表达的“信息结构”是什么。

1）表达目标不同：流程图是“状态迁移”，时序图是“消息往来”

• 流程图擅长表达：

  • 业务步骤：A → B → C
  • 决策分支：如果 X 就走 D，否则走 E
  • 人工/系统混合步骤：填表、审核、回退
  • “有没有走到某一步”的路径覆盖（测试很爱用）

• 时序图擅长表达：

  • 参与者（Actor / 系统 / 服务 / 组件）之间的调用链
  • 请求与响应的先后关系
  • 同步 vs 异步（例如发消息、回调、事件驱动）
  • 超时、重试、幂等、补偿等“交互侧”问题

一个很实用的判断：

• 如果你写的是“用户点击 → 页面跳转 → 提交表单 → 审核通过/拒绝”，流程图更直观。
• 如果你写的是“前端 → 网关 → 订单服务 → 支付服务 → 第三方支付 → 回调 → 风控 → 通知”，时序图更直观。

2）时间维度不同：时序图把“先后”当一等公民

流程图当然也有先后顺序，但它的顺序是“流程节点顺序”。

时序图的顺序是“消息在时间轴上的发生顺序”。这会带来两个关键能力：

1. 你能清楚标出 谁先调用谁，以及每个参与者在何时处于活跃状态（Activation）。
2. 你能表达流程图里很容易糊掉的情况：
   • A 调用 B 后 并不等待，而是继续做别的（异步）
   • B 的返回结果可能在 很久之后通过回调回来
   • 并行分支真正的“并发”而不是“看起来分叉”

3）参与者视角不同：流程图弱化“边界”，时序图强调“边界”

流程图经常把“系统”当成一个整体：节点是“校验”“下单”“发货”。

时序图会逼你回答：

• 校验到底发生在哪个组件？前端？网关？服务端？
• 下单是订单服务做的，还是网关做的？还是调用了库存服务？
• 发货是谁发的？仓储系统？第三方？

这件事对研发/测试/架构非常关键：

• 研发需要知道“我负责的边界在哪，接口是什么”。
• 测试需要知道“哪个环节可控，哪个环节要 mock，异常怎么注入”。
• 架构需要知道“跨服务调用链长不长，有没有不合理耦合”。

什么时候该画时序图：8 条判断规则（能直接照着用）

下面这 8 条，建议你当成“开工前自检”。满足越多条，越该画时序图（至少补一张）。

规则 1：参与者 ≥ 3 个，而且每个都有明确职责

典型场景：前端、BFF/网关、业务服务、外部系统。

• 只有 1~2 个参与者？流程图或文字说明可能就够。
• 3 个以上且职责不同？时序图能把“谁对谁负责”画清楚。

规则 2：你需要回答“先后顺序会影响结果吗？”

例如：

• 必须先锁库存再下单？还是先下单再锁库存？
• 风控在支付前还是支付后？
• 先写库还是先发消息？

只要顺序影响结果（尤其是异常结果），时序图价值就很高。

规则 3：存在同步/异步混用、回调或事件驱动

流程图常见的误导是：

它看起来像“走一步下一步”，但现实中很多系统不是这样。

有下面任何一个关键词，就建议画时序图：

• 回调（callback / webhook）
• MQ / 事件总线
• 异步任务（job）
• 长轮询 / SSE / WebSocket
• 延迟队列 / 重试队列

规则 4：你需要把“失败怎么处理”讲明白

比如：

• 超时重试：谁重试？重试几次？间隔？是否幂等？
• 降级熔断：熔断发生在哪一层？返回给谁？
• 补偿：失败后是否要反向操作？谁负责触发补偿？

这些都属于交互协议的一部分。流程图可以有“失败分支”，但很难表达“失败发生在调用链的哪个位置”。

规则 5：你在写接口文档/联调说明/测试用例

面向“要落地的人”的材料（研发、测试、写文档的人）通常都需要回答：

• 请求从哪里发起？
• 经过哪些服务？
• 每一步的输入输出是什么？
• 哪些步骤可观测（日志/指标/trace）？

这其实就是时序图的强项。

规则 6：你需要表达“并发”或“竞争条件”

例如：

• 同一用户连续点击两次提交
• 同一订单被两个回调重复通知
• 同一库存被多笔订单争抢

流程图画并发很容易变成“分叉两条线”，但并发的关键是同时发生以及相互影响。时序图配合 par（并行片段）更清晰。

规则 7：跨团队/跨系统协作，需要对齐责任边界

只要你要跟别的团队对齐（支付、风控、物流、第三方平台），时序图往往是“对齐契约”的最短路径。

流程图更多是“我们内部怎么走”。时序图更像“我们和外部怎么说话”。

规则 8：你发现自己写了很多“然后/之后/接着”但仍然容易误解

当文字描述里出现大量：

• “然后 A 再去调用 B”
• “之后 B 会回调 A”
• “接着 A 再通知 C”

而读者还是问“先后顺序到底怎样？”——把它画成时序图，通常立刻清晰。

典型例子：同一个需求，用流程图和时序图分别怎么表达

这里用一个常见需求：“用户提交订单并支付” 来对比。

用流程图表达（适合产品/业务说明）

流程图会强调：

1. 用户提交订单
2. 系统校验参数
3. 创建订单
4. 进入支付
5. 支付成功/失败分支
6. 成功后发货/通知

这种表达对产品、运营、甚至写 PRD 很友好：你能快速看清“流程节点”。

但它天然会弱化这些关键问题：

• 创建订单时是否锁库存？
• 支付成功是“前端拿到结果”还是“回调确认成功”？
• 回调失败要不要重试？谁重试？

用时序图表达（适合研发/测试/联调）

时序图会强调：

• 前端 → 网关：创建支付
• 网关 → 订单服务：创建订单（返回订单号）
• 订单服务 → 库存服务：锁库存（失败则回滚）
• 前端 → 支付渠道：拉起支付
• 支付渠道 → 回调接口：通知支付结果（可能重复）
• 回调接口 → 订单服务：更新订单状态（幂等）
• 订单服务 → 通知服务：发消息

这张图基本能回答“你们到底怎么联调”的问题。

如果你希望把这些参与者、消息、激活条、组合片段（alt/opt/loop/par）快速拼出来，可以用这个编辑器：左侧点选生命线/消息/组合片段，右侧实时预览，最后一键导出 SVG/PNG/JPEG/draw.io，便于放进 PRD/技术文档/测试报告里：

• 手打时序图 - 时序图在线制作
• 流程图在线制作 - AI生成 | 自动排版

常见误解：为什么你画的流程图“看起来对”，但研发/测试还是不买账

下面是我见过最常见的几类“沟通翻车点”。每一条都给出反例和修正方式。

误解 1：把“组件调用”当成“流程节点”

反例：流程图里一个节点写“调用支付服务”，下一步写“支付服务回调”。

问题是：

• 回调是支付服务主动发起的，还是由我们轮询拉取？
• 回调到哪个服务？网关？订单服务？回调服务？
• 如果回调重复，谁负责幂等？

修正：把“调用”从流程节点里拆出来，画时序图：明确参与者、消息方向、同步/异步。

误解 2：用流程图画“并发”，实际上是“顺序分叉”

反例：流程图分出两条线：一条“写订单”，一条“发消息”，看起来像并行。

但真实问题是：

• 两个动作是不是必须都成功？
• 先写库还是先发消息？
• 其中一个失败怎么办？

修正：用时序图 par（并行）或明确顺序；如果用事件驱动，画出消息队列参与者与消费顺序。

误解 3：只画“成功路径”，异常全靠脑补

反例：流程图从“支付成功”直接到“发货”，没有任何失败分支。

现实里最难的是：

• 超时
• 重试
• 回调丢失
• 重复回调
• 部分失败（库存锁了但支付没成功）

修正：至少用时序图把 3 类异常补齐：

1. 调用超时（谁重试）
2. 异步结果迟到（回调/事件）
3. 重复消息（幂等）

误解 4：把“业务规则”混进“交互协议”导致边界模糊

反例：流程图写“校验库存”，但没说是“我们自己校验”还是“库存服务校验”。

修正：流程图里保留业务节点（校验库存/创建订单），时序图里明确“谁执行”。两张图分工明确。

推荐的交付方式：两张图怎么配合最省力

如果你在写 PRD / 技术方案 / 测试用例，我建议用下面这个组合：

1. 一张流程图：讲清业务步骤、分支、人工节点（给产品/业务/新人看）
2. 一张时序图：讲清参与者、消息、先后、异常（给研发/测试/联调看）

交付清单（拿来就能用）

流程图至少包含

• 起点/终点定义清晰
• 关键决策点（if/else）完整
• 业务口径一致（状态名统一）
• 人工步骤与系统步骤区分

时序图至少包含

• 生命线命名一致（系统/服务/组件不要混叫）
• 同步/异步消息用不同箭头区分
• 关键返回值/状态变更有标注（别全靠读者猜）
• alt 片段补齐主要分支（成功/失败/风控拦截等）
• loop 表达重试（标清次数/条件）
• opt 表达可选步骤（例如“如果开启风控则…”）
• 有外部系统时，画清边界（第三方/回调方向）

场景拆解：3 个“应该用时序图”的高频业务

为了让判断更直观，这里给 3 个常见场景，你可以对照自己的需求。

场景 1：登录（验证码/失败重试/风控）

为什么流程图不够：

• 验证码可能来自短信服务（异步）
• 风控可能在多个点触发（登录前/登录后）
• 失败重试有次数与间隔

时序图里你可以明确：

• 前端、认证服务、短信服务、风控服务、用户服务的交互
• alt：验证码正确/错误/过期
• loop：重试次数

场景 2：下单-支付-回调（超时/补偿/重复回调）

为什么流程图不够：

• “支付成功”往往不是前端结果，而是回调确认
• 回调可能重复，必须幂等
• 支付成功但发货失败需要补偿

时序图里可以补齐：

• 回调方向与签名校验
• 幂等键
• 失败重试与补偿触发者

场景 3：接口调用（超时/熔断/降级）

为什么流程图不够：

• 超时发生在哪一跳？客户端？网关？服务间？
• 熔断发生在哪一层？返回给谁？

时序图里可以画：

• 调用链中的每一跳
• alt：成功/超时/熔断
• opt：降级逻辑

FAQ：时序图和流程图的常见问题（含踩坑提醒）

Q1：能不能只画流程图，不画时序图？

可以，但通常只适用于：

• 参与者少（1~2 个）
• 没有异步/回调
• 异常处理简单
• 不需要跨团队联调

一旦你要落到研发/测试，很多“默认假设”会让人反复追问。那时补画时序图反而更费。

Q2：能不能只画时序图，不画流程图？

也可以，尤其在纯技术沟通里。

但当你要让产品/业务快速理解全局，“一张流程图讲业务步骤”会更友好。时序图在非技术读者眼里可能信息密度过高。

Q3：流程图里已经有分支了，时序图还需要 alt 吗？

需要，原因是两者分支的“含义”不同：

• 流程图分支：业务路径
• 时序图 alt：交互条件（在什么条件下，发生哪组消息）

如果你只在流程图里写“支付失败”，却不在时序图里画“失败发生在哪一步”，研发和测试仍然不知道如何处理。

Q4：时序图要画到什么粒度？画太细会不会维护成本高？

建议按“读者是谁”定粒度：

• 给联调：画到接口级（URL/方法/事件名）
• 给内部评审：画到服务级（订单服务→库存服务）
• 给产品：画到系统级（App→后端→第三方）

不要把“每个内部函数调用”都画进去。时序图的目标是对齐协作边界与关键协议，不是画代码执行栈。

Q5：我画的时序图总是很乱，有没有快速整理方法？

有三个非常实用的整理策略：

1. 先列生命线，再补消息：先确定参与者（用户/前端/网关/服务/第三方），不要边画边加。
2. 用组合片段收拢复杂度：
   • alt 收拢分支
   • loop 收拢重试
   • opt 收拢可选步骤
   • par 收拢并行
3. 把“异常”当作第一等公民：异常路径单独用 alt 分出来，不要用注释糊过去。

如果你嫌排版麻烦，建议直接用可视化编辑器：左侧点选生命线/消息/组合片段快速搭结构，右侧实时预览随时校对；需要放文档时导出 SVG/PNG/JPEG；要继续加工就导出 draw.io 交给团队二次编辑。

工具入口（带文章追踪参数）：手打时序图 - 时序图在线制作

最后一段：把“画图”当成对齐成本，而不是仪式

画流程图不是为了“看起来专业”，画时序图也不是为了“UML 正统”。它们的价值只有一个：减少误解，降低返工。

• 当你在对齐“业务路径”时，用流程图。
• 当你在对齐“交互协议与责任边界”时，用时序图。

把这两张图配合起来，你会发现很多争论根本不需要吵：图一画，问题自己就暴露出来了。

加餐：再给你 3 个“画错了就会返工”的反例（以及怎么改）

很多团队不是不会画图，而是画出来的图无法支撑落地：研发拿着没法实现、测试拿着没法设计用例、文档放进去读者看不懂。下面 3 个反例非常典型，你可以对照自己的图做一次自查。

反例 A：流程图把“接口协议”省掉，只剩业务词

常见画法：

• 节点写“校验参数”“创建订单”“调用支付”“更新状态”

问题：

• “校验参数”到底谁校验？前端校验还是后端校验？失败返回码是什么？
• “调用支付”是同步下单还是先拿预支付单？是否有签名？
• “更新状态”由谁触发？前端回传？回调确认？还是消息消费？

怎么改：

• 流程图继续保留这些业务节点 流程图在线制作 - AI生成 | 自动排版，但补一张时序图：把关键节点对应的接口/事件/回调补齐。
• 时序图里把每条关键消息至少标出：方向（谁→谁）/消息名/关键入参/关键返回值或状态变化。

反例 B：时序图只画“调用链”，不画“条件与异常”

常见画法：

• 从 A 到 B 到 C 一路同步调用，看起来很顺，但没有任何 alt/opt/loop。

问题：

• 真实系统里异常比成功更复杂：超时、重试、降级、回调失败、重复消息……
• 你不画，评审时就会出现“默认假设不同”：有人以为会重试，有人以为不会；有人以为失败要回滚，有人以为允许最终一致。

怎么改：

• 至少补三类 alt 分支：
  1. 关键失败（例如支付失败/库存不足/风控拦截）
  2. 技术失败（超时/网络错误/服务不可用）
  3. 重复与迟到（重复回调/重复消息/迟到回调）
• 把“重试”用 loop 表达，并写清触发条件与上限（次数/间隔/是否指数退避）。

反例 C：流程图和时序图“说的不是同一件事”

常见画法：

• 流程图写“支付成功→发货”，但时序图里支付成功后没有任何通知/消息，或者发货由另一个系统触发。

问题：

• 两张图的口径不一致，读者会不知道该信哪张；更糟的是，后续维护的人会用错误的图做决策。

怎么改：

• 给每个“关键业务节点”建立映射：流程图的节点，对应时序图里的哪一段消息片段。
• 在时序图里用注释或片段标题标出：“这里对应流程图的【创建订单】节点”。
• 保持术语一致：同一个系统/服务/状态，不要在两张图里用不同名字。

评审用检查清单：这张图能不能作为交付物？

你可以在评审时直接按下面清单过一遍（特别适合架构评审、接口评审、测试评审）。

流程图评审（业务正确性）

• 起点和终点定义清晰（什么叫“完成/失败/取消”）
• 决策条件可判定（不是“视情况而定/可能/大概”）
• 每条分支都能走到某个终点（避免“悬空路径”）
• 业务状态、字段名、口径与 PRD/接口文档一致
• 人工步骤与系统步骤有区分（避免把人工动作当系统自动）

时序图评审（可实现、可测试）

• 参与者边界清晰（哪些在本系统内，哪些是外部）
• 同步/异步表达正确（不要把异步画成同步等待）
• 每个关键调用都有对应的错误处理分支（至少覆盖超时/失败返回）
• 幂等点标清（回调/消息消费/重试入口）
• 重试策略明确（谁重试、最大次数、是否需要去重）
• 可观测性入口明确（关键日志、trace、指标建议落在哪一段）

文档落地（让别人用得起来）

• 图里出现的术语在正文里有解释（尤其是缩写和内部名词）
• 图的导出格式适配你的交付渠道：
  • 放 PRD/技术文档：优先 SVG（清晰可缩放）
  • 发群里快速对齐：PNG/JPEG
  • 团队要二次编辑：draw.io
• 版本可维护：图和接口/状态变更的版本号或更新时间能追踪

很多人卡在“排版太费时间”。更现实的做法是：先用编辑器把结构搭出来——左侧点选生命线、消息、组合片段快速补齐；右侧实时预览检查对齐；最后按场景导出 SVG/PNG/JPEG 或 draw.io 给团队继续维护。对于需要快速起草的场景，还可以让 AI 先从你的文字描述生成初稿，再由你做口径校正。

• 手打时序图 - 时序图在线制作
• 流程图在线制作 - AI生成 | 自动排版