技术解读

以下内容由 GitRead 中文社区 编辑团队基于项目 README 与官方资料整理, 结合中文开发者的常见使用场景补充技术选型建议。具体以项目官方文档为准。

项目背景与痛点

Mermaid 已经把“用文本画图”做成了事实标准——GitHub、GitLab、Notion、Obsidian 都原生支持。但它的实现始终附着在浏览器上:解析、布局、渲染全在 JS 里跑,文本宽度靠 getBBox() 测量,布局交给 dagre,最后生成一棵 DOM 树。

一旦要把它搬到服务端,麻烦就来了。在 CI 里批量生成文档图表、给 Markdown 渲染管线加图片、或者在编辑器里做预览,你就得请出 Puppeteer/Playwright,启动一个 Chromium,占用几十上百 MB 内存,冷启动几百毫秒。mermaid-cli 和 Kroki 本质上走的都是这条路:为了渲染一张流程图,先启动一整个浏览器。

merman 的定位一句话说清:把 Mermaid 的解析与渲染从浏览器里剥离出来,用 Rust 重写,headless 运行。没有 DOM,没有 V8,没有 Chromium。对后端和工具链而言,这是把“系统级重依赖”换成“库级轻依赖”。

核心技术揭秘

Mermaid 的语法并不是单一 grammar,而是十几个:流程图、时序图、类图、状态图、ER、甘特、饼图……每种都有自己的词法规则、AST 和历史遗留的容错行为。因此第一层必然是类型分派:先识别图类型,再进入对应的 parser。这也是为什么这类重写项目通常不用纯 parser generator——Mermaid 的语法存在大量上下文相关和“能跑就行”的宽松解析,手写递归下降更现实。

解析结果需要统一收敛到同一个图模型:节点、边、子图、标签、样式类。这个图模型是后续所有工作的基础,也决定了与 Mermaid 生态的兼容上限。

真正的难点有两个。

其一是布局。 Mermaid 默认走 dagre 的 Sugiyama 分层布局:去环、分层、层内排序(重心法)、坐标分配(Brandes-Köpf)。Rust 侧要么移植要么重写,涉及大量几何计算和迭代优化,是渲染质量和性能的关键分界。布局的实现质量决定了“看起来像不像 Mermaid”。

其二是文本度量。 浏览器里 getBBox() 一行搞定;headless 环境没有排版引擎,节点尺寸、文本换行、标签避让全得自己算。需要借助字体表(fontdue、ab_glyph 之类)测量 advance width,还要处理中英文混排、字号继承、字体回退。这也是为什么这类项目往往对字体配置高度敏感——字体没装对,中文直接变成豆腐块或宽度失真。

graph TD A[Mermaid 文本] --> B[图类型识别] B --> C[对应的词法与语法分析] C --> D[统一图模型] D --> E[分层布局引擎] E --> F[文本度量与字体回退] F --> G[SVG 序列化] D --> H[主题与样式解析] H --> G G --> I[输出 SVG / PNG]

最后是 SVG 序列化:把布局结果翻译成 path / text / rect,主题在这里注入。整条链路纯 CPU 计算,没有跨进程通信,没有浏览器往返。

功能亮点与差异

对比 mermaid-cli,merman 的优势在于三个“不需要”:

  • 不需要浏览器:适合容器极简的 CI、Serverless、边缘环境;
  • 不需要序列化边界:作为 Rust crate 直接嵌进现有管线,或者编译成 CLI / WASM;
  • 输出确定性:纯函数式渲染意味着同一输入产出同一份字节,天然适合 git diff 和快照测试——这一点在文档工程里价值极高。

它更像“重新实现一个 Mermaid”,而不是“调用 Mermaid”。代价也很直接:兼容面需要一项项追平,Mermaid 那些非标准的边缘语法、社区自定义主题、themeCSS 这类注入能力,都是长期的兼容性债务。

应用场景与落地建议

适合的场景很明确:文档站构建、Markdown 服务端渲染、代码评审机器人、WASM 在线编辑器即时预览。这几个场景的共同点是图不复杂、量大、要求快且可复现。

生产落地有三条建议:

  1. 先做覆盖度验证,把你业务里真实出现的图类型和语法变体抽样跑一遍,别一上来就全量替换;
  2. 锁死字体环境,镜像里预装字体,明确 font-family,否则中文字宽计算会漂移;
  3. 双轨并行,CI 里用 merman 快速出图,人工审阅或最终发布时用 mermaid-cli 兜底,逐步收窄差异。

综合评价

优点:定位精准,填补了“无浏览器 Mermaid”这个真实空白;Rust 带来的性能与可嵌入性是结构性优势,确定性输出对文档工具链是加分项。

缺点:生态兼容是长期工程,短期内难以覆盖 Mermaid 的全部语法与主题能力;文本度量这类细节一旦出问题,表现是“图能画但很丑”,排查成本不低;项目成熟度需要时间验证。

一句话总结:它不是 Mermaid 的替代品,而是 Mermaid 在服务端的一次“去浏览器化”重构。如果你的痛点就是 CI 里的那几十秒和几百 MB,它值得一试;如果你需要的是百分之百的渲染保真,目前还得留着 mermaid-cli 做后备。

关于

GitHub 原始描述(英文)

Mermaid.js, but headless, in Rust.

描述取自 GitHub 官方 API,保持仓库作者书写的原文。

简要分析

热度分
750
价值分
408
活跃状态
活跃

语言占比

C
C++
CMake
CSS
Dart
Dockerfile
Elvish
Gnuplot
Go
HTML
JavaScript
Kotlin
Makefile
Mermaid
Nix
PowerShell
Python
RenderScript
Roff
Rust
Shell
Swift
Tree-sitter Query
TypeScript
Typst