Web端开源ER图工具推荐：从画图到SQL生成全搞定

最近好几个做课程设计和系统项目的朋友跑来问我同一个问题：能不能不装那些笨重的原生客户端，直接在浏览器里把数据库表结构画成 ER 图？这题我太有发言权了。早些年我做一个学校实训管理系统，光是为了在办公室、家里、客户现场三台设备之间同步画图，就折腾了整整一个晚上，最后实在受不了，才把目光彻底转向 Web 端可用的开源工具。

先说结论：Web 端 + 开源 + 数据库 ER 图设计，这个组合现在完全成熟了。你不需要装 PowerDesigner，不需要买 Navicat 的高级版，更不用把 DBeaver 的插件体系研究一遍，只需要一个浏览器，就能完成从建表、画关系、导出 SQL 到生成文档的一整套流程。这篇文章我会把目前实测下来最值得用的 3 款开源工具拿出来逐一点评，从它们的核心功能、适用场景、实际踩坑点讲起，最后附带一套完整的实操流程，保证你看完就能直接用起来。如果你是正在做数据库课程设计的学生，或者日常需要维护老项目但不想被客户端绑死的开发，这篇内容应该能帮你省下不少时间。

1. 为什么要选 Web 端开源 ER 图工具

1.1 从“装客户端”到“开浏览器”的习惯迁移

早期的数据库设计工具几乎全是桌面应用，最有代表性的就是 PowerDesigner 和 ERwin。这类工具功能确实强大，建模、反向工程、代码生成一套全，但问题也非常明显：安装包动辄几个 GB，许可证价格不菲，而且用的是本地文件存储，团队协同基本靠手动发文件、合并文件，版本管理一塌糊涂。更麻烦的是换电脑就得重装一次，环境配置、驱动路径、授权激活每一步都能卡你半天。

我印象最深的一次，是帮一个朋友调一个学生选课系统的数据库设计。他把数据库文件拷给我，我电脑上没装他那款工具，光是对版本就花了快一个小时。后来我干脆打开 draw.io 的网页版，让他把表结构贴过来，我在线重建关系，一步一步把 ER 图画完再导成图片发给他。从那次之后我就悟了：ER 图这个事，绝大多数场景根本不需要桌面级重武器，一个能随时打开、随时分享的 Web 工具才是日常最高频的刚需。

Web 端工具还有一个隐形优势就是跨平台。你公司电脑是 Windows，家里是 Mac，临时在平板上也要看一眼前端同事发来的表结构，这时候只要浏览器统一了，所有环境差异就都不存在了。配合云盘的自动备份，画到一半关电脑也不慌，重新打开还接着上次的进度，这个体验是本地文件模式完全比不了的。

1.2 一张“合格”的 ER 图到底需要什么

在我们深入工具之前，先简单对齐一下 ER 图的核心要素。很多新手拿到工具就乱画一通，画出来的东西只有他自己看得懂，这其实不是工具的问题，而是对 ER 图本质的理解还不够。

ER 图解决的是三件事：第一，有哪些实体，对到数据库里就是有哪些表；第二，每个实体有哪些属性，对到数据库里就是有哪些字段以及字段类型；第三，实体之间有什么关系，对到数据库里就是主外键关联以及一对多、多对多这种基数关系。作为一个合格的设计工具，它至少要能画表、能画字段、能画关系连线，并且最终能导出成 SQL 或者图片，方便后续开发直接执行建表。

我再往后加两条我自己很看重的标准：一是能不能从现有数据库“反向生成”ER 图，二是能不能把 ER 图变成可以被 Git 管理的文本文件。这两个能力放在当下特别重要，前者解决的是老项目维护问题，数据库早就跑起来了但文档缺失，你总不能手工一张张表画吧；后者解决的是多人协作问题，ER 图如果能像代码一样走 diff、review，那它就不再是一张一次性的图片，而是持续演进的活文档。用这个标准去筛，市面上大量“看着很美”的工具就被淘汰了。

2. 三款工具逐个拆解：风格完全不同的三种解法

2.1 draw.io（diagrams.net）：能自动导入表结构的万能绘图板

第一款要聊的是 draw.io，现在官方叫 diagrams.net，但我习惯还是叫它 draw.io。它是开源项目，许可证是 Apache 2.0，有桌面版，也有网页版，网页版地址直接用浏览器访问就可以打开，不用注册不用安装，这一点对很多临时要用一下的人来说简直是救星。

