流程图 vs 时序图：什么时候用流程图，什么时候用时序图

先把一句话讲清：你到底想让人“看懂什么”？

同一个需求，画成流程图和画成时序图，读者得到的信息完全不一样。

• 流程图（Flowchart / Activity）更像是“路线图”：强调步骤顺序、业务规则、分支条件、结束/失败路径。读者通常关心的是：这件事怎么做、在哪些地方做判断、什么情况下会终止/回滚。
• 时序图（Sequence Diagram）更像是“通话记录”：强调参与者之间谁先调用谁、消息往返顺序、同步/异步、超时与重试。读者通常关心的是：这次交互里谁发起、谁响应、何时回调、失败怎么兜底。

如果你只记住一个选择原则：

• 你要解释“业务怎么走” → 先用流程图
• 你要解释“系统怎么互相说话” → 用时序图

很多团队争论“用哪种图”，其实是表达目标没对齐。下面按最常见的工作场景，把它拆开讲透。

想先把“文字步骤”快速变成一张可评审的流程图，可以用这个工具把结构先立起来（后面再补异常分支也更省事）：

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

快速选择清单（30 秒版）

把下面问题按顺序问一遍，通常就能当场决定用哪张图（或两张都用）。

1）你的核心信息是“规则”还是“交互”？

• 核心是业务规则/步骤：比如审批、退款、对账、注册、下单、发货 → 流程图
• 核心是系统交互/调用链：比如前端-网关-服务-DB-三方支付的请求与回调 → 时序图

2）读者是谁？

• 产品、运营、测试、交付、老板：更容易读懂流程图（更贴近“事情怎么做”）
• 开发、架构、SRE、联调同学：更需要时序图（更贴近“系统怎么跑”）

3）你要解决的痛点是哪一种？

• 评审时总被问“有没有异常分支？”“失败后怎么处理？” → 用流程图把分支与终止条件补齐
• 联调时总被问“到底谁调用谁？”“回调在哪个接口？”“超时重试几次？” → 用时序图把消息顺序与边界画清

4）你希望读者看完能做什么？

• 能写测试用例、做流程验收、对齐业务口径 → 流程图更直接
• 能拆接口、定超时、定幂等、定位链路问题 → 时序图更直接

结论往往是：流程图负责“范围与规则”，时序图负责“关键交互的细节”。

两种图的“坐标系”：它们在表达什么维度

很多“用错图”的根源，是没意识到两种图的主轴不同。

流程图：控制流（Control Flow）是主轴

流程图默认回答这些问题：

• 下一步做什么？
• 什么时候分支？分支条件是什么？（是/否、成功/失败、库存是否充足等）
• 什么时候结束？（完成/取消/超时/人工介入）
• 哪些步骤可以合并，哪些必须串行？（即使你不画并行符号，也在讲“先后”）

如果你把流程图画得好，读者会自然形成“业务状态机”的感觉：每一步能否进入、进入后能否退出、退出到哪里。

时序图：消息流（Message Flow）是主轴

时序图默认回答这些问题：

• 参与者有哪些？（用户/前端/网关/订单服务/支付服务/三方/消息队列…）
• 谁在什么时候发起调用？
• 调用是同步还是异步？
• 返回值/回调在哪里发生？
• 超时、重试、幂等、补偿是怎么落在接口上的？

时序图强调“时间”，所以它天然适合描述：

• 一次请求链路
• 跨服务协作
• 事件驱动/消息队列
• 回调、轮询、Webhook

常见误用与反例：你可能正在浪费所有人的时间

画错图的后果不是“文档不好看”，而是评审和联调都变慢：每个人都要在图里“猜”你想表达什么。

误用 1：用流程图画“谁调用谁”

你可能见过这种流程图：每个节点写着“前端调用 A 接口 → 网关转发 → 订单服务调用支付服务 → …”。

问题在于：

• 流程图的节点会越来越长，最后全是接口名
• 分支一多，线就交叉，读者看不出“时间顺序”是否真实
• 最致命的是：你表达的是调用链，但流程图的语法更适合表达业务步骤

如果你的争论点是“回调先到还是落库先做？”——这本来就是时序图的战场。

误用 2：用时序图塞进所有业务规则

另一种极端是：把每一个业务判断都写成 alt / opt，层层嵌套到读不下去。

问题在于：

• 规则越多，时序图越像“代码截图”，但又没有代码那么精确
• 测试同学要找“有哪些分支”，在时序图里非常痛苦
• 产品要看“流程口径”，会被参与者和调用细节淹没

当你想表达“规则齐全”，流程图（或状态图）更有效。

误用 3：两种图都画，但内容重复

很多文档里流程图和时序图画了两张，但几乎是同一件事的两种视图，读者会问：那我到底该信哪张？

更好的策略是：

• 流程图：覆盖面要全（包含异常/兜底/人工介入）
• 时序图：只挑关键链路（最复杂、最容易出故障、最难联调的那段）

什么时候一定要用流程图（而不是“随便画个时序图”）

下面这些场景，流程图通常是“最短路径”。

1）需要对齐业务口径与责任边界

