3款开源Web端ER图设计工具对比与实践指南

做数据库设计这几年，我最大的感受是：ER图这东西，重要的不是画得好看，而是能准确表达出“谁和谁是什么关系”。但现实中的麻烦在于，很多工具要么太笨重，装完一年用不了几次；要么收费，试用期一过就各种限制。后来我干脆把整套工作流搬到Web端——打开浏览器就能画，画完直接导出给团队评审，省掉了装客户端、换机器、版本不一致这些破事。今天这篇就聊聊我长期在用的3款开源Web端ER图设计工具，它们分别是图形化画图工具diagrams.net、专注数据库表结构设计的老牌工具WWW SQL Designer，以及把ER图写成文本再由浏览器渲染的Mermaid erDiagram。

这三款工具覆盖了三种完全不同的画图习惯：有人喜欢拖拽图形，有人习惯先建表再连线，还有人希望ER图能像代码一样放进Git仓库、用文本维护。不管你是正在做数据库课程设计的学生，还是需要在项目里长期维护数据模型的开发者，这里面总有一款能对上你的使用习惯。

1. 为什么我推荐这三款Web端开源工具

1.1 选工具前，先搞清楚自己的真实需求

很多人一上来就问我“哪款ER图工具最好用”，我的回答通常是：先别急着选工具，先回答三个问题——你多久画一次ER图？画完给谁看？要不要导出建表SQL？

这三个问题的答案，直接决定了工具选型的方向。举个例子，如果你是给课程设计画一张ER图交作业，那最核心的需求就是“画得清楚、能放进论文”，这时候让代码控去学Mermaid语法就是本末倒置；反过来，如果你在一个长期维护的项目里，每次表结构变更都要同步更新文档，那图形界面反而成了负担，用文本描述ER图再自动渲染，是最省心的方案。

这也是为什么我没有推荐那种“全家桶”式的一体化数据库设计平台。在我看来，工具之间不是替代关系，而是负责不同环节。真正高效的工作流，往往是让不同的工具各自做自己最擅长的事，最后通过导出和导入把它们串起来。

1.2 三款工具的开源协议与基础对比

在开箱即用这件事上，这三款工具都做到了极致：不需要下载安装包，不需要配置复杂的运行环境，只要浏览器能上网就能干活。如果你有私有化部署的需求，它们也都支持部署到自己可控的服务器上，数据完全由自己掌握。

为了让你一眼看出它们的区别，我把核心差异整理成了下面的表格：

从表格里能看出来，我选工具的底层逻辑是看“产出物”：diagrams.net产出的是给人看的图，WWW SQL Designer产出的是能直接跑的建表SQL，Mermaid产出的是一段可复用的文本描述。搞清楚这一点，后面所有操作都顺了。

2. 三款工具核心能力逐项拆解

2.1 diagrams.net：能打天下的通用ER图画布

diagrams.net是开源的流程图和图表绘制工具，Apache 2.0协议，可以放心商用。它的在线版地址是app.diagrams.net，打开就是画布，大部分情况下你甚至不需要注册账号，画完直接下载文件走人。

很多数据库从业者其实早就用过它，但只是把它当普通画图工具用，没有发挥出它在ER图场景下的潜力。事实上diagrams.net内置了Database图形库，里面有现成的Entity、Table等形状，新建图的时候直接选“实体关系”模板，画出来的表和常规数据库设计工具一样规整。

更关键的一个功能是“从SQL生成ER图”。在菜单栏的Arrange → Insert → Advanced → SQL里，把建表语句粘贴进去，工具会自动解析出每张表及其字段，生成图形化的表结构。这个功能对大表特别有用，几十张表手动画得累死，用SQL一把梭进来，再手动整理布局就行。反过来，如果你在画布上画好了实体关系，也可以通过Tools菜单里的导出功能，把设计转换成SQL脚本。

