Ttext2mermaid

AI 时序图生成器

把 API 描述转成含参与方和箭头的时序图。

打开生成器 →

试一下这些示例 —— 点击后自动进生成器

OAuth 2.0 授权码流
OAuth 2.0 授权码流:用户在客户端应用点击登录,重定向到授权服务器,登录并同意授权,授权服务器通过重定向返回 code 给客户端,客户端用 code + client_secret 换取 access_token,再用 token 调用资源服务器 API。
Stripe 结账 + Webhook
Stripe 结账流程:前端通过后端创建 payment intent,后端调 Stripe API,Stripe 返回 client_secret,前端在 Stripe 侧确认支付,Stripe 通过 webhook 通知后端支付成功,后端履约订单并通过 WebSocket 推送给前端。
分布式事务(Saga 模式)
Saga 模式:订单服务创建订单(pending),发布事件,支付服务扣款并发布结果事件,成功则库存服务锁库存,失败则支付服务补偿退款。订单服务监听所有事件最终确定状态。
WebSocket 聊天消息投递
WebSocket 聊天消息:客户端 A 通过 WebSocket 发消息到服务器,服务器持久化到数据库,通过 B 的 WebSocket 推送给接收方 B,B 发送已读回执,服务器更新消息状态并通知 A。

什么时候用它

时序图是描述**多方之间的顺序和时机**最锋利的工具。任何时候你需要展示"谁调用了谁,先后顺序,返回了什么"—— 时序图都是首选。典型场景:API 集成、认证握手(OAuth、SAML、JWT 刷新)、分布式系统间消息流、含锁的数据库事务、WebSocket / SSE 推送模式。 它是工程文档的标准工具,因为它**强迫你显式命名每个参与方** —— 不能含糊地写"后端做点什么",每个箭头都必须有明确的来源、目标和消息内容。这让它特别适合架构评审和 RFC 文档:审阅者可以逐个箭头挑毛病。 一条经验法则:如果你的口头解释里"然后…然后…然后…"出现超过 3 次,你要的是时序图,不是流程图。时序图擅长表达异步消息、参与方的"忙碌区间"(activation bar)、标注单条箭头背后的原因(notes)。它不适合什么?**完全并行、没有明确先后**的交互 —— 那种用组件图(component diagram)更合适。

相关工具

AI 流程图生成器
用一句话描述一个流程,得到一张图,导出 SVG / PNG。
AI UML 类图生成器
描述类、属性、继承,得到一张 Mermaid UML 类图。