时序图

时序图

时序图用参与者与消息箭头描述调用顺序，适合登录、支付与链路讲解。构图AI 可一句话生成可编辑手绘时序图。

登录可免费体验 1 次；VIP 期内不限制日常画图；导出 PNG / SVG / .excalidraw。

什么时候用

• 接口联调前：前后端、多服务对齐「先调谁、带回什么、失败怎么回」。
• 排查延迟与故障：把超时、重试、回调画出来，定位卡在哪一跳。
• 协议说明：OAuth、支付、WebSocket 握手等需要严格顺序的场景。
• 新人 onboarding：比口头讲「登录大概是这样」更可核对、可评审。

不适合表达组织汇报关系（用组织结构图），也不适合表达数据表结构（用 ER 图）。若只有单系统内部步骤与判断，流程图往往更轻量；时序图的价值在「多方协作的时间顺序」。

核心元素

画时序图时建议固定节奏：先定参与者名单 → 画主成功路径 → 再补失败、超时与回调。消息命名要可执行，例如「校验验证码」「签发 JWT」，避免「处理一下」。

排版规则（时序专用）

1. 参与者从左到右按调用链排序：用户/客户端靠左，基础设施靠右，箭头多为短跳。
2. 生命线间距均匀：过密会导致箭头文字重叠，过疏则画面空洞。
3. 请求与返回成对：同步调用务必画返回，否则联调对不上字段来源。
4. 垂直方向只增不减：时间永远向下；不要为了省空间把晚发生的消息画到上方。

反例：把「浏览器、CDN、网关、鉴权、用户服务、订单服务、库存、支付、短信、日志、监控」十一个参与者全画进一张支付时序——线交叉到无法讲解。应拆成「支付主链路」与「通知/对账」两张，或合并同角色实例。

Prompt 好坏对比

实践建议：先画「主成功路径」再叠加失败与超时；评审时也可分两张图——主路径与异常路径。

常见错误

1. 参与者过多：线交叉、箭头密成一团，读者抓不住主路径。
2. 漏掉返回或回调：只画请求不画响应，联调时对不上字段来源与错误码。
3. 把业务判断全塞进时序：复杂分支应拆图，或在旁注简写条件，避免一张图讲完所有故事。
4. 命名含糊：箭头上写「调用接口」无法落地；应写清动作与关键资源。
5. 用时序代替架构：时序讲「一次调用怎么走」，架构讲「系统长期长什么样」，二者不要互相顶替。

与相邻图类型的区别

若消息经过消息队列，箭头上写清「投递」与「消费」是两次交互，不要画成同步往返；否则研发会误以为调用方在等待结果。

第三方回调类链路要把「验签失败」画出来，否则联调只覆盖快乐路径，上线后对账会对不上。

用构图AI怎么画

选择「时序图」，写清参与者与场景，例如：「画微信支付时序图，含用户、商户、微信支付平台」。生成后核对请求/返回是否成对，标注关键接口名，再导出。可先对照 OAuth、支付示例页的参与者粒度，再改成自己的链路。

构图AI 共 12 种技能，复杂系统可搭配架构图（看全景）与流程图（看业务）使用，形成「结构—流程—交互」三件套。若只是产品对齐步骤，先用流程图往往更省事。

相关：时序图入门 · OAuth 示例 · 支付时序示例 · 登录时序示例 · 使用此技能画图

补充说明

时序图评审建议投影到大屏，按消息逐条念「谁在什么时候请求谁」。念不顺的地方，往往就是实现时会踩坑的地方。

使用构图AI 绘制该图类型时，把评审意见沉淀为下一次生成的约束，比反复从零描述更高效。也可结合站内示例与指南对照学习，再回到 /draw?skill=sequence-diagram 实操。

最后提醒：时序图上的每条消息最好能对应到真实接口名或事件名，哪怕先用临时代号，也比「调用一下」清晰。