很多人只知道 draw.io 是个通用绘图工具，可以画流程图、架构图，却忽略了它有一个专门针对数据库的“SQL 导入导出”功能。在菜单里找到 Arrange 下方的 Insert 下面的 Advanced，再选 SQL，它会弹出一个文本框，让你直接粘贴建表语句，或者配置数据库连接自动读取表结构。粘贴 SQL 的方式我试过很多次，只要是标准的 CREATE TABLE 语句，它就能把表、字段、主键、外键都识别出来，自动生成带连线关系的 ER 图。

它还有个特别实用的点：因为底层数据模型比较通用，生成的 ER 图可以继续手动调整，拖拽表位置、修改连线样式、加注释、加分组框，所有操作都在浏览器里完成，跟画普通图形一样顺手。画完之后可以导出成 HTML、PNG、SVG，也可以直接保存到 GitHub、Google Drive、OneDrive 这类云端存储里。对于团队协作来说，这个云存储集成是真的方便，你画完图，链接甩到群里，谁都能打开看，也不需要专门装什么看图软件。

当然它也有明显的缺点。第一，它本质上是个通用绘图工具，不是专业的数据库建模工具，所以在数据类型的映射、索引、默认值这些元信息上，支持得比较粗糙，导出 SQL 之后经常需要手动调整。第二，它的关系连线虽然能自动生成，但布局算法很基础，表一多就乱成一锅粥，需要花不少时间手工梳理位置。第三，反向生成功能只支持部分数据库的 JDBC 连接方式，如果数据库比较小众，大概率连不上。

用它最舒服的场景，其实是“快速把已有表结构变成一张能给人讲清楚关系的图”，以及“画一张漂漂亮亮的架构设计文档配图”。它不追求数据库建模的严谨性，追求的是视觉表达的自由度和易分享性。

2.2 WWW SQL Designer：浏览器里的老牌数据库设计器

第二款是 WWW SQL Designer，这是一款非常老牌的纯 Web 数据库设计工具，开源项目，在浏览器里直接跑，不存在安装问题。它的核心理念和 draw.io 完全不同：draw.io 是从空画布开始自由发挥，而 WWW SQL Designer 是让你像操作表格一样，先把数据库的表结构“定义”出来，然后它自动帮你把 ER 图关系画出来。

打开工具之后你会看到三列面板：左边是可用字段类型，中间是表设计区，右边是关系连线区。你要做的就是新建一张表，输入表名，然后往表里添加字段，每个字段选择名称、类型、长度、是否主键、是否可空。定义完两张表之后，再用鼠标在表之间拖一条连线，选择外键关联的目标字段，ER 图的关系就自动生成好了。

这套操作逻辑对初学者特别友好，因为它把“建表”这个动作做得非常直观。你不需要会写 SQL，不需要理解抽象建模理论，只需要知道业务里有哪些数据、这些数据之间有什么联系，就能把模型画出来。画完以后，右上角有生成 SQL 的功能，根据你的选择可以生成 MySQL、PostgreSQL、Oracle 等不同方言的建表语句，直接复制到数据库执行就能建出表来。

但它的缺点也相当明显。界面停留在十年前的 Web 风格，现代审美基本谈不上；多表情况下布局同样很乱，自动调整的功能几乎等于没有；导出的 SQL 质量一般，对于索引、注释、字符集这些细节支持得不够；更重要的是，它的后续维护节奏比较慢，很多浏览器新版下偶尔会出现兼容性小毛病。

虽然有这样那样的问题，但我不否认它是最容易上手的 Web ER 工具之一。对于刚接触数据库课程设计的学生，用它来完成“老师认可、答辩能讲”的 ER 图，性价比非常高。它的学习成本大概五分钟，画出来的效果却接近专业建模工具的七八成，这一点相当难得。

2.3 Mermaid Live Editor：把 ER 图当文档写的代码流方案

第三款是 Mermaid Live Editor，准确说它不是传统的图形化 ER 工具，而是一个通过代码生成图表的在线编辑器。Mermaid 本身就是开源项目，它的理念是“用 Markdown 一样的方式写图表”，你写一段 ER 图的描述文本，它实时渲染成图片，而这段文本天然可以被 VSCode、GitHub、GitLab、Notion 等平台识别。

很多人第一次接触会觉得反直觉：我画个图为什么要写代码？但你真正用过一次就会发现，这套方案对程序员来说简直太优雅了。因为 ER 图的本质是结构化信息，表、字段、主外键、关系，这些都可以用固定的语法表达。用图形界面拖拽来拖拽去反而效率低，而且要微调一个字段名就得用鼠标在图形里找到它，远不如直接编辑一行文本快。

