Mermaid是一种基于文本描述生成图表的轻量级语法,适合用于流程图、时序图、类图、状态图、甘特图等可视化场景。相比传统的绘图工具,Mermaid最大的优势在于图形结构可以直接通过代码维护,修改节点、调整流程或补充业务逻辑时,不需要重新拖拽图形。
对于技术文档、项目方案、产品设计以及数据处理说明而言,Mermaid流程图尤其适合表达“数据从哪里来、经过哪些处理、最终产生什么结果”。结合条件判断、子流程、样式定义以及交互能力,还可以进一步制作具有个性化效果的流程图。
Mermaid流程图的基本结构
Mermaid流程图通常使用 flowchart 声明图表类型,并通过节点和连接线描述流程。
最简单的示例:
其中:
-
flowchart表示绘制流程图; -
TD表示从上到下排列; -
A、B、C、D是节点标识; -
[]用于定义节点显示文本; -
-->表示带箭头的流程连接线。
Mermaid还支持不同方向,例如:
LR 表示从左向右排列。
常见方向包括:
| 方向 | 含义 |
|---|---|
| TD | Top Down,从上到下 |
| TB | Top Bottom,从上到下 |
| BT | Bottom Top,从下到上 |
| LR | Left Right,从左到右 |
| RL | Right Left,从右到左 |
对于数据处理流程,LR 通常更适合展示“输入→处理→输出”的链路;对于业务审批流程,TD 往往更加直观。
从数据开始设计Mermaid流程图
一个真正有价值的流程图,并不是简单把几个步骤连接起来,而是要先梳理数据流向。
例如,一个典型的数据分析流程可以拆成:
原始数据 ↓ 数据采集 ↓ 数据清洗 ↓ 数据转换 ↓ 数据分析 ↓ 结果存储 ↓ 可视化展示
对应的Mermaid代码可以写成:
这种写法最大的价值在于流程结构非常清晰。当业务发生变化时,例如增加“数据校验”环节,只需要修改代码:
相比重新绘制图片,修改文本代码更加方便,也更适合纳入Git等版本控制系统。
使用判断节点表达业务逻辑
流程图最常见的场景之一就是条件判断。Mermaid可以使用 {} 创建菱形判断节点。
例如用户登录流程:
这里的:
C{账号密码是否正确}
会显示为判断节点,而:
C -->|是| D C -->|否| E
则分别表示不同的业务分支。
这种方式特别适合描述:
-
用户登录;
-
支付流程;
-
审批流程;
-
数据校验;
-
异常处理;
-
自动化任务;
-
API请求流程。
如果一个流程存在多个判断条件,可以继续扩展:
这样可以把复杂的业务规则压缩成结构清晰的视觉路径。
用子流程组织复杂数据处理
当流程图越来越复杂时,所有节点放在同一层级很容易造成视觉混乱。Mermaid提供了 subgraph,可以把相关节点划分为不同区域。
例如:
这种设计适合大型数据流程。
例如一个数据平台可能包含:
数据采集 ├── API接口 ├── 数据库 └── 文件上传 数据处理 ├── 清洗 ├── 去重 └── 转换 数据分析 ├── 指标计算 ├── 聚合 └── 异常检测 结果应用 ├── 报表 ├── Dashboard └── API
通过Mermaid的子图结构,可以把这些模块直接映射到流程图中,使技术人员更容易理解系统架构。
让流程图具备个性化样式
默认样式可以满足基础需求,但面对正式技术文档时,通常需要根据不同节点的作用进行视觉区分。
Mermaid可以通过 classDef 定义样式。
例如:
通过这种方式,可以让数据源、处理节点、判断节点和异常节点拥有不同的视觉表现。
如果流程图用于团队技术规范,还可以建立统一的颜色规则。例如:
-
蓝色表示数据输入;
-
绿色表示正常处理;
-
橙色表示条件判断;
-
红色表示异常或风险;
-
灰色表示辅助流程。
这样形成统一的视觉语言后,读者无需逐个阅读文字,也能快速理解流程结构。
使用链接实现流程图交互
Mermaid不仅能够生成静态结构,还可以根据具体渲染环境实现一定程度的交互。
例如:
在支持相关交互配置的Mermaid渲染环境中,点击节点可以跳转到指定页面。
这种方式特别适合技术文档。
例如:
系统架构图 ↓ 点击“数据采集” ↓ 进入数据采集模块说明 ↓ 查看接口定义 ↓ 查看代码示例
这样,流程图就不再只是展示结构的图片,而可以成为文档导航入口。
不过需要注意,是否允许 click 交互以及具体表现形式,与Mermaid版本和宿主平台的安全配置有关。部分Markdown平台可能禁用相关功能,因此实际使用前需要确认渲染环境。
通过数据驱动流程图内容
Mermaid最大的特点之一是“文本即图形”。这意味着流程图可以与数据、配置文件或者程序逻辑结合。
例如,可以先准备流程数据:
JavaScriptconst steps = [ { id: "A", name: "数据采集" }, { id: "B", name: "数据清洗" }, { id: "C", name: "数据分析" }, { id: "D", name: "结果展示" } ];
再由程序生成Mermaid语句:
JavaScriptconst diagram = ` flowchart LR A[数据采集] --> B[数据清洗] B --> C[数据分析] C --> D[结果展示] `;
如果流程节点来自数据库,则可以进一步动态生成。
例如数据库中保存:
| ID | 名称 | 下一节点 |
|---|---|---|
| A | 数据采集 | B |
| B | 数据清洗 | C |
| C | 数据分析 | D |
| D | 数据展示 | - |
程序可以读取这些数据,然后自动拼接:
A[数据采集] --> B[数据清洗] B[数据清洗] --> C[数据分析] C[数据分析] --> D[数据展示]
这种设计适合工作流系统、审批平台、任务编排系统以及数据管道可视化。
动态生成Mermaid流程图的思路
如果需要让用户自己创建流程,可以将流程编辑器与Mermaid结合。
基本架构可以设计为:
用户操作 ↓ 流程节点数据 ↓ JSON模型 ↓ Mermaid代码生成器 ↓ Mermaid渲染 ↓ 交互式流程图
例如前端保存:
JavaScriptconst workflow = { nodes: [ { id: "A", text: "开始" }, { id: "B", text: "数据处理" }, { id: "C", text: "结束" } ], edges: [ { from: "A", to: "B" }, { from: "B", to: "C" } ] };
生成Mermaid代码:
JavaScriptfunction createMermaid(workflow) { const lines = ["flowchart LR"]; workflow.nodes.forEach(node => { lines.push(` ${node.id}[${node.text}]`); }); workflow.edges.forEach(edge => { lines.push(` ${edge.from} --> ${edge.to}`); }); return lines.join(" "); }
最终生成:
这种方式的关键并不是直接修改Mermaid字符串,而是先维护结构化数据,再将数据转换成Mermaid语法。
对于大型应用来说,这种架构更容易维护。
个性化互动不等于简单点击
如果希望实现真正的个性化互动,可以从三个方向扩展。
第一种是节点点击。
用户点击“数据分析”节点后,右侧展示对应的指标说明、接口地址和执行记录。
第二种是状态变化。
例如工作流正在运行时,可以通过不同样式区分:
已完成 → 绿色 处理中 → 蓝色 等待中 → 灰色 失败 → 红色
第三种是根据用户身份展示不同流程。
例如普通用户看到:
提交申请 → 审核 → 查看结果
管理员则看到:
申请提交 → 初审 → 复审 → 权限分配 → 日志记录
这样,Mermaid流程图就可以成为业务系统中的可视化组件,而不是单纯存在于技术文档里的静态图。
流程图中的数据状态可视化
对于数据管道而言,仅仅展示节点名称通常是不够的。
可以把处理状态直接体现在节点中:
也可以根据状态定义不同样式:
对于实时数据平台,还可以让后端根据任务状态动态生成Mermaid源码,从而让流程图反映当前系统状态。
Mermaid流程图常见问题
节点ID为什么不能随意重复
Mermaid中的节点ID用于识别节点。
例如:
如果多个业务节点都使用同一个ID,可能导致节点被合并或者关系出现异常。
因此动态生成流程图时,应确保节点ID唯一。
中文节点是否可以直接使用
通常可以直接使用中文:
不过节点ID最好使用简单的英文、数字组合,把中文放在节点显示文本中。
为什么代码正确但网页不显示
这类问题通常与渲染环境有关。
常见原因包括:
-
Markdown平台没有启用Mermaid;
-
Mermaid版本与语法不兼容;
-
某些安全策略限制脚本或链接交互;
-
HTML标签或特殊字符处理存在差异;
-
动态渲染时没有正确初始化Mermaid。
如果使用JavaScript动态渲染,需要确认Mermaid已经完成初始化,并且目标容器中的源码符合当前版本的语法要求。
Mermaid与传统流程图工具的区别
Mermaid更适合“结构化、可维护、可版本控制”的流程图场景。
传统绘图工具通常通过拖拽方式制作图形,优点是自由度高,适合设计复杂视觉效果;Mermaid则通过代码定义结构,更适合程序员、技术文档和自动化系统。
两者可以按照使用场景进行选择:
| 使用场景 | 更适合的方式 |
|---|---|
| 技术文档 | Mermaid |
| Git项目文档 | Mermaid |
| 数据处理流程 | Mermaid |
| 自动生成流程图 | Mermaid |
| 复杂视觉海报 | 专业绘图工具 |
| 高度自由的UI设计 | 专业绘图工具 |
| 工作流系统动态展示 | Mermaid或专用流程图库 |
如果流程本身经常变化,文本化的Mermaid通常能够显著降低维护成本。
Mermaid流程图的SEO价值
对于技术博客而言,Mermaid还有一个容易被忽略的价值:它能够帮助文章形成更清晰的信息结构。
例如一篇介绍数据处理的文章,如果只使用连续文字描述:
首先获取数据,然后对数据进行清洗,之后进行转换和分析,最后生成结果。
用户需要阅读完整段落才能理解流程。
换成:
信息层次会更加直观。
不过需要注意,搜索引擎对Mermaid图形本身的理解能力和展示方式取决于具体平台。为了兼顾搜索引擎与无障碍访问,重要流程不要只依赖图形表达,可以在图表前后配合自然语言解释。
例如:
数据首先从业务数据库和API接口采集,经过清洗和格式转换后进入分析模块,最终生成报表和统计指标。
这样既方便读者理解,也能够让核心信息以文本形式存在。
编写Mermaid流程图的实用原则
一个好用的流程图并不是节点越多越好。
首先,要控制单张图的复杂度。如果一个图包含几十甚至上百个节点,最好拆成多个子流程。
其次,节点名称应该简洁。推荐:
数据清洗 订单校验 生成报告
而不是:
对从数据库中读取出来的原始订单数据执行完整的数据清洗和格式标准化操作
再次,要保持方向统一。一个流程如果主要从左向右发展,就不要频繁改变方向,否则容易增加阅读成本。
最后,要区分主流程和异常流程。正常业务路径可以保持简洁,错误、重试、回滚等逻辑放到分支中。
一个完整的数据到互动流程示例
综合数据处理、状态判断、模块划分和个性化展示,可以设计如下流程:
这个例子体现了Mermaid流程图的几个重要能力:
-
用箭头描述数据流向;
-
用判断节点表达业务规则;
-
用
subgraph划分处理模块; -
用异常分支描述失败流程;
-
将数据处理与用户交互连接起来。
如果进一步与前端应用结合,可以根据真实数据动态改变节点文本和样式,例如显示当前处理数量、执行状态、错误数量和处理耗时。
最终形成的系统可以理解为:
真实业务数据 ↓ 结构化流程模型 ↓ Mermaid代码 ↓ 流程图渲染 ↓ 状态展示 ↓ 用户交互 ↓ 业务操作
这也是“从数据到个性化互动”的核心思路:Mermaid负责把结构化流程转换成直观的视觉表达,而业务系统负责提供数据、状态和交互逻辑。两者结合后,流程图就不再只是文档中的辅助插图,而可以成为数据分析、工作流管理和技术系统中的可视化入口。