我的日常习惯是：把.drawio文件直接存进项目的Git仓库，配合VS Code插件（Draw.io Integration）在编辑器里打开，改完图形就相当于更新了文档，提交时还有diff可以看。需要发给人评审的时候，导出成PNG或SVG，沾到IM聊天窗口里就能看，对方完全不需要安装任何工具。这也是Web端工具最大的优势之一：交付成本极低。

2.2 WWW SQL Designer：数据库设计专用的Web老炮

WWW SQL Designer是一个很老但很经典的开源工具，GPL-3.0协议，源码托管在GitHub。它和通用画图工具有一个本质区别：它是先有表，后有图。使用逻辑非常硬核——你直接在建表模式下操作，最终产物是一份符合语法规范的SQL DDL。

整个界面分三块：中间是画布，左侧是工具栏和表列表，底部是当前表的字段编辑区。在画布上添加一张表之后，双击表名可以修改表名，在字段编辑区里可以逐条添加字段、设置数据类型、长度、默认值，勾选主键、唯一、非空等约束。所有操作都是表单化的，不需要像图形工具那样去拖动文本框调整位置。

它的杀手锏是工具栏里的“Export DDL”按钮。你可以在下拉框里选择目标数据库类型，比如MySQL、PostgreSQL、Oracle、SQLite等，然后一键生成建表SQL。对于做数据库课程设计或者小型业务系统开发的人来说，这个功能省下了大量手写建表语句的时间，而且生成结果规范，不容易因为手误漏掉逗号或括号。

唯一的短板是它偏老，界面是英文，而且默认不处理AUTO_INCREMENT这类扩展属性，导出后需要自己补一下。但只要你理解了它“面向SQL设计”的理念，这个小坑完全不是问题。

2.3 Mermaid erDiagram：让ER图走进代码仓库

Mermaid是一个用文本描述图表的开源项目，MIT协议，erDiagram是它的ER图模块。它解决的问题很直接：ER图可以作为代码存在，被版本管理、被diff、被复用。

它的语法非常直观，核心是三部分：实体定义、属性定义、关系定义。实体就是表，属性就是字段，关系就是表之间的连线。写完一段文本之后，把它丢进Mermaid Live Editor（mermaid.live），右侧会自动渲染出对应的ER图。你甚至不需要额外安装任何软件，在浏览器里就能完成整个过程。

但是Mermaid真正的威力在于嵌入。GitHub和GitLab的原生Markdown渲染器都支持Mermaid，意味着你把ER图文本直接写进README里，页面打开就是一张图；docsify、VuePress等文档站也有对应的插件支持。这意味着什么？意味着你的技术文档里不再是一张“静态死图”，而是一段可以随代码一起演进、可以review注释的活文本。同事改了表结构，顺便改一行ER图代码，文档和实现永远是同步的。

我自己的项目里有不少ER图就是用.mmd文件存在仓库里，配合CI流水线用Mermaid CLI（mmdc命令）自动导出图片，统一归档到文档站点。这套流程跑起来之后，我再也没手动修过文档里的数据模型图。

3. 实操：图书馆借书系统ER图，三种工具各画一遍

3.1 先把表结构想明白再动手

下面我用一个最经典的“图书馆借书”案例，把三款工具完整走一遍。这个案例在数据库课程设计里出现频率极高，实体不多，但关系清晰，很适合作为上手练习。

先理清业务：一个读者可以借多本书，一本书可以被多个读者借过。如果直接在读者和图书之间画多对多关系，在实现上会绕弯子，所以标准做法是引入一张借阅记录表，把“多对多”拆成两个“一对多”。

这里我定义三张核心表：

• 读者表BORROWER：borrower_id（主键）、name、phone、reg_date
• 图书表BOOK：book_id（主键）、title、author、publisher、isbn、stock
• 借阅记录表BORROW_RECORD：borrow_id（主键）、borrower_id（外键）、book_id（外键）、borrow_date、due_date、return_date、status