例如：审批、退款、对账、发票、售后、风控、客服介入。

流程图适合把关键口径钉死：

• 触发条件是什么
• 哪些状态可逆，哪些不可逆
• 哪些节点需要人工确认
• 超时之后算失败还是继续排队

2）需要完整覆盖异常分支与兜底

流程图天生适合画：

• 成功/失败
• 有库存/无库存
• 支付成功/支付失败/支付超时
• 自动处理/人工处理

尤其在交付时，流程图能直接变成测试用例大纲：每个分支至少要有一条用例。

3）需要把复杂流程“拆层”讲清楚

好的流程图往往不是一张巨图，而是分层：

• 顶层：只画 7~12 个关键步骤，保证一屏能读
• 二层：把某个复杂步骤（比如“支付”或“退款”）展开为子流程
• 三层：再把最复杂的交互用时序图补上

如果你发现你画流程图时不断想写接口名，通常说明你应该在下一层用时序图，而不是在同一张流程图里硬塞。

什么时候一定要用时序图（否则你会在联调时崩溃）

下面这些场景，时序图往往能把“吵架点”一次说清。

1）多参与者协作，且存在回调/异步

典型：支付、短信、邮件、风控、三方登录、物流推送。

时序图能清楚表达：

• 请求是谁发起的
• 回调/Webhook到哪个端点
• 业务落库发生在“收到回调之前还是之后”
• 异步消息到底是“至少一次”还是“恰好一次”（至少要在图上标出幂等点）

2）你需要讨论超时、重试、幂等与补偿

这些问题在流程图里很难讲清“谁重试、重试几次、间隔多久”。

在时序图里，你可以把关键点画出来：

• 哪一段是同步调用，超时阈值是多少
• 失败后谁来重试（调用方？任务队列？定时器？）
• 幂等键在哪里生成（订单号？业务流水号？请求 ID？）
• 何时触发补偿（撤销/冲正/退款）

如果你的系统遇到过“支付回调重复导致重复发货”，你会知道这类信息不在时序图里明确出来，后面一定会还债。

3）需要明确接口契约与数据流向

时序图不只是画箭头。它适合承载这些“能落地”的信息：

• 请求/响应的关键字段（只写影响分支的字段即可）
• 状态码/错误码大类（成功、可重试、不可重试）
• 事件名称（下单成功事件、支付成功事件）
• 落库/事务边界（在生命线旁标注即可）

注意：不要把完整 JSON 贴进图里，那会毁掉可读性；保留“影响行为的字段”就够了。

一组对照：流程图的“判断节点”与时序图的“alt 分支”

两种图都能表达“分支”，但它们表达的重点不同：

• 流程图的判断节点关注：规则本身（条件是什么、满足后走哪条路径）
• 时序图的 alt/opt 关注：交互差异（不同条件下，哪些消息会发生/不会发生）

实践中很常见的一种拆分：

• 在流程图里把“是否需要风控校验”作为判断节点
• 在时序图里只在需要时展开“风控服务的调用与回包”，并标出超时与降级

这样既能让业务读者看懂规则，也能让开发读者在关键链路上对齐实现。

落地写法：一套“流程图 + 时序图”组合的推荐套路

如果你希望文档既能评审、又能联调、还能交付测试，通常不需要纠结“二选一”，而是用组合把信息分层。

第 1 张：主流程流程图（必须）

目标：让任何人 3 分钟内理解“这件事怎么走”。

建议只回答：

• 主流程 7~12 步
• 关键分支 3~6 个（失败/超时/人工介入）
• 关键状态（创建、处理中、成功、失败、取消…）

如果你正在从会议纪要/需求文档里抽步骤，最省时间的方式通常是：先用文本写出节点和连线，再生成一张“能读”的图，然后再回头补边界与分支。

你可以用这个入口把流程图先生成出来，再按评审反馈迭代：

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

第 2 张：关键链路时序图（可选但强烈推荐）

选择“关键链路”的标准：

• 最容易出故障（第三方、网络、超时）
• 最容易扯皮（边界不清、职责不清）
• 最难测（异步回调、重复消息、幂等）

时序图的目标是让开发/测试能落地：

• 接口是谁调用谁
• 顺序是什么
• 失败怎么兜底

第 3 张（可选）：异常/补偿专用图

当异常分支太多时，把异常单独拎出来会更清晰：

• “支付超时如何处理”一张图
• “回调重复/乱序如何处理”一张图
• “对账差异如何处理”一张图

这类图可以是流程图也可以是时序图：看它主要在讲“规则”还是“交互”。

只给一个小例子：同一件事，两种图各画什么

以“下单并支付”为例（这里只给一个小例子，重点是看差异）。

如果你画流程图，你通常会写这些“业务步骤”

• 用户提交订单
• 校验库存与价格
• 创建订单（状态=待支付）
• 发起支付
• 判断：支付是否成功？
  • 是：订单状态=已支付 → 触发发货
  • 否：订单状态=支付失败 → 提示用户重试/取消
• 判断：是否超时未支付？
  • 是：关闭订单 → 释放库存

