开源ER图工具怎么选？draw.io、erd-editor、SchemaSpy实测对比

做后台开发、数据建模这一行，几乎没有人能绕开ER图。不管是新项目设计表结构，还是接手老系统梳理库表关系，画一张清晰的实体关系图，比看十遍文档都有用。但工具选择一直是个让人头疼的问题：Navicat、DataGrip 这类老牌工具确实强，可它们要么收费、要么只能在本地桌面上用，换个电脑或者拉同事一起评审，协作起来异常麻烦。

这两年 Web 端工具慢慢成熟了，至少有三款开源方案，我已经在真实项目里用了很久，覆盖了“纯手工绘制”“半自动建模”“数据库反向生成”三条完全不同的使用路径。这篇文章就把这三款工具的选型思路、实操步骤、踩坑记录一次性讲透，帮你省去自己试错的成本。

1. 先聊聊选型思路：为什么这三款值得推荐

很多人一听到“开源”，第一反应就是功能简陋、界面难看。说实话，几年前的 Web 开源绘图工具确实有这个问题，但现在情况完全变了。我最初的需求很简单：浏览器打开就能用，不装客户端；画出来的图能导出成图片或 SQL；最好能直接连数据库反向生成，省得手工一个个建实体。在实际测试了七八款工具之后，真正能满足这些要求且长期维护的，就是下面三款。

1.1 选开源工具的底层逻辑

选择开源工具并不只是为了省钱，更多是因为可控。商业数据库设计软件大多把数据存在私有格式里，团队协作时一人一个格式，很难做版本管理。而开源工具里，draw.io 的图本质上是一份 XML 文件，erd-editor 是 JSON 加自定义 DSL，SchemaSpy 生成的是一堆静态 HTML——这些都可以直接提交进 Git 仓库。也就是说，你的 ER 图能够像代码一样做 diff、做 review、做历史回溯，这种体验在付费工具里反而不容易做到。

另外一点是部署自由度。三款工具里，draw.io 和 erd-editor 都有在线公共实例，但如果你所在团队对数据安全比较敏感，完全可以把它们打包进自己的服务器或内网。SchemaSpy 更是天生就是命令行工具，非常适合放进 CI/CD 流程里，每次数据库结构变更后自动生成最新文档。这种自动化能力，是纯图形化商业工具很难替代的。

1.2 三款工具的核心定位差异

我在实际使用中，对这三款的定位越来越清晰：draw.io 是“通用型绘图工具”，适合画任何类型的图表，ER 图只是它的应用场景之一；erd-editor 是“专职 ER 建模工具”，面向开发者的 DSL 语法让建表像写代码一样快速；SchemaSpy 则是“文档生成器”，它解决的痛点是我拿到一个陌生数据库时，如何快速弄清全貌。

工具没有绝对的好坏，只有适合的场景。如果你是一个前端或后端工程师，只是想快速画一张表结构图给同事看，直接上 draw.io。如果你在建表阶段就想同步维护模型，并且希望后续能自动生成 DDL，erd-editor 效率极高。如果你需要梳理一个几百张表的旧系统，SchemaSpy 半小时就能出全套报告，用手画一个星期都未必能画完。

2. 三款工具逐一拆解：能力、操作与应用场景

这节我按“工具怎么用、怎么操作、适合解决什么问题”的顺序来写，方便你直接对着操作。考虑到每个工具的侧重点不同，我会把操作步骤和背后的设计逻辑放一起讲，这样你不仅能照着做，还能理解为什么这样做。

2.1 draw.io：Web 端通用绘图的老牌选手

draw.io 在 GitHub 上已开源多年，官方在线站点 app.diagrams.net 就可以直接打开，也支持自己部署。很多人不知道的是，它其实内置了一套“Entity Relation”图形库，画 ER 图时根本不需要从零开始画矩形和连线。

2.1.1 基础画图操作路径

打开网页后，选择“空白图”或“实体关系”模板。左侧图形库搜索“entity relation”，里面会提供标准的三列布局实体表格（包含表名、字段名、字段类型），比单纯用矩形手动拼装规范很多。拖一个实体到画布，双击表格即可修改字段内容，右键可以选择添加行。表之间的连线可以用左侧的“关系线”拉拽，关联完成后还可以把连线设置为识别关系，比如 crow's foot 标记法。