举个例子，学生和课程之间是多对多关系，需要中间表选课记录，用 Mermaid 的 ER 图语法写出来非常简洁。定义好之后，代码就是文档，文档就是代码，完全没有二次维护成本。改动了一个表，重新渲染一下，图就同步更新了。这在文档型团队里是杀手级特性，因为它解决了 ER 图最常见的“画完之后代码改了、图没人更新”的痛点。

Mermaid 的 Live Editor 是 Web 页面，打开就能用，左边写代码右边看图，还支持导出 PNG 和 SVG。目前它的 ER 图支持已经比较完善了，可以定义表、字段、主键、外键、关系基数（一对一、一对多、多对多），也能给关系加 label。对于中小规模的表结构，比如二十张表以内的系统，它基本够用。

它的短板也很直接：渲染样式比较单一，没有那种“精美大图”的感觉；不支持反向从数据库导入，必须手工写定义；关系一复杂，自动布局仍然会打架。所以它最适合的场景是项目 README、技术方案文档、代码仓库里的数据库设计说明，而不是正经的数据库建模交付物。

2.4 额外加餐：SchemaSpy 帮你自动生成数据库文档

除了上面三款能“主动画图”的工具，我还想加一个几乎每个老程序员都应该知道的自动文档工具：SchemaSpy。它同样是开源项目，专门做一件事情——连接你的数据库，然后自动生成一个完整的网页版数据库文档，里面包含所有表的字段信息、索引、约束，以及自动绘制的 ER 关系图。

我上学的时候做课程设计，期末要交一份数据库设计文档，当时就是靠 SchemaSpy 把 MySQL 里的表结构全部导出来，然后加上手写的业务说明，半小时就搞定了一份相当漂亮的文档。工作之后有一次接手一个完全没有文档的二手项目，也是靠它快速搞清楚了二十几张表之间的关联关系，那感觉就像在黑暗中摸到了电灯开关。

SchemaSpy 的使用方式是基于 Java 命令行的，你需要本机装 Java 环境和对应数据库的 JDBC 驱动，然后执行一条命令行语句，它会自动扫描整个 schema 并输出一个静态 HTML 目录。虽然它的交互不算特别新潮，但胜在自动化程度极高，一键生成，所有东西都是现成的。如果你遇到一个数据库表多的老项目，我强烈建议先跑一遍它，会比任何手动画图工具都高效。

3. 实操演示：以“学生选课系统”为例画出完整 ER 图

3.1 先搭一个最简单但完整的表结构

为了让上面的工具对比更有说服力，我们统一用一个非常常见的业务场景来演算：学生选课系统。这个系统在课程设计和毕业设计里出现频率极高，表结构也比较经典，一般至少包含三张核心表：学生表 student、课程表 course、选课表 student_course，其中选课表是学生和课程多对多关系拆出来的中间表，保存选课时间和成绩。

学生表 student 的字段我规划如下：id 作为主键，name 学生姓名，student_no 学号，department 系别，grade 年级。课程表 course 的核心字段有：id 主键，course_no 课程编号，course_name 课程名称，credit 学分，teacher 任课教师。中间表 student_course 则比较简单：student_id 外键指向学生表，course_id 外键指向课程表，选课时间 create_time，成绩 score。在实际数据库里，student_id 和 course_id 可以做成联合主键，确保同一个学生不能重复选同一门课。

三张表的关系是清楚的两对一：选课表里的 student_id 关联学生表的 id，course_id 关联课程表的 id。在教学语义上，一个学生可以选多门课，一门课可以被多个学生选，所以学生到课程是多对多，中间表正是用来拆解这个多对多关系的。

3.2 用 draw.io 从 MySQL 反向生成 ER 图

现在看实际操作。如果你已经有了一张建表语句的文本，最简单的方式是打开 draw.io 网页版，然后走这个路径：菜单 Arrange -> Insert -> Advanced -> SQL。它会弹出一个对话框，下方有两个 Tab，一个是“SQL”直接粘贴，一个是“JDBC”连接数据库。我建议新手先用粘贴 SQL 的方式，因为不受网络和驱动影响，最稳定。

具体的流程是这样的：在 Texts 区粘贴完整的 CREATE TABLE 语句，然后在方言下拉框里选择你用的数据库类型，比如 MySQL，再点 Connect，工具就会解析 SQL 并自动生成表格和连线。这里有一个细节：draw.io 解析的时候，需要你每条建表语句都带清楚 PRIMARY KEY 和 FOREIGN KEY 约束，解析成功率才会高。如果有些外键没有在 SQL 里写，生成的图就不会自动连线，需要你后续手动连。