读者看完会知道：业务的关键口径是什么、有哪些分支、失败怎么收口。

如果你画时序图，你更可能关心这些“交互细节”

• 前端 → 订单服务：创建订单
• 前端 → 支付服务：创建支付单
• 支付服务 → 第三方支付：下单
• 第三方支付 → 支付服务：异步回调（可能重复）
• 支付服务 → 订单服务：更新订单状态（需要幂等）
• 订单服务 → MQ：发货事件

读者看完会知道：回调落在哪、幂等点在哪、消息怎么串起来。

同一个“支付成功/失败”的分支：

• 在流程图里，它是“规则分支”
• 在时序图里，它往往对应“回调是否到达、到达后触发哪些消息”

交付规范：把图从“能看”变成“能用”

很多图之所以在团队里失效，是因为缺少交付规范：画了，但没人敢按它实现或验收。

流程图的 6 条硬规范

1. 节点用动词开头：提交/校验/创建/调用/更新/通知，比“订单/支付”这种名词更清楚
2. 每个判断写清条件：不要只写“是否成功”，要写“支付回调验签通过且金额一致？”这种可验证条件
3. 把终止态画出来：成功结束、失败结束、取消结束、人工结束
4. 避免交叉线：交叉线通常意味着你少了“子流程/拆层”
5. 异常路径要有收口：失败后去哪？重试？补偿？人工？别让线条悬空
6. 标注边界（可选但很有用）：用泳道/分组把“用户侧/系统侧/人工侧”分开，读者更容易理解责任

时序图的 6 条硬规范

1. 参与者命名统一：网关/订单服务/支付服务/三方支付，不要一会儿写 A 一会儿写 B
2. 区分同步与异步：至少在文字或箭头样式上区分（同步请求 vs 事件/回调）
3. 标出幂等点：回调、消息消费、状态更新处要注明“幂等键/去重依据”
4. 标出超时与重试归属：是调用方重试，还是后台任务补偿？别只写“失败重试”
5. 把错误分成三类：可重试、不可重试、需要人工介入（对应不同处理策略）
6. 别把图当接口文档：只写关键字段与关键返回，不要塞完整 payload

FAQ：团队里最常吵的 8 个问题

1）我能不能只画一种图？

能，但要看你的目标。

• 只为了让业务对齐、让测试覆盖分支：只画流程图也行
• 只为了开发联调、排查链路：只画时序图也行

但一旦涉及“既要评审，又要联调”，两种图组合通常是更省时间的做法：你减少的是会议里的解释成本。

2）流程图一定要用 UML / BPMN 吗？

不一定。

• 你在做企业流程治理、需要严格符号与合规：BPMN 更合适
• 你在做系统分析、希望表达行为与状态：UML Activity/State 更合适
• 你在做团队沟通、追求快速对齐：简化流程图也可以

关键不是“用哪个标准”，而是规则是否可验证、边界是否清晰。

3）时序图里要不要画数据库/缓存？

看它是否影响决策。

• 如果 DB 只是实现细节、不会改变交互顺序：可以不画
• 如果 DB/缓存决定了幂等、事务、读写一致性：建议画出来（至少标注落库点）

4）一张图画到多大算过度？

经验阈值：

• 流程图：超过一屏仍需要读者频繁缩放/拖拽，基本就该拆层
• 时序图：参与者超过 8~10 个，通常就该拆成“主链路 + 关键子链路”

5）流程图里的“并行”要不要画？

如果并行会影响结果（例如“两个任务都完成才算成功”），建议画；否则不画也没问题。

不画并行并不等于系统不并行——只是你文档的重点不在那。

6）怎么用图帮助测试更快落地？

• 用流程图把分支枚举出来，测试直接按分支写用例
• 用时序图把接口与回调钉死，测试才能构造正确的 mock/回放

很多“测不动”的系统，本质是：流程图缺异常、时序图缺幂等/重试归属。

7）我已经有流程图了，什么时候必须补时序图？

当出现以下任一情况：

• 有三方回调/消息队列
• 有“同一件事可能被触发多次”的风险（重复回调、重复消息、重复点击）
• 你需要讨论超时、重试、补偿、幂等

这几类问题靠流程图很难讲清具体责任。

8）有没有更快的画法？

最快的画法通常是：

• 先把“业务步骤”用文本列出来 → 生成流程图 → 评审时迭代
• 再挑最复杂的一段 → 画时序图把交互与边界钉死

如果你想把第一步（从文本到流程图）省下来，可以直接用在线生成入口把结构先立起来：

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

最后的判断：你是在“对齐口径”，还是在“对齐实现”？

• 对齐口径（规则、状态、分支、兜底）→ 流程图更强
• 对齐实现（参与者、接口、回调、超时、重试、幂等）→ 时序图更强

真正高效的文档不是“图画得多”，而是每张图只负责一种信息。把流程图当成“业务地图”，把时序图当成“系统通话记录”，你会发现评审更快、联调更少扯皮、测试也更容易覆盖。

如果你手里已经有一段文字流程，建议先把流程图快速生成出来再迭代（避免在 PPT 里反复拖框）：

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