但有个坑必须提醒：默认的 entity relation 图形不支持双击自动加行，需要手动编辑表格数据。如果你只是画一张几个表的简单模型，这倒没什么问题；但如果你要画几十个字段的大表，手工添加会非常累。我的做法是先在 Excel 或文本里整理字段列表，再一次性粘贴进去，效率提升明显。

2.1.2 实战心得：模板的选择比画图更重要

draw.io 左侧图形库里有多种 ER 图模板，有的带主键标记，有的带索引标记，有的支持更多样式。经验是不要纠结于模板丰富程度，选最普通的“实体关系”模板即可。因为模板本质就是图形样式，颜色、线型都可以后期调整，字段结构才是核心。我习惯用“颜色区分实体类型”——比如用户、订单这类业务主表用浅蓝，日志、流水这类辅助表用浅灰，这样一眼就能看出哪些是核心表。

导出方面，draw.io 支持 PNG、SVG、PDF，最值得推荐的是 SVG。因为 SVG 是矢量图，放到文档或网页里无论怎么缩放都清晰，还能保留文本内容，方便后续检索。如果团队里有人不想用 Web 端，draw.io 也提供 VS Code 插件，可以直接在编辑器里编辑同一份文件，这一点对开发团队非常友好。

2.2 erd-editor：面向开发者的高效建模工具

erd-editor 是 GitHub 上一个活跃的开源项目，以前叫 vuerd，主打“DSL 驱动 + 可视化编辑”。它的特点是：你不需要拖拽任何东西，只要在左侧文本区写类似建表语句的 DSL 格式，右侧就会实时渲染出 ER 图，反过来拖动图形时，左侧代码也会同步变化。这种双向绑定体验，非常契合写代码出身的工程师习惯。

2.2.1 利用 DSL 快速定义表结构

它的语法非常薄，基本就是“表名 { 字段名 类型 [注释] }”的格式。举个实际例子，我要建一套简单的用户-订单模型，DSL 长这样：

User { id int [pk] name varchar email varchar } Order { id int [pk] user_id int [ref: > User.id] total_amount decimal created_at datetime }

写完这段，右侧就自动出现了两张表，并且生成了从 Order 指向 User 的一对多关系连线。对比用鼠标拖拽实体再连线，这种方式优势极大，尤其是几十张表的情况下，纯文本比图形界面更容易批量修改和批量复制。而且 DSL 文件本身是纯文本，放进 Git 仓库做 diff 时干净清楚，不会像 draw.io 的 XML 那样冗余信息特别多。

2.2.2 反向工程与 SQL 导入导出

erd-editor 最大的亮点是对数据库的导入导出支持。在右侧工具栏可以配置数据库连接，默认支持 MySQL、PostgreSQL、SQLite 等主流关系型数据库。连接后选中需要导入的库，工具会读取所有表的字段、主键、外键关系，自动生成对应的 ER 图和 DSL 文本。这个“反向工程”功能，对于接手遗留项目简直是救星。

导出方面，它支持生成 DDL SQL 脚本，也就是可以直接拿到数据库里执行建表；也支持导出成图片。我在实际项目里经常用的流程是：维护一份 DSL 文件作为表结构的设计稿，评审通过后用它的导出功能生成 SQL，再放到 Flyway 或 Liquibase 这类迁移工具里去执行。这样一来，ER 图、表结构、迁移脚本三者完全同步，再也不会出现“图一套、数据库一套”的情况。

2.2.3 部署与协作注意事项

erd-editor 既提供了在线版，也支持本地通过 Docker 或 npm 一键启动。对于追求数据不出内网的团队来说，本地部署非常方便，一条命令就能跑起来。因为它的存档是一个 JSON 文件，团队成员之间可以直接分享这个 JSON 或 DSL，非常轻量。不过它的在线公共版有时访问不够稳定，关键项目我建议还是本地部署更稳妥。