生成之后你看到的图会比较乱，这是正常的，因为 draw.io 的自动布局算法比较朴素。接下来你需要手动拖动表的位置，把中间表放到两位“父表”的中间下方，把关系线扯顺，给每张表换个颜色区分模块。这个过程虽然麻烦，但也正好是梳理业务关系的好机会，你会一边拖一遍重新审视外键设计是不是合理。

画完图后，你可以导出成 PNG 或 SVG 格式放到论文或文档里。因为 SVG 是矢量格式，放大也不会糊，答辩投影时非常清晰，我一般都会导出 SVG 备份一份，同时导出一张 PNG 方便即时预览。

如果你想要用 JDBC 方式直接连接 MySQL，操作也不复杂。你需要先确认本机能连上数据库，然后在 draw.io 的弹窗中切换 JDBC 模式，填上数据库地址、端口、数据库名、用户名和密码，再点连接。首次连接通常会卡在驱动上，最常见的问题是本机没有对应数据库的 JDBC 驱动包，或者 Java 环境没配置好。后面我会在常见问题里详细说。

3.3 用 Mermaid 手写 ER 图的完整示例

再来看 Mermaid 的方式。下面这段代码就是三张表的 ER 图定义，我直接用文本编辑器写好，粘到 Mermaid Live Editor 就能渲染。

