什么是顺序图？
一个顺序图是一种行为UML 图详细描述了软件操作随时间进行的方式。作为统一建模语言（UML）规范的核心标准，它精确地建模了对象、进程或微服务之间交换消息的时序顺序。通过将生命线垂直排列，将顺序交互水平排列，这种特定的UML 图类型使软件工程师和系统架构师能够在编写生产代码之前，清晰地可视化复杂的 API 调用序列、网络数据握手以及数据库事务边界。
使用VPasCode您无需花费数小时来对齐平行箭头、拉伸消息线或移动边界框以腾出新步骤的空间。我们的布局引擎会随着您输入纯文本声明式脚本，动态计算整个时间轴网格。
核心语法指南：元素与构造
要在 PlantUML 中设计出可执行且符合标准的 UML 顺序图，您需要掌握组件声明、消息箭头样式、生命线以及逻辑控制结构。
1. 声明 UML 参与者和形状
默认情况下，此 UML 图中的组件继承标准的方形框形状。然而，您可以使用特定的 UML 关键字更改实体的视觉原型，从而为读者提供关于系统边界的即时架构上下文。
actor 客户端
boundary "API 网关" as 网关
control 控制器
database "PostgreSQL" as DB
2. 消息箭头与同步性
箭头线和箭头头的样式根据 UML 图标准，确立了在您的基础设施管道中发生的精确通信协议：
- 同步请求（阻塞）：由实线和实心箭头头表示。发送方等待响应：
A -> B - 异步消息（非阻塞）：由实线和空心细箭头头表示。发送方传递数据并立即继续：
A ->> B - 响应 / 返回值：由虚线和空心箭头头表示：
B --> A
3. 管理生命线（激活和停用）
为了避免你的组件看起来像扁平的条形，你应该明确展示进程正在积极消耗CPU线程或内存容量的时刻。使用activate 和 deactivate 标记，或者使用简写内联递增语法（++ / --):
Gateway -> Controller ++ : "processPayment()"
Controller --> Gateway -- : "返回收据"
4. 逻辑块：选择、循环和并行
复杂的业务逻辑（例如if/else分支、数据库重试或并行执行线程）必须包裹在UML图规范中称为组合片段的结构化全局框架边界内：
- 条件逻辑（alt / else）： 模型条件分支。
Plantuml Edit Plantuml in VPasCode
alt 成功条件 A -> B : "继续请求" else 失败状态 A -> B : "抛出错误代码" end
- 重复循环（loop）： 模型迭代、重试或队列处理块，直到满足条件为止。
Plantuml Edit Plantuml in VPasCode
loop 直到队列为空 Worker -> Queue : "获取下一个任务" end
- 并行执行（par）： 模型将独立线程上同时执行的操作分离开来。
Plantuml Edit Plantuml in VPasCode
par 并行运行进程 A -> 日志服务 : "写入追踪分析" else A -> 数据库 : "提交客户资料数据" end
清晰序列的最佳实践
- 使用分隔符对消息进行分组： 使用双等号 (“
== 您的阶段 ==) 将庞大的从认证到结账的流程分解为不同的逻辑里程碑。 - 使用自动编号： 将
autonumber指令直接放在@startuml。这会强制工作区在每个箭头上标记步骤编号，使代码审查变得容易得多。 - 保持响应简洁： 避免在返回箭头（
-->）上写大段描述性语句。相反，只需标注返回的原始数据对象或HTTP状态码（例如，"201 已创建令牌").
现实世界中的PlantUML序列图示例
示例1：微服务认证循环（Alt块与生命线）
此模板处理一个标准的安全流程，客户端向网关进行认证，展示了显式的生命周期线以及在标准UML图格式内的替代条件结果框架。
@startuml
autonumber
参与者 用户
边界 "Web应用" as App
控制 "认证服务" as Auth
用户 -> App ++ : "提交凭据"
App -> Auth ++ : "POST /v1/auth"
alt #LightGreen 登录成功
Auth --> App : "200 OK (JWT令牌)"
App --> 用户 : "渲染仪表板"
else #LightPink 凭据无效
Auth --> App : "401 未授权"
App --> 用户 : "显示错误提示"
end
deactivate Auth
deactivate App
@enduml
语法分解： 该 自动编号 标签自动管理1到5的编号。该 替代 和 否则 块会附加自定义的十六进制颜色标志（例如，#LightGreen）以立即在成功与失败的执行路径之间添加视觉突出显示。该 ++ 标记确保在网络调用块期间生命线保持活跃。
示例2：高级订单处理（循环、并行和分隔符）
此企业架构蓝图模拟了一个强大的结账系统，该系统将任务分配给并行工作线程，执行数据库写入，并依赖外部系统同步循环。
@startuml
autonumber
boundary "结账API" as API
database "订单数据库" as DB
control "工作队列" as Queue
boundary "Stripe" as Stripe
== 阶段1：交易账本验证 ==
API -> DB ++ : "写入待处理订单"
DB --> API -- : "订单ID已确认"
== 阶段2：支付与异步履行 ==
API -> Stripe ++ : "扣款客户账户"
Stripe --> API -- : "支付已授权"
par 并行后台操作
API -> Queue ++ : "发布 'Order_Placed' 事件"
deactivate Queue
else
API -> DB ++ : "更新状态为 '已支付'"
deactivate DB
end
loop 网络故障时最多重试3次
API -> API : "Ping通知同步Webhook"
end
API --> Client : "返回HTTP 200（成功）"
@enduml
语法分解： 该 == 分隔符将布局划分为不同的操作阶段。该 par 块将消息箭头路径清晰地分叉为两条独立的水平路径，说明事件发布和数据库状态更新同时发生且互不阻塞。自指向箭头（API -> API）完美地映射了本地内部实例函数循环。