需要注意的是，它比较适合“从一开始就使用”的项目。如果数据库里已经有几百张表，导入后画布会非常杂乱，需要依靠自动布局功能整理，但效果有限。这种情况我会改用 SchemaSpy 来生成文档，而不是硬塞进 erd-editor。

2.3 SchemaSpy：自动生成数据库全量文档的利器

SchemaSpy 跟前两个工具不是一个路子，它是一个基于命令行的 Java 工具。你不需要用鼠标画任何东西，只要配置好数据库连接，它就会自动分析所有表、列、主外键、索引、视图，生成一套完整的静态 HTML 报告，里面包含全局关系图、每张表的详情页、甚至表之间关系的 SVG 图。

2.3.1 一条命令生成全站文档

以 MySQL 为例，基本命令如下：

java -jar schemaspy.jar -t mysql -host localhost -port 3306 -db mydb -u root -p yourpassword -o /output/dir

运行完成后，去输出目录打开 index.html，就能看到整个数据库的 ER 总览图。这个图不是一整张巨大的图，而是分模块组织的：所有表按照关联关系自动排列，点击任意一张表，又能跳转到这张表的字段详情、索引信息、隶属于它的外键关系、以及依赖它的表。对于刚接手一个大项目的人来说，这就是一份“数据库地图”，比任何人工画的图都全。

新版本还支持通过 Docker 运行，比如：

docker run -v /output:/output schemaspy/schemaspy:latest -t mysql -host host.docker.internal -db mydb -u root -p pass -o /output

我用 Docker 版本跑过一次几十张表的系统，前后不到一分钟就全部生成完毕，而且报告里中文字段也能正常显示，只要在命令里加上-charset utf8参数。这一点比很多商业工具还要省心。

2.3.2 适合什么场景，不适合什么场景

SchemaSpy 最大的优势是“客观全面、零遗漏”。你不需要手动确认每张表，工具会把整个库都给扫出来，包括那些你可能完全不知道存在的历史表。但这也是它的短板：它生成的是“现状”，而不是“设计蓝图”。当你处于新建系统的设计阶段，想自由地构思表结构时，SchemaSpy 帮不上忙，因为它只能处理已有的数据库。

所以我的经验是：新项目设计阶段用 erd-editor 或 draw.io；老项目梳理、数据库迁移、文档审计用 SchemaSpy。比如我们做过一次数据库拆分，需要摸清哪张表被哪些表引用，SchemaSpy 的全局关系图直接列出了所有上下游依赖，省掉了大量体力活。

3. 三款工具横向对比：关键维度逐一过一遍

前面分别介绍了三款工具，这一节我按实际选型最关心的维度做横向对比，希望你不用再翻多个文档去比较。对比分为两块：功能维度参数对比和应用场景选型建议。

3.1 功能维度参数对比

下面这张表是我的个人实测感受，不代表绝对标准，但基本能反映三款工具的真实表现。

以“数据库反向生成”为例，draw.io 不是完全没有办法，可以通过第三方脚本把数据库表结构转成 drawio 的 XML，再导入绘制，但配置成本高、效果一般，不如直接用 erd-editor 或 SchemaSpy。而 SchemaSpy 不支持手工修改，如果画完想调整布局，只能在 HTML 层面做小改，不建议作为日常交互工具。

这个表格只是静态对比，实际情况中还有一个重要变量：团队的协作习惯。如果团队所有人都用同一个工具，那协作成本几乎为零；如果每个人用不同工具，即便是再好的工具也会带来摩擦。所以我的建议是，新团队或新项目先统一主用工具，其余工具作为备选方案配合使用。

3.2 基于实际场景的选型建议

具体到“我到底该用哪一款”这个问题，我一般按下面的逻辑来推荐：

