Mermaid 流程图是节点和连线的文本模型。第一行决定图表类型和方向。flowchart TD 表示从上到下；flowchart LR 表示从左到右。方向应该根据叙事方式选择，而不是根据屏幕宽度随意决定。
把节点身份和显示文本分开
用简短、稳定的 ID，把人能读懂的文字放在方括号里：
flowchart LR
request[收到请求] --> validate{输入有效吗?}
validate -->|是| process[处理订单]
validate -->|否| reject[返回校验错误]validate 是边连接使用的 ID；输入有效吗? 是显示标签。标签以后可以改，而不会把所有连线一起重写。稳定的 ID 也更方便后续样式调整和 diff 审阅。
给分支添加标签
如果一个菱形节点没有分支标签，读者就要自己猜哪条线是 yes，哪条线是 no。使用 -->|标签| 给外向边添加简短标签，并保持整张图里的术语一致。不要在同一张图里混用 true/false、yes/no 和 success/failure。
使用子图表示边界
子图可以用来表示责任边界或运行时边界：
flowchart LR
subgraph Browser
edit[编辑源码] --> render[渲染图表]
end
subgraph LocalStorage
draft[(草稿)]
end
edit --> draft不要把每两个节点都包成一个子图。只有当边界能传达职责、信任、部署或生命周期时，它才有价值。
避免常见解析陷阱
Mermaid 的语法会演进，但有几类错误很容易定位。先从最小图开始，再一次加一条语句。遇到包含标点的标签时，必要时给标签加引号。流程图里小写的 end 具有特殊含义，因此要么首字母大写，要么换个节点文本。另外要注意某些边的特殊尾部字符，因为 o 和 x 在某些位置会被当作特殊边形。
为变化而设计
图太大往往在“变得难维护”之前就已经难以阅读。最好把系统总览和细节流程拆开，尽量减少交叉线，并保持抽象层级一致。一个叫“系统”的节点和一堆具体函数节点放在一起，通常说明模型混用了不同层级。
可以在 本地 Mermaid 编辑器 中测试并导出源码。编辑器使用的是站点内置的 Mermaid 版本，所以只要能渲染，就说明在这个运行时里确实可用。