Mermaid vs PlantUML 活动图：控制流程默认选 PlantUML

只比较活动图表达，PlantUML 明显更强，应作为正式活动图的默认选择；Mermaid Flowchart 适合简单流程说明。Mermaid 官方将这类语法归为 Flowchart，而 PlantUML 提供专门的活动图控制结构；两者并非同一套 DSL（Mermaid Flowcharts，PlantUML Activity Diagram，均于 2026-07-22 核验）。

本文的范围是动作控制。若要从图表用途整体选择，请看总览中的图表目的与系统边界；若流程的重点转为角色职责，请看泳道图中的角色职责与交接。

核心结论

• PlantUML 的 start、stop、end、kill 与 detach 可直接写出开始、结束和提前终止。
• 分支、循环与 fork/join 在 PlantUML 中有专用控制关键词；Mermaid Flowchart 通过节点与连线表达同类图形关系。
• 简单的顺序和判断流程可用 Mermaid；一旦控制路径需要成为评审对象，默认采用 PlantUML。
• 活动控制与状态迁移不同，涉及对象生命周期时应转到状态图的状态边界。

为什么正式活动图默认选 PlantUML？

PlantUML 的活动图语法把控制路径写进文本：if、repeat、while、fork 等关键词分别对应判断、循环和并行。Mermaid Flowchart 同样能用节点、带标签的边和方向表达流程，但这些关系由图形连接组织，因此正式活动图默认选 PlantUML 更清晰（PlantUML 官方语法，Mermaid Flowchart 官方语法）。

判断标准不是“能不能画出来”，而是读代码时能否立即看出控制意图。下面的订单流程只有开始、判断和两条结束路径，两个工具都能表达；PlantUML 则把开始、判断与停止直接写成活动控制语句。

Mermaid 代码和图

flowchart TD
  Start([Start]) --> Receive[Receive order]
  Receive --> Check{Stock available?}

  Check -- Yes --> Reserve[Reserve items]
  Reserve --> Charge[Charge payment]
  Charge --> Confirm[Confirm order]
  Confirm --> Done((End))

  Check -- No --> Notify[Notify customer]
  Notify --> Done

PlantUML 代码和图

@startuml
start
:Receive order;

if (Stock available?) then (yes)
  :Reserve items;
  :Charge payment;
  :Confirm order;
else (no)
  :Notify customer;
endif

stop
@enduml

start/end 与分支谁更直接？

PlantUML 为活动图提供 start、stop、end，并允许在适用路径使用 kill 或 detach；这些词明确区分正常结束与提前终止。Mermaid Flowchart 则以开始、结束和判断节点配合连线表达流程，适合控制路径很少的说明图（PlantUML 的开始与终止语法，Mermaid 节点与边）。

分支数量不多时，Mermaid 的菱形和 Yes、No 连线已经足以说明去向。分支需要嵌套、需要在某个分支停止，或结束含义需要被审查时，if、else、endif 和终止关键词的文本结构更不容易被连线布局掩盖。

循环、fork/join 与提前终止怎样比较？

PlantUML 以 repeat、while、fork、fork again 和 end fork 或 end merge 明确书写循环、并行与汇合；提前结束可放在对应分支内。Mermaid 能以回边、一对多连线和汇合节点表达同样的图形关系，但没有同类活动图控制关键词（PlantUML 循环与并行语法，Mermaid Flowchart 语法）。

下面的风控流程保留了两种写法。Mermaid 图中，审核、拒绝、两条后续工作和汇合都由节点与边组成；PlantUML 图中，拒绝路径的 stop 与后续的 fork 结构直接标出控制意图。

Mermaid 代码和图

flowchart TD
  Start([Start]) --> Validate[Validate order]
  Validate --> Risk{Risk detected?}

  Risk -- Yes --> Review[Manual review]
  Review --> Approved{Approved?}
  Approved -- No --> Reject[Reject order]
  Reject --> Done((End))
  Approved -- Yes --> ParallelStart[Continue fulfillment]

  Risk -- No --> ParallelStart
  ParallelStart --> Update[Update order status]
  ParallelStart --> Notify[Send notification]
  Update --> Join[Complete workflow]
  Notify --> Join
  Join --> Done

PlantUML 代码和图

@startuml
start
:Validate order;

if (Risk detected?) then (yes)
  :Manual review;
  if (Approved?) then (yes)
  else (no)
    :Reject order;
    stop
  endif
endif

fork
  :Update order status;
fork again
  :Send notification;
end fork

:Complete workflow;
stop
@enduml

当循环、并行和异常终止同时出现时，差别主要在维护：PlantUML 的缩进仍对应控制块，Mermaid 的读者需要沿连线确认回边、分叉与汇合。这是“正式活动图默认 PlantUML”的实际理由，不是说 Mermaid 无法表达流程。

Mermaid Flowchart 何时足够？

当图只需说明顺序、一次判断和回边，Mermaid Flowchart 的节点与连线可以完整传达动作走向。官方文档支持节点、边、方向和 subgraph，因此它适合简单流程说明；只有需要专门活动控制语义时，才应切换到 PlantUML（Mermaid Flowcharts）。

下面的需求处理流程只有一次回边和一个完成路径。它不需要将循环或终止类型写成独立控制语句，所以 Flowchart 是合适的表达。

Mermaid 代码和图

flowchart LR
  Draft[Draft requirement] --> Review{Review passed?}
  Review -- No --> Revise[Revise requirement]
  Revise --> Review
  Review -- Yes --> Implement[Implement change]
  Implement --> Verify[Verify result]
  Verify --> Release[Release]

活动控制的选型边界

选择 Mermaid Flowchart：流程以顺序动作、少量判断和清楚的去向为主，读者无需区分正常结束、提前终止、循环块或并行汇合。

选择 PlantUML Activity Diagram：开始与结束语义、嵌套分支、循环、fork/join 或异常终止本身是设计结论的一部分。涉及角色交接时，不要在本文延伸，请转到泳道图的角色职责和跨泳道交接；涉及组件、服务和外部边界时，请转到软件架构图的系统边界。

常见问题

Mermaid 有专门的 UML 活动图 DSL 吗？

截至 2026-07-22，Mermaid 官方语法分类未列出专门命名为 Activity Diagram 的 DSL，而是通过 Flowchart 的节点、边、方向和 subgraph 表达活动流程；当前官方文档也未提供 PlantUML 那类以 if、repeat、fork 组织的专门活动图控制语法（Mermaid Flowcharts）。

Mermaid 能表示循环和并行吗？

能表示图形关系。回边可以表示循环，一对多连线与汇合节点可以表示并行及汇合；但这些结构由连线组织。需要把循环和 fork/join 作为明确控制结构评审时，PlantUML 的 while、repeat、fork 与 end fork 更直接（PlantUML 官方语法）。

PlantUML 如何表达提前终止？

PlantUML 活动图可用 stop、end 表达结束，并在适用场景使用 kill 或 detach。这让一个分支的提前终止直接出现在文本控制路径中，而不是只依赖连线指向某个结束节点（PlantUML 的终止语法）。

活动图与状态图应该怎样分工？

活动图回答“动作按什么控制路径执行”，状态图回答“对象处于什么状态、因何事件迁移”。若讨论订单、任务或会话的生命周期边界，应使用状态图的状态与迁移；若讨论动作控制，则回到本文的 PlantUML 活动图选择。