• 场景一：快速画一张图，给同事说明表关系。用 draw.io，打开即用，学习成本最低，而且画出来比较美观。
• 场景二：新项目设计阶段，边设计边维护模型。用 erd-editor，DSL 写起来快，改起来也快，还能源源不断生成建表语句。
• 场景三：接手老系统，需要快速梳理全量表结构。用 SchemaSpy，自动化扫描，半小时得到全套地图。
• 场景四：团队需要维护长期文档，希望 ER 图跟着代码一起版本化。优先 erd-editor 的 DSL 或者 draw.io 的 XML，入库管理最省心。
• 场景五：偶尔需要给客户或领导汇报，展示漂亮的大图。用 draw.io 调整样式后导出 SVG，或直接在 erd-editor 里导出高分辨率图片。

选型时不要盲目追求功能全，能满足核心痛点就好。很多时候最简单的工具反而是团队使用率最高的，这一点我深有体会。我们团队最开始引进了好几个高端建模工具，结果大多数人日常工作还是回退到 draw.io，因为打开就能画，不设置任何连接信息，不记任何命令。

4. 实战演练：用“图书馆借书系统”跑通完整流程

这一节我用一个经典的“图书馆借书系统”作为案例，分别走一遍三款工具的操作流程。数据模型一共有四张表：图书表、读者表、借阅记录表和管理员表，关系是读者与图书通过借阅记录形成多对多关联，管理员负责维护图书信息。这样的模型虽然简单，但已经覆盖了主键、外键、一对多、多对多等常见元素。

4.1 使用 draw.io 手工绘制完整 ER 图

用 draw.io 画这张图的思路是“先表后线再标注”。先拖拽四个实体表格，依次填入字段信息。图书表（book）字段包括 book_id、title、author、isbn、publisher、publish_date；读者表（reader）字段包括 reader_id、name、phone、email；借阅记录表（borrow_record）字段包括 record_id、book_id、reader_id、borrow_date、return_date；管理员表（admin）字段包括 admin_id、username、password_hash。

填充表格时有个技巧：双击表格后进入编辑状态，直接粘贴多行文本，draw.io 会自动识别换行。然后调整各表位置，把借阅记录表放在图书表和读者表中间，这样画出的连线不会交叉，整体布局更清爽。接下来从借阅记录表的 book_id 连到图书表的 book_id，从借阅记录表的 reader_id 连到读者表的 reader_id，连线默认是带箭头的实线，右键可以设置成一对多标识。

最后加一个图例说明，把主键字段用下划线样式标注出来，外键连线用不同颜色区分。导出 PNG 之前，记得在“文件-属性”里设置好导出分辨率，一般 200 DPI 足够清晰。这里特别提醒，draw.io 的连线如果连错了实体，拖动连线端点时有吸附效果，可以微调到正确位置。

4.2 使用 erd-editor 通过 DSL 一步生成模型

用 erd-editor 就完全不同了，全程不需要鼠标。对应的 DSL 定义如下：

Book { book_id int [pk] title varchar author varchar isbn varchar publisher varchar publish_date date } Reader { reader_id int [pk] name varchar phone varchar email varchar } BorrowRecord { record_id int [pk] book_id int [ref: > Book.book_id] reader_id int [ref: > Reader.reader_id] borrow_date date return_date date } Admin { admin_id int [pk] username varchar password_hash varchar }

写完这段 DSL，右侧画布自动生成四张表，并以箭头标出 BorrowRecord 对 Book 和 Reader 的引用关系。此时如果发现字段漏了，直接在文本区补一行，画布实时更新；如果觉得默认布局不美观，拖动某张表，旁边的引用线会自动重新规划路径，这种体验非常顺滑。

完成建模后，点导出按钮选择“生成 SQL”，工具会输出整套 MySQL 建表语句，包括外键约束。或者先连接一个测试库，点击导入生成 ER 图，检查无误后再反向导出 SQL，这样就能保证建模和实际库结构完全一致。我自己常用的流程是：设计阶段不连数据库，先写 DSL 确认模型；评审通过后再连接开发库，用导入功能验证，最后把 SQL 交给迁移工具执行。

4.3 使用 SchemaSpy 自动生成借书系统文档

假设这个借书系统的库已经建好了，我想快速产出一份完整的库表文档，就用 SchemaSpy。前提是本地装了 Java 环境或者 Docker，并且有数据库的连接账号。以 Docker 方式运行，命令大致如下：

