先说清楚本横评比什么、不比什么，以及数据是什么时候、从哪里取的。本评测不是亲自压测。所有星标、许可证、主语言、未关闭 issue、建仓时间、最近推送日期，都来自 2026-09-15 当天对各项目官方 GitHub 仓库与官方文档的实核。星标数实时变动，你读到这篇时可能已经变了，所以这里只把它当作体量量级参考，不把它当作结论。
我们对比的维度只有五类可客观核验的东西：架构范式、依赖与运行时、产物形态与可移植性、许可证类型、维护活跃度与问题密度。我们刻意不打画质分。原因很简单：画质是主观的，没有统一的标尺，硬打分只会变成各说各话，对读者没有帮助。本文所有数字都来自上面的实核数据，不编造、不估算、不推测趋势。
需要特别点明：下文会提到 diagram-design 的未关闭 issue 数量明显低于另外几个项目，但那不是质量判决。diagram-design 2026 年 4 月才建仓，而 mermaid 2014 年、excalidraw 2020 年就已经在，体量、年龄、功能面差异巨大，新仓库 issue 少很大程度是还没长大。请务必带着这个限定条件读后面的数字。
一、评测口径与边界声明
这一节是整篇的底座，先把它钉死。我们选这五个项目做对照，不是因为它们是同类竞品，而是因为它们恰好覆盖了 2026 年做图这件事上三条不同的成本落点：把图交给引擎渲染、把图交给一份规范、把图交给一块白板。把它们放在一张表里比，比的是成本落点，不是谁画得更漂亮。
为什么强调非亲自压测。压测需要统一的环境、统一的输入、统一的评判标准，而图这件事实在太依赖使用场景：你给高管看的架构图和给同事看的技术草图，衡量标准完全不同。我们没有，也不打算造一个虚假的统一考场。所以我们只核可客观核验的事实，把判断留给读者自己的场景。
为什么不打画质分。画质没有标尺，配色、圆角、留白、线条质感，每个人都有不同偏好。给一个主观分，只会让厂商拿去当广告，读者得不到可迁移的结论。这篇横评的价值在于把可核验的维度摊开，让你按自己的场景做乘法，而不是替你下一个我们都不敢保证适用所有人的结论。
数据时效也请记牢：2026-09-15。星标、issue、推送日期都会变，本文不承诺它们在你读到的那一刻仍然精确，只承诺它们是我们在这个时间点实核出来的。
二、五个项目硬数据总览
下面是 2026-09-15 实核的硬数据，一张表收口，一句定位放在表后。
| 项目 | 星标 | 许可证 | 主语言 | 未关闭 issue | 建仓于 | 最近推送 |
|---|---|---|---|---|---|---|
| cathrynlavery/diagram-design | 39,807 | MIT | HTML | 44 | 2026-04-16 | 2026-09-10 |
| mermaid-js/mermaid | 90,244 | MIT | TypeScript | 1,785 | 2014-11-01 | 2026-09-14 |
| excalidraw/excalidraw | 131,918 | MIT | TypeScript | 3,471 | 2020-01-02 | 2026-09-14 |
| terrastruct/d2 | 25,416 | MPL-2.0 | Go | 528 | 2022-09-05 | 2026-09-13 |
| plantuml/plantuml | 13,313 | LGPL-3.0 | Java | 588 | 2010-11-04 | 2026-09-14 |
一句话定位：diagram-design 是 2026 年新出现的自包含产物方案，强调双击就能打开；mermaid 是浏览器里跑的文本引擎，嵌入文档生态最成熟；excalidraw 是手绘白板，协作草图是它的主场；d2 是 Go 写的独立编译器，定位是用文本画架构图；plantuml 是三者里最老的 Java 生态文本引擎，沉淀最久。
把这张表读两遍会有两个反直觉的点。第一，星标最高的 excalidraw 和星标最低的 plantuml 差了将近十倍，但它们分属不同范式，受众本就不同，星标高低不能直接换算成谁更好。第二，diagram-design 建仓最晚、星标却已经过三万，说明自包含产物这条路线在 2026 年确实有真实需求，而不是小众玩具。
三、三类范式：成本分别落在哪
这五个项目可以按范式分成三类，每类的成本落点完全不同。理解这一点，比记任何一张对比表都重要。
文本引擎类：mermaid、d2、plantuml。输入是文本 DSL，输出依赖引擎渲染。作者只描述结构与关系，版式交给引擎自动布局。代价是版式不可控，产物通常依赖特定渲染器或运行时。mermaid 跑在浏览器里，靠 JavaScript 在客户端把文本渲染成 SVG；d2 是 Go 写的独立编译器，2022 年出现，许可证 MPL-2.0；plantuml 是 Java 生态，许可证 LGPL-3.0，2010 年就在，是三者里最老的。
文本引擎类的好处是写作门槛低，几行 DSL 就能出图，适合工程师随手记。坏处也来自同一处：你交出的是源代码，看到的图是渲染器的产物。一旦渲染器不在，或者版本变了，你看到的图和同事看到的图可能不一样。这在需要长期存档、对外交付的场景里是硬伤。
自包含产物类：diagram-design。它不由引擎渲染，而是让编码 Agent 直接产出自包含的 HTML 加内联 SVG；无构建步骤、无 JavaScript、无外部图片依赖，双击可打开、离线可看。代价是它是一套很重的绘图规范：只用 1 个强调色、无阴影、圆角不超过 10px、所有坐标与间距必须能被 4 整除。上手成本高于写几行 DSL。
自包含产物类的好处是产物就是你自己的文件，不依附任何运行时，十年后双击还能打开。坏处是规范重，写第一张图要比写一段 mermaid 费心思，而且规范由项目方定义，你图的样子要服从它的设计系统，这不是坏事，但对追求自由版式的作者是一种约束。
手绘交互类：excalidraw。白板手绘质感，强项是人与人协作草图。AI 直接产出的是它的场景文件（.excalidraw 与 .excalidraw.json）而非成品图，交付出去还需要对方有同样的编辑器或再导出。它解决的是脑子里的想法还没定型时，一群人一起把它画清楚，而不是一次性交付一份定稿。
四、四个可客观核验的维度
下面把四个维度逐项过一遍，全部基于实核数据，不主观打分。
渲染与运行时依赖：mermaid 依赖浏览器里的 JavaScript；d2 是独立二进制，命令行即可跑；plantuml 需要 Java 运行时；excalidraw 依赖其前端编辑器；diagram-design 的产物是纯 HTML 加内联 SVG，打开即看，不需要任何运行时。
产物形态与可移植性：文本引擎类的产物本质是源文本加渲染器，离开渲染器就看不到图；diagram-design 的产物是文件本身，可移植性最强；excalidraw 的产物是场景文件，需要编辑器才能还原成图。
许可证类型及其分发含义：diagram-design、mermaid、excalidraw 是 MIT；d2 是 MPL-2.0，属弱 copyleft，义务主要落在被修改的文件层面；plantuml 是 LGPL-3.0，属弱 copyleft，通常允许以库形式被更大程序调用，但对修改与再分发有条件。落地前请以各项目 LICENSE 文件原文为准，我们只说许可证类型不同、对二次分发与嵌入的要求不同，不下能不能商用的绝对结论。
维护活跃度与问题密度：下表用实核的星标与未关闭 issue 对照。再次提醒，这不是质量判决，建仓时间与体量差异巨大。
| 项目 | 星标 | 未关闭 issue | 建仓于 | 最近推送 |
|---|---|---|---|---|
| diagram-design | 39,807 | 44 | 2026-04-16 | 2026-09-10 |
| mermaid | 90,244 | 1,785 | 2014-11-01 | 2026-09-14 |
| excalidraw | 131,918 | 3,471 | 2020-01-02 | 2026-09-14 |
| d2 | 25,416 | 528 | 2022-09-05 | 2026-09-13 |
| plantuml | 13,313 | 588 | 2010-11-04 | 2026-09-14 |
最后推送日期全部集中在 2026-09-10 到 2026-09-14 之间，说明五个项目在核数据时都在活跃维护，没有哪个明显停更。把 issue 数和星标放一起看，diagram-design 三万多星只有 44 个未关闭 issue，而 mermaid 九万多星有 1,785 个、excalidraw 十三万多星有 3,471 个。这个差距很扎眼，但必须回到限定条件：diagram-design 才建仓五个月，另外两者分别建仓十二年、六年，功能面和使用人数都不在一个量级。issue 少是年轻带来的，不是质量带来的。
五、跨范式互操作这一层
这一层是 diagram-design 独有、也最值得说的地方。它提供了 draw.io、mermaid、excalidraw 三条导入重绘通道，把已有源文件重绘成它的设计系统。换句话说，它不要求你从零开始，而是把你在别的范式里的存量资产收编进来。
支持输入：draw.io 的 .drawio、.drawio.xml、.drawio.png、.drawio.svg（含压缩 payload）；mermaid 的 .mmd、.mermaid 以及 Markdown 里的 mermaid 代码块；excalidraw 的 .excalidraw 与 .excalidraw.json（不支持它的 png/svg 导出）。
它明确声明不继承源文件的坐标、配色、字体、draw.io 的斜线连接器、mermaid 的自动布局、excalidraw 的手绘几何；一定继承组件、关系、分组、方向。每次导入会输出 fidelity ledger（保真账单），列明被合并、折叠、丢弃的内容。这个账单的价值在于可审计：你交给它一张图，它告诉你哪些保住了、哪些被它按规范折叠或丢掉了，不是黑箱。
重绘带四个旋钮：Format（html、svg、png、html+png），Size（9 档，含 doc-inline、slide-16x9、social-og、print-a4-landscape 等，同时改 viewBox 与字号阶梯），Detail（faithful 最多 24 节点、balanced 最多 12、simplified 最多 7，按固定降级阶梯删减），Audience（engineer、mixed、executive，改措辞不改数量）。这四个旋钮把收编过程变得可控：你不是把一张图丢进去听天由命，而是按交付场景调格式、尺寸、细节密度、读者层级。
值得点评的张力：它的宣传语明确写着 No Mermaid slop，却同时提供 mermaid 导入通道。既批评又兼容，说明它要的不是消灭 mermaid，而是把存量 mermaid 资产收编进它自己的设计系统。这个姿态对已有大量 mermaid 存量、又想统一视觉规范的团队，反而是加分项，因为这等于给了你一条无痛迁移的路，而不是让你二选一。
顺带一提，站内我们也有关于 Agent 工作流的横评，可对照阅读：AI 编码技能框架横评、Claude Code、Cursor 与 Codex 横评、Kimi 与 Qwen、GLM 的长上下文横评。同批次还有 diagram-design 资源篇 与 diagram-design 接入 Claude Code 的 SOP 可供延伸。
六、选型建议与结尾判断
按团队形态给建议，下面一张表收口。
| 团队形态 | 建议方案 | 理由 |
|---|---|---|
| 个人写文档 | mermaid 或 diagram-design | mermaid 上手快、生态成熟；diagram-design 适合要统一视觉且追求可移植 |
| 频繁嵌入技术文档的团队 | mermaid | 渲染器嵌入文档生态最成熟，协作与版本管理顺手 |
| 出给高管看的图 | diagram-design | 设计系统统一、可移植、离线可看，适合对外交付 |
| 多人白板协作 | excalidraw | 手绘草图与实时协作是它的主场 |
| 已有大量 mermaid 或 draw.io 存量 | diagram-design 的导入重绘 | 把存量资产收编进统一设计系统，保真账单可审计 |
结尾判断：选图表方案，买的不是能不能生成图，而是图生成之后归谁、以什么形态存在、谁能打开。文本引擎类把成本放在渲染链路上，产物是引擎的产物；自包含产物类把成本放在绘图规范上，产物是你自己的文件。AI 时代的真正变量不是画得好不好看，而是 Agent 能不能一次性写出可交付的产物，以及这个产物在没有你的环境里还能不能打开。把这条线想清楚，选型就不难了。
常见问题
Q1：这篇横评是亲自压测的吗？ A1：不是。本评测不是亲自压测，所有数字来自 2026-09-15 当天对各项目官方仓库与官方文档的实核，星标数实时变动，只作体量量级参考。
Q2：diagram-design 的 issue 最少，是不是它质量最好？ A2：不是质量判决。它 2026 年 4 月才建仓，而 mermaid 2014 年、excalidraw 2020 年就已存在，体量、年龄、功能面差异巨大，新仓库 issue 少很大程度是还没长大。
Q3：Mermaid 和 diagram-design 能一起用吗？ A3：可以。diagram-design 提供 mermaid 导入重绘通道，支持 .mmd、.mermaid 文件以及 Markdown 里的 mermaid 代码块，会把源文件重绘进它的设计系统，并输出保真账单。
Q4：这几个项目能不能商用？ A4：我们只说许可证类型不同、对二次分发与嵌入的要求不同，落地前请以各项目 LICENSE 文件原文为准。MIT 最宽松；MPL-2.0 与 LGPL-3.0 属弱 copyleft，义务分别落在文件层面与库调用条件上。
Q5：Excalidraw 的 AI 产物能直接交付吗？ A5：AI 直接产出的是场景文件（.excalidraw 与 .excalidraw.json）而非成品图，交付出去需要对方有同样的编辑器或再导出，不适合作为一次性可交付文件。
参考来源