erDiagram student { int id PK varchar student_no varchar name varchar department int grade } course { int id PK varchar course_no varchar course_name int credit varchar teacher } student_course { int id PK int student_id FK int course_id FK datetime create_time int score } student ||--o{ student_course : "has" course ||--o{ student_course : "has"

写完之后，右边立即渲染出一张客户关系非常清晰的 ER 图。你会发现这种方式的维护成本极低，假设我要给课程表增加一个“上课地点 classroom”字段，只需要在代码块里加一行，渲染出来的图就自动更新，完全不需要用鼠标去拉框调线。

这就是我为什么特别推荐每个开发者都应该学一点 Mermaid 的日常表达方式。它不需要你精通，只要有需求了翻一下官方文档就能写。尤其是用 GitHub 做项目管理的人，把这段代码放在 README 的数据库设计小节里，看的人直接就能看到图形，而且永远不会出现“图片过期”的问题，因为图和定义是同一份文本。

3.4 三款工具的横向对比与选型建议

这三款工具都亲自上手用了一轮之后，我整理了一个对比表，方便大家根据自己的场景做选择：

选型建议我直接给结论。如果你要做课程设计、毕设答辩，需要一张“看起来正式”的 ER 图，优先选 draw.io，因为它的视觉自由度最高，能画得又全又好看。如果你几乎是零基础，想在十分钟内把表结构理清楚、拿到一张能交差的图，WWW SQL Designer 最合适，界面虽然丑但功能直白。如果你是在写技术文档、代码仓库，或者你所在团队强调工程化和可维护性，Mermaid 是首选，它可以无缝融入你的文档体系。如果是老项目的库表逆向梳理，那就不要犹豫，直接用 SchemaSpy 一键生成文档，然后再用 draw.io 手动整理成汇报素材。

4. 常见问题与排查技巧实录

4.1 draw.io 连接数据库失败怎么办

这是我在各个交流群里被问得最多的一个问题。卡在“JDBC Connection”或者“加载驱动失败”这一类错误上，基本原因可以归成三类：本机没有安装对应的 JDBC 驱动、驱动版本和数据库版本不匹配、连接字符串的格式写错了。

先解决驱动问题。draw.io 的 SQL 导入功能底层依赖 Java，如果你不是开发环境，可能本机连 Java 环境都没有。我建议你检查系统是否安装了 Java，命令行里输入 java -version 看看是不是有反应。然后需要明白一件事：不同的数据库要下载不同的 JDBC 驱动 jar 包，MySQL 用 mysql-connector-j，PostgreSQL 用 postgresql，Oracle 用 ojdbc。光有驱动还不够，draw.io 通常需要在设置里指定驱动路径，它没法自动从系统里找到。

再说连接字符串。MySQL 的标准写法是 jdbc:mysql://localhost:3306/数据库名?useSSL=false&serverTimezone=Asia/Shanghai，注意 ? 后面的参数不能省，尤其是 serverTimezone 这个参数不写，很多新版驱动都会报时区错误。端口号别填错，默认是 3306，如果你本机改过端口就用你实际的。用户名和密码如果用 root，注意部分 MySQL 新版本默认不允许 root 远程连接，你需要创建一个本地用户或者调整权限策略。

还有一种情况是防火墙。如果你连的是远程数据库服务器的 JDBC 端口，先确认服务器防火墙放行了对应端口。这类问题排查起来很烦，我通常的套路是先在本机命令行用 telnet 测试一下端口通不通，比如 telnet 127.0.0.1 3306，通了再去检查驱动和字符串，这样能快速缩小范围。

4.2 Mermaid 中文不显示或关系画不出来

Mermaid 用起来的时候，最常见的坑有两个：一个是中文标签显示成乱码或者干脆不显示，另一个是关系基数语法写错导致渲染报错。

中文问题多半是浏览器渲染字体的原因，在 Live Editor 里可以手动切一下主题或者更新渲染字体，但更靠谱的做法是避免在实体名里使用中文，把中文放进属性注释或者关系 label 里。不过我也遇到过极端情况，关系 label 里的中文在导出 PNG 时会变成一个一个方框，这个基本无解，建议关系 label 用英文或者拼音，字段注释放到正文说明里。

关系画不出来的问题，绝大多数是语法不匹配。Mermaid 的 ER 图关系语法是 实体A 关系符号 实体B，其中关系符号是像 ||--o{ 这样组合出来的，左侧符号代表左实体的基数，右侧符号代表右实体的基数。新手最容易把符号写反，或者漏了中间的 --，导致解析失败。还有一个高频坑是实体的名字里带了空格，比如 Student Course 如果不加引号，Mermaid 会把它当成两个实体，这时候要写成 "Student Course"。

我建议新手写的每段 Mermaid 代码都先在 Live Editor 上跑通再贴进仓库，因为有些旧版渲染器对语法的宽容度不够。另外 Mermaid 对字段名中的某些符号也不是全部支持，比如字段名带点号、带括号就很容易出问题，一个稳妥的方法是字段名尽量用简单无符号的命名风格。

4.3 导出 SQL 与命名不规范的问题

WWW SQL Designer 这类“先画图再导 SQL”的工具，最让人头疼的就是导出的 SQL 不够精致。我遇到过几次，生成出来的表没有显式指定字符集和排序规则，中文插入进去就是乱码；还有主键虽然标了，但某些方言下自增属性没加上，导致插入数据时主键冲突。

这种情况不要指望工具全自动解决，正确姿势是把它生成的 SQL 当草稿，执行之前手工补充字符集、索引和注释。比如 MySQL 里每次建表我基本会在最后加 ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci，这些细节才是生产环境能跑得稳的关键。

命名不规范的问题更值得单独提醒。很多工具在反向生成或正向转换时，会把字段名里的下划线处理得五花八门，或者把驼峰命名的字段拆得离谱。我的建议是：字段名统一使用小写加下划线，所有主外键字段的类型必须严格对齐，否则 ER 图画得再漂亮，联表查询时也是灾难。一张 ER 图真正值钱的地方，不是线画得直不直，而是背后的字段设计经不经得起推敲。

4.4 我的实战组合建议

工具从来不是非此即彼的关系，真正高效的流程往往是组合拳。我自己现在固定下来的工作流是：先用 SchemaSpy 把老项目的现有库表结构全部导出来，搞清楚全貌；然后用 draw.io 把核心表和关键关系重新画一遍，用于对外汇报和文档配图；最后在项目 README 里用 Mermaid 放一段可维护的 ER 图定义，确保后续代码变更时图能跟着文档走。

如果是全新项目，我会直接从 Mermaid 开始，先在文本层面把表定义和关系写清楚，跑通了再衍生到具体建表语句。这样可以避免一开始就陷入绘图的细节调整里，也方便和同事做代码评审。等模型稳定了，再抽时间用 draw.io 出一张精美大图作为正式交付物。

说到底，ER 图这个工具是设计阶段的辅助，不是目的本身。我们真正关心的是表结构对不对、关系表达准不准、后续开发能不能顺畅落地。选什么工具，看你当下最需要解决什么问题：要快速理清关系选最容易上手的，要长期维护选能进文档的，要汇报好看选能自由编排的。不用追求所谓“最强大工具”，能用顺手并且坚持用下去，比什么都强。

我个人到现在还是会在每个新项目开始前一天，先花半小时把数据库的大致模型画出来。这个习惯帮我避免了很多返工，也让团队里每个人对数据结构的理解保持一致。画图这个动作本身，其实就是强迫你把业务逻辑想清楚的最佳方式。希望这篇内容对你选工具、画 ER 图有一些实际帮助，也欢迎你在用的过程中遇到有意思的工具坑来找我交流。