docker run --rm -v /tmp/output:/output schemaspy/schemaspy:latest -t mysql -host 127.0.0.1 -port 3306 -db library -u root -p yourpass -o /output -charset utf8

运行日志会打印扫描过程，结束之后到 /tmp/output 目录下，用浏览器打开 index.html。左侧是表列表，中央是全局关系图，借阅记录表位于图书表和读者表之间，连接线清晰标出了引用关系。点击 BorrowRecord 表，还能看到它的字段详情、索引、以及它引用了哪些表。整个过程没人手工拖动任何图形，但产出的文档比手工绘制的更全更客观。

我建议把生成路径固定成一个脚本，放进项目目录里，比如根目录放一个 generate-db-doc.sh，团队成员随时可以重新生成最新文档。每次数据库结构有变更，跑一次脚本，再提交到文档库，这个习惯能省掉无数沟通成本。

5. 常见问题与踩坑记录：这些细节最容易翻车

使用过程中难免遇到各种小问题，有些问题从报错信息根本看不出来原因，我把自己踩过的一些坑整理出来，供你参考。

5.1 draw.io 相关问题

常见问题是“连线表示不了正确的基数关系”。draw.io 默认线型是普通实线，不显示“一”“多”标记。解决方法是点选连线后，在右侧样式面板里将“开始/结束箭头”改成 crow's foot 风格。网上有些模板里已经内置了这个样式，拖出来直接用更省事。但如果你们团队习惯看 Chen 表示法或 UML 表示法，记得在项目规范里注明，否则不同人画出来的图风格参差，看起来非常乱。

还有一个容易忽略的点：当你把 draw.io 的 XML 文件提交到 Git 之后，每次手动编辑都会产生大量 diff，因为 XML 里记录了坐标、样式等大量附加信息。团队协作时，最好规定由固定成员来维护 ER 图，避免多人同时修改导致冲突频繁。如果你需要更轻量、更适合 diff 的方式，直接切换去用 erd-editor 的 DSL 会更舒服。

5.2 erd-editor 连接数据库失败排查

erd-editor 连接数据库时最容易出现的问题是“找不到驱动”或“连接超时”。前者多发生在使用 MySQL 8 以上版本时，默认驱动版本不匹配。解决方式是在项目配置里手动指定或更换驱动为较新的兼容版本；后者则要检查数据库所在机器是否允许远程连接，以及防火墙是否放行对应端口。

另外一个小坑是，从数据库导入时，如果表名或字段名包含特殊字符、空格，DSL 解析器可能报错。我的习惯是先通过 SQL 脚本把表结构导出，再在 erd-editor 里“导入 SQL”而不是直接连库，等确认 schema 正确后，再处理风格样式问题。这样也能避免生产环境连接信息直接在界面上暴露。

5.3 SchemaSpy 输出乱码或缺少关系图

SchemaSpy 输出乱码基本都出在字符集没有指定。数据库端是 utf8mb4 时，命令里务必加-charset utf8或者-charset utf8mb4，否则 HTML 页面上的中文全是问号。还有 Graphviz 依赖的问题，旧版 SchemaSpy 依赖本地的 Graphviz 来生成 SVG 关系图，新版已经把相关能力集成进 jar 包，如果你用的版本还报 Graphviz 缺失，最简单的解法是改用 Docker 镜像，镜像里已经包含了运行环境。

最后提醒一个老生常谈的问题：数据库密码不要直接写在脚本命令里。即使本地开发环境，也不建议这么干。可以把密码放到环境变量中，避开 shell 历史记录和截图传播的风险。SchemaSpy 本身并不负责运维安全，但作为使用者，我们得对自己团队的信息安全负责。

通过这些工具的使用，我最大的体会是：画 ER 图这件事，真正卡住人的不是软件能力，而是对库表关系的理解。工具只是把脑中的模型转成可视化的媒介，选一款顺手的、符合团队协作习惯的就好。如果你还在纠结，先从这个原则出发：常用、够用、能导出、能回滚。至于更复杂的自动化、文档生成、CI/CD 集成，都是在长期使用中可以慢慢补上的能力。