接口增加一个确认步骤，旧PPT里的时序图却找不到可编辑版本。手工拉箭头既慢，也难看清两次修改差在哪里。PlantUML用文本描述图形，适合把设计与代码一起留档，后来的人可以继续修改。
先写三个参与者，不急着画整套架构
打开XunL PlantUML在线编辑器，在代码区输入以@startuml开始、@enduml结束的描述。一个询价场景可以先写“买家向网站提交资料，网站保存询价，网站向买家返回结果”，再用参与者和箭头表达对应消息。
例如 买家 -> 网站 : 提交询价 与 网站 -> 数据库 : 保存记录 是两条不同消息。名称应贴近团队实际称呼，消息用动词说明动作，不要把按钮点击、保存成功和通知发出写成同一件事。
成功与失败，要在图里有明确含义
基本流程渲染出来以后，再讨论校验失败、保存失败和重复提交。若页面返回成功发生在数据保存以前，图中就要如实表达，不能因为业务希望成功而把时序顺序画成理想状态。
图形可以用于需求讨论，也可以记录现状，两种用途应在标题或说明中区分。现状图需要负责人确认，设计图则需要后续实现与验收。图中有一条消息，不证明实际系统已经发出了它。
每次只增加一个分支或参与者，预览确认后再继续，比一次粘贴一大段复杂描述更容易定位语法错误。参与者过多时可以拆成总览与专项图，不必让所有系统挤在一张图里。
预览方式与资料范围需要提前知道
本工具将图代码提交到本站服务器进行沙箱渲染，不是完全本地绘图。输入前应去除客户资料、访问密钥和不适合该处理方式的内容。页面说明不保存渲染代码，但这不能替代组织自己的资料使用规则。
沙箱不允许任意引用本地文件或网络地址，不能把桌面上的文件路径直接写进include期待它能读取。标准库与支持范围按页面说明核对；需要外部依赖时，应采用有相应权限与配置的本地工作流。
图和源码一起交付，才方便持续维护
确认内容后导出SVG或PNG。SVG适合继续放进文档与演示材料，PNG方便普通预览；实际插入Word、PPT后仍要检查中文、裁切和字号。不要只在编辑器缩放视图中验收。
源代码应与图同时保留，并写清版本、用途和负责人。分享链接可能把代码放进链接本身，所以获得链接的人可能看到内容，不能把它当作带访问审批的私密空间。
后续变更时先改源描述再重新导出，不要只在图片上贴一段文字。这样消息、参与者和说明始终来自同一来源，审查也可以通过文本差异理解修改。
PlantUML可以替代拖拽工具吗？
它更适合关系明确、经常改动且需要版本管理的图。自由插画或高度定制视觉可能仍适合其他工具，选择应围绕维护需求。
预览成功就代表流程设计正确吗？
只证明代码能够渲染。顺序、责任和异常处理仍要与真实业务或设计目标核对，特别是涉及数据保存和成功反馈的节点。
个人微信：ssevening