关系是：BORROWER 1—N BORROW_RECORD；BOOK 1—N BORROW_RECORD。下面逐个工具演示。

3.2 diagrams.net实操：从建表SQL快速反推ER图

打开app.diagrams.net，新建图的时候选择“实体关系”模板。如果你手头已经有SQL建表语句，这一步不用傻傻手动拖方块，直接用它的SQL导入功能：

1. 点击菜单栏Arrange → Insert → Advanced → SQL。
2. 在弹出的文本框里粘贴建表SQL，注意用标准的CREATE TABLE，字段之间逗号分隔，最好显式标出主键约束。
3. 点击OK后，工具会自动把每张表解析成图形放到画布上，字段列表会自动展开。
4. 手动补关系连线：从BORROW_RECORD表的borrower_id字段拉一条线到BORROWER表的主键borrower_id；同样从BORROW_RECORD表的book_id拉到BOOK表的主键book_id。
5. 设置连线样式，比如标上1:N或者在端点上用crow's foot记号，直观表达外键关系。
6. 最终导出：如果要放进论文，建议导出SVG矢量图或者把PNG缩放比例调到200%，清晰度才不会糊。

这里说个实操细节：从SQL导入生成表非常快，但关系线基本不会自动生成，因为很多人的建表语句里外键约束写得不完整，工具解析不出来。所以流程上我推荐“SQL导入生成表框架 + 手动连线整理关系”，两者结合效率最高。另外，如果表特别多，建议先打开“View → Diagrams”面板，把图形按层次整理好，导出的时候才能一张图看全。

3.3 WWW SQL Designer实操：画表直接出建表语句

打开WWW SQL Designer的在线Demo（GitHub仓库里有入口链接），它没有两分钟上手门槛，操作完全是数据库思维：

1. 在工具栏点击表的按钮，然后在画布上点一下，生成一张新表，默认名字叫table1。
2. 双击表头修改表名为borrower。
3. 在底部的字段面板里添加字段：字段名填borrower_id，类型选INT，长度可以填11，勾选PK主键。
4. 继续添加name、phone、reg_date等字段，类型分别选VARCHAR和DATE。
5. 用同样方式创建book和borrow_record两张表。注意borrow_record里的borrower_id和book_id，类型也选INT，但不要勾选PK，它们后面要作为外键。
6. 建立关系：点击borrower表的borrower_id字段（会高亮），然后直接拖拽到borrow_record表的borrower_id字段上，松手后会自动生成一条关系连线。book到borrow_record同理。
7. 点击工具栏里的Export DDL按钮，选择目标库为MySQL，弹出框里就是完整的建表SQL，直接复制到MySQL客户端里就能执行。
8. 别忘了保存一份XML格式的设计文件，这个是它自己的工程文件，下次还能接着改。

我有一次给一个课程设计项目做快速原型，整个ER图加建表SQL，不到10分钟就搞定了，最后交上去的作业分数还很高。当然也有坑：比如它生成的SQL默认不会加上AUTO_INCREMENT，主键需要自己手工补上“AUTO_INCREMENT”关键字；还有就是在下拉框里选择类型时，要留意MySQL的VARCHAR需要带长度，否则导出SQL里会少参数。

3.4 Mermaid erDiagram实操：用文本描述图书馆借书模型

如果用Mermaid，这段ER图的源码长这样，我把它写成text块方便阅读：

erDiagram BORROWER ||--o{ BORROW_RECORD : "借阅" BOOK ||--o{ BORROW_RECORD : "被借" BORROWER { int borrower_id PK varchar name varchar phone date reg_date } BOOK { int book_id PK varchar title varchar author varchar isbn int stock } BORROW_RECORD { int borrow_id PK int borrower_id FK int book_id FK date borrow_date date due_date date return_date varchar status }

把这段文本复制到mermaid.live左侧编辑器里，右侧立刻渲染出一张关系图。关系行的含义要理解清楚：||--o{表示“一个读者对应零个或多个借阅记录”，前面的||读作“恰好一个”，后面的o{读作“零个或多个”。方向是从父表指向子表，配合关系标签，一眼就能看出业务含义。

渲染确认没问题后，你可以直接下载SVG或PNG，也可以把这段文本直接粘贴到GitHub的Markdown文件里，页面会自动渲染成图。需要批量导出时就装@mermaid-js/mermaid-cli，命令行里一句话把.mmd文件转成图片：

mmdc -i library.mmd -o library.png -w 1200 -b white

这个工具链对我这种长期和文档打交道的人来说简直是福音，因为ER图和代码共用一套版本管理逻辑，改没改、改了什么，全都有迹可循。

4. 实战中踩过的坑和排查技巧

4.1 diagrams.net相关问题

我在diagrams.net里遇到最多的问题，是从SQL导入生成ER图后关系线缺胳膊少腿。分析下来基本都是SQL语句里没有写外键关联导致的，工具自然无法推断关系。所以要么在SQL里显式加上FOREIGN KEY约束，要么干脆接受“先导入再手动连线”这个流程，心里有预期就不会烦。

另一个常见问题是导出的图片清晰度不够。特别是要放到论文里或者放大看字段名时，默认的PNG导出偏模糊。解决方式很简单：导出时在设置里把缩放比例调到200%，或者直接导出SVG，在Word里插入SVG后放大不会失真。

4.2 WWW SQL Designer相关问题

老项目普遍存在现代浏览器兼容性问题，WWW SQL Designer也不例外。我实测Firefox和Edge偶尔会出现按钮点击没反应、字段下拉框渲染异常的情况，换成Chrome后一切正常。如果你遇到界面卡顿或者按钮失灵，优先换浏览器。

再就是误刷新导致整个设计丢失。这个工具没有自动保存，你画到一半手一滑按了F5，全部白干。我的习惯是每完成一张表就点一下保存按钮，把XML文件下载到本地，做到“表级保存”。别嫌麻烦，这个习惯在关键时刻能救命。

还有一个细节是导出SQL时注意目标数据库类型的选择。默认模板和不同数据库的方言有差异，比如PostgreSQL和MySQL在自增字段、引号风格上就不一样。导出后最好先到数据库里跑一遍，确认没问题再继续。

4.3 Mermaid erDiagram相关问题

Mermaid在中文环境下最大的问题是字体。在mermaid.live里渲染一般没问题，但用CLI导出图片时，如果系统缺少中文字体，生成的PNG里中文可能变成方块或者乱码。解决办法是给mmdc指定适合的字体配置，或者在容器环境里安装中文字体包。

还有一点，Mermaid是自动布局，不能像图形工具那样手动拖动每个节点。一旦实体多、关系复杂，图会变得比较拥挤。我的经验是，尽量把ER图拆分成多个子图，比如“用户域”“订单域”“库存域”各一张，阅读起来比一张巨图清晰得多，渲染性能也好。

4.4 常见问题速查表

为了方便你以后排查，我把上面这些经验整理成了一张速查表：

写在最后的话

我现在的使用习惯基本固定下来：课程设计、快速原型这类一次性的任务，优先上WWW SQL Designer，因为它能把表结构设计直接变成建表SQL，效率是第一位的；正式文档、对外汇报、论文配图，用diagrams.net，因为它能产出漂亮且可控的交付物；而长期维护的项目，尤其是有多人协作和文档沉淀需求的，必然选Mermaid erDiagram，让ER图作为代码仓库的一部分持续演进。

最后分享一个我踩过很多次坑之后总结出来的习惯：不管用哪个工具，先拿张纸或者白板，把实体、主键、外键、关系列个草稿，然后再开电脑落到工具里。很多时候你在软件里反复拖拽、反复修改，根本问题不是工具不好用，而是业务关系没想清楚。ER图的本质是帮我们理清数据模型，工具只是表达手段，别把精力浪费在折腾工具上。