开源Web端ER图设计工具对比：从SQL到可视化建模的实战选型

前阵子接手一个老系统重构，第一件事不是看代码，而是把数据库表关系理清楚。我习惯用 ER 图做梳理，但当时手边没有一个 Web 端可用的开源数据库 ER 图设计工具——Navicat 的逆向工程图丑不说，导出的图片还没法让同事在线评注。搜了一圈，真正能满足“开源、Web 端、能画 ER 图”这三个条件的工具不多，最后我留下了三款：老牌可视化工具 WWW SQL Designer，通用绘图神器 draw.io（也就是 diagrams.net），以及适合写进文档的 Mermaid erDiagram。这篇文章不打算做那种“工具清单搬运”，我想把我实际部署、实际画图、实际踩坑的过程都讲一遍，顺便给出可以直接照抄的选型建议。

1. 为什么我不用桌面客户端，也要在 Web 里画 ER 图

先说清楚一个前提：我并不是排斥桌面客户端。DBeaver、DataGrip、Navicat 我都用过，逆向数据库表结构的能力都很强，但如果目标是“让团队一起评审 ER 图”，桌面客户端的体验就有点难受了。

1.1 桌面客户端在协作场景下的三宗罪

第一，分发给别人很麻烦。你要么导出 PNG，要么截图丢到群里，看的人只能“看”，不能自己拖动、隐藏、缩放；一旦评审会上提出“订单表和支付表之间其实还有一个中间表”，你又得切回客户端改完再导一次。第二，每个人的环境不一样。有人 Windows，有人 macOS，有人 Linux，装的数据库客户端版本还不一致；就算大家都有 DBeaver，各自连库的配置、驱动、插件也经常对不上，沟通成本全耗在环境问题上了。第三，保存的文件格式不通用。很多客户端导出的 ER 图文件只能在自家软件里打开，离开那个软件，这些成果就是一张死图。

所以我定了一个原则：只要不是必须连生产库做交互式实时分析，ER 图设计这个动作尽量放到 Web 端去完成，最好还需要满足几个硬指标。

1.2 我看重开源 ER 图工具的四个硬指标

我筛选工具时只盯四件事。

第一，必须开源。 ER 图本质上是团队的知识资产，我不希望它被某个 SaaS 平台锁死。今天这个在线工具还能用，明天突然改收费策略，我的数据库设计文档就跟着遭殃。开源至少保证代码在本地，最坏情况也能自己维护。

第二，必须能在浏览器里跑。部署到公司内网也好，打开官方在线版本也好，只要不需要每个使用者安装客户端，协作门槛就低一大截。

第三，必须支持 SQL 的导入或导出。画 ER 图不是最终目的，最终目的是把表结构落成建表 DDL，或者反过来把现存数据库的 DDL 变成大家可以讨论的图形。如果一个工具只能画图，不能和 SQL 互通，那它就只是一个高级白板，价值大打折扣。

第四，保存格式要尽量通用。XML、纯文本、Markdown 或者 SVG 都可以，只要能进 Git，能 diff，能被后续工具继续加工。我不接受“导出之后没法二次编辑”的单向交付。

1.3 筛完一圈后的结论

说实话，同时满足这四点的“专业 ER 图设计工具”并不像想象中那么多。很多打着“在线数据库设计器”旗号的网站是闭源 SaaS，免费版还有表数量限制；不少开源项目又只支持桌面端，不能 Web 访问。最后我选定的三款各有侧重：WWW SQL Designer 走的是经典可视化路线，draw.io 走的是通用绘图路线，Mermaid erDiagram 走的是代码化路线。下面逐个讲。

2. WWW SQL Designer：老牌纯 Web 可视化建模器

WWW SQL Designer 是一个有点年头的项目，作者是 Ondřej Žára，源码在 GitHub 上可以找到。它的形态比较古典：前端 JavaScript 画布，后端 PHP 负责保存和加载 XML，打开浏览器就能用，不需要安装任何数据库客户端。

我第一次用它的感受是“简单到几乎不用学”。没有账号体系，没有项目列表，打开就是一个空白画布，左边一排工具按钮，像极了十几年前的网页设计器。

2.1 五分钟把服务跑起来

因为项目是纯 PHP 的，跑起来非常轻量。如果你本机装了 PHP，可以这样启动：

git clone https://github.com/ondras/wwwsqldesigner.git cd wwwsqldesigner php -S 127.0.0.1:8080 -t .

浏览器访问http://127.0.0.1:8080就能看到界面。如果没装 PHP，用 XAMPP、MAMP、宝塔这类集成环境也可以，原理都是把它放到 Web 服务器的根目录下。

有一点要提前注意：它有一个“保存到服务器”的功能，需要 PHP 对配置的保存目录有写权限。如果文件权限不够，保存时会报错，但这不影响你把设计结果导出为本地 XML 文件。我的建议是第一次用的时候就先试一次“导出到本地”，确认浏览器下载正常，再考虑要不要配置服务端保存。

2.2 从空白画布到一张可执行的建表 SQL

WWW SQL Designer 的核心操作路径我拆成四步。

第一步，新建数据库。画布上右键或者点工具栏里的“Create table”，会拖出一个表对象，双击表头可以修改表名。第二步，双击表主体进入字段编辑界面，逐行添加字段。字段名、类型、长度、默认值，以及是否为主键（PK）、是否自动递增（AUTO_INCREMENT）都在这里设置。第三步，用工具栏里的“Relation”工具，从一个表的主键字段拖到另一个表的关联字段，它会自动生成连线，并弹出关系选项。第四步，点工具栏里的“Export SQL”，选择目标数据库类型，就能拿到建表 DDL。

下面是我随手画一个“用户-订单”模型后导出的简化结果：

CREATE TABLE `customer` ( `customer_id` int NOT NULL AUTO_INCREMENT, `name` varchar(100) DEFAULT NULL, PRIMARY KEY (`customer_id`) ); CREATE TABLE `order` ( `order_id` int NOT NULL AUTO_INCREMENT, `customer_id` int DEFAULT NULL, PRIMARY KEY (`order_id`) ); ALTER TABLE `order` ADD FOREIGN KEY (customer_id) REFERENCES `customer` (customer_id);

它能直接拿到 MySQL 里执行，省去手工建模的不少体力活。

2.3 用下来要注意的四个坑

第一，字段类型集合是固定的。界面下拉框里只有 MySQL、PostgreSQL、Oracle 等几种常见类型，如果你用到了比较偏门的自定义类型，需要手动改导出后的 SQL，或者去改源码里的类型定义。第二，导入 SQL 的能力比较“老实”。它可以识别标准 CREATE TABLE 和 ALTER TABLE 外键语句，但遇到复杂的存储过程、触发器、分区表定义，基本会忽略或报错。所以它更适合“从模型生成 SQL”，不太适合“从老库逆向成精美模型”。第三，画布在表数量超过三四十张后会明显卡顿。它不是为超大规模数据库设计的，做小型业务系统或者子模块建模很顺手，做全企业级上千张表的设计会很难受。第四，界面很朴素，没有现代工具的暗色主题、自动布局、多人协同；如果你追求视觉精美，它的默认输出确实不够好看。

不过它有一个桌面工具比不了的优势：整站就是一个 PHP 项目，丢到内网服务器就能用，数据完全在自己的掌控中。适合团队内部快速建模，不需要把业务表结构泄露给第三方平台。

3. draw.io / diagrams.net：不是专用 ER 工具，但能做出最漂亮的交付图

如果非要让我给“ER 图”选一个所有人都能打开的 Web 工具，我会毫不犹豫选 draw.io。这个项目在 GitHub 上叫 jgraph/drawio，开源协议是 Apache 2.0，官方在线版 diagrams.net 免费使用，同时也可以下载源码自托管。你打开网页就是画布，不需要注册，画完的文件可以存成本地.drawio文件，也可以直接存到 GitHub、GitLab、OneDrive 这些地方。

很多人觉得 draw.io 只是通用绘图工具，画架构图、流程图用的，和数据库 ER 图没什么关系。这其实低估了它。它自带数据库实体关系图的模板和形状库，更重要的是它内置了一个“从 SQL DDL 生成 ER 图”的能力，直接把建表语句变成图形。

3.1 用 DDL 自动生成实体关系图

我通常的做法是先从数据库里把表结构的 DDL 导出来，然后粘贴到 draw.io 里自动生成。不同版本菜单路径略有差异，英文版一般在Arrange -> Insert -> Advanced -> From SQL，中文版在“排列 -> 插入 -> 高级 -> 来自 SQL”附近。如果你找不到，直接在菜单栏搜索 “SQL” 会更稳妥。

我测试过这样一个简单的 DDL：

CREATE TABLE students ( id INT PRIMARY KEY, name VARCHAR(100) ); CREATE TABLE courses ( id INT PRIMARY KEY, title VARCHAR(100) ); CREATE TABLE student_courses ( student_id INT, course_id INT, PRIMARY KEY (student_id, course_id), FOREIGN KEY (student_id) REFERENCES students(id), FOREIGN KEY (course_id) REFERENCES courses(id) );

draw.io 会识别出三张表、三个主键字段、两个外键关系，并自动画出三张带字段列表的数据表矩形以及它们之间的关系线。生成后你可以在画布里继续拖动调整位置，改变关系线颜色、增加标签、添加容器分组。

3.2 让 ER 图从“能看”到“能评审”

自动生成的图一开始往往很乱，关系线交叉、表位置重叠，直接发给别人看会留下“很不专业”的印象。我总结了一套整理流程。

先用容器按业务模块分组。比如把用户中心相关的表放进一个泳道或矩形框里，订单中心放进另一个，这样评审时能一眼看清边界。再给关系线补上基数标签。draw.io 默认生成的连线只有一条线，我在连线上双击，标上1、0..*、1..*这些关系说明，必要时加一行文字解释“这条外键代表什么业务含义”。然后给表加颜色区分核心表、日志表、字典表：核心表用暖色，字典表用冷色，日志表用灰色。最后加一个图例，说明颜色、线型以及主外键图标的含义。

导出的时候我会同时输出两份：一份可编辑的.drawioXML 文件，放进 Git 仓库，方便以后修改和对比版本；另一份 SVG 或 PNG，用于写周报、评审文档和对外分享。SVG 还有一个好处，是可以让前端同事直接放到内部知识库里，还能保持清晰度。

3.3 有几件事必须提前知道

draw.io 虽然能生成 ER 图，但它并不是数据库建模工具。它生成的表和关系线只是一些绘图对象，不具备模型语义；你在画布里改了一个字段名，不会同步回 SQL；把一张表删掉，也不会帮你生成相应的 DROP 语句。它不直连数据库，官方在线版默认没有“连上 MySQL 自动反向生成表结构”的功能。所以我的定位很明确：draw.io 负责“画得漂亮”和“评审好看”，不负责“建模严谨”。

如果你要的是：打开工具、连上数据库、自动出来全套 ER 图，然后还能从模型直接改表结构并同步回生产库，那 draw.io 不合适，你该用专业的数据库建模客户端。

4. Mermaid erDiagram：把 ER 图写进代码仓库的最佳选择

前两款工具都是图形化操作，Mermaid 走的完全是另一条路：用纯文本描述实体和关系，然后让工具渲染成图。Mermaid 本身是开源的，官方在线编辑器 mermaid.live 可以在浏览器里直接预览，所以它也满足“Web 端可用”这个条件。我第一次用 Mermaid 画 ER 图是在写技术方案文档的时候，突然想画张表结构图，又不想切去截图，就在 Markdown 里直接写了一段 erDiagram，刷新页面后图就出来了，当时就觉得这个思路特别适合程序员。

4.1 为什么我建议用文本画 ER 图

文本最直接的好处是能进 Git。字段调整、关系变化，别人在 Pull Request 里看到的是一行一行的 diff，而不是一张模糊的图片截图；老同事走一遍 code review，新旧 ER 图哪里变了就一目了然。另一个好处是不再需要专门的绘图软件，只要有一个能渲染 Mermaid 的环境就行：GitHub Markdown 支持、Notion 支持、各种静态站点生成器也支持。对于以文档驱动开发的技术团队来说，这套工作流比“画图软件导图贴文档”要顺畅得多。

4.2 erDiagram 语法入门

Mermaid 的 ER 图语法分两部分：实体定义和关系定义。关系写在最前面，实体块放在后面。以“用户-订单-商品”为例：

erDiagram customer ||--o{ order : places order ||--|{ order_item : contains order_item }o--|| product : includes customer { int customer_id PK string name } order { int order_id PK int customer_id FK datetime created_at } order_item { int order_item_id PK int order_id FK int product_id FK int quantity } product { int product_id PK string sku decimal price }

这段代码渲染出来后，能看到四张实体表，每个字段前面是类型，后面可以标PK或FK，表之间会自动生成连线。语法非常简单，没有图形工具的前置学习成本，照着已有 DDL 就能改出来。

4.3 关系基数：搞清楚那串符号

刚接触的人最容易在关系符号上懵掉。Mermaid 的关系线两侧各有两个字符，左边描述“左侧实体的基数”，右边描述“右侧实体的基数”。

常见的符号如下：

所以customer ||--o{ order的意思是：一个客户可以有零个或多个订单，而每个订单有且仅有一个客户。写关系线时，最重要的是分清主体和从体。把||放在“一”的那一侧，把o{或|{放在“多”的那一侧，顺序颠倒会导致关系语义完全相反。

4.4 在 Web 预览之外，还能把渲染接入 CI

Mermaid Live Editor 适合临时画图、调试语法。如果希望每次代码合并后自动生成最新的 ER 图文件，可以配合官方的 mermaid-cli 使用。我在一个内部项目里写过这样的命令：

npx -y @mermaid-js/mermaid-cli -i schema.mmd -o schema.svg

这里schema.mmd是存放 ER 图文本的文件，schema.svg是渲染出的图片。把这个命令放到 CI 脚本里，只要 schema.mmd 有更新，SVG 就会自动重新生成。文档永远和代码同步，不需要人手去“记得导图”。

4.5 它的短板也很明显

Mermaid 不是数据库建模器，不支持反向导入数据库，也不支持从图形拖拽生成 SQL。它的定位更像是一种“表达语言”，适合把已经定好的表结构画成文档，不适合用来做设计探索。另外，cypher 复杂关系多了以后，文本里的关系线很容易读晕，不如图形工具直观。所以我的使用习惯是：定稿后的 ER 展示用 Mermaid，设计阶段的思考和讨论，还是回图形工具更舒服。

5. 三款工具横向对比与选型建议

三款工具各有各的脾气，放在一起对比会清晰很多。下面是我自己的评估表，不追求面面俱到，只写实际用下来影响选择的关键项。

选型建议我按角色拆开说：

如果你是后端开发，主要精力在写业务代码，只希望文档里有一张能跟着代码走的 ER 图，优先选 Mermaid。它最轻，改起来也顺手。

如果你要和产品、测试、甲方过方案，需要对着一张“看起来专业”的图做评审，draw.io 是首选。它最擅长把复杂关系整理成清晰美观的模块图。

如果你正在做新系统的数据库建模，想快速画表、拉关系，顺手把建表 SQL 生成出来，那 WWW SQL Designer 更对口，它是三款里唯一一个把模型和 SQL 真正联动起来的工具。

如果你的团队有内网部署需求，不想让表结构出现在任何外部平台，WWW SQL Designer 和 draw.io 都能自托管，Mermaid 则完全不存在数据出网的问题，因为它就是一段文本。

6. 我的真实选型经验：什么情况下别迷信工具

工具讲到最后，还是得回到实际工作流。我个人踩过不少次“为了用工具而用工具”的坑，这里说点真话。

6.1 ER 图的核心不是工具，而是关系边界

早年间我很热衷找好用的建模工具，后来发现很多项目的 ER 图画不好，不是工具不行，而是压根没把表之间的关系想清楚。比如订单表和用户表到底是1:N还是N:M，中间表要不要冗余，状态字段放哪张表，这些问题靠换工具解决不了。画出来的图丑一点、乱一点，只要关系清楚，评审会上大家还是能看懂；反过来，工具再贵再智能，表的边界本身就是糊涂的，ER 图只会更难看。

6.2 我最后固定下来的工作流

现在我处理一个模块时，通常是这样组合的：先用 SQL 或者 WWW SQL Designer 快速把核心表和字段列出来，跑通主外键关系；等到结构稳定了，把 DDL 丢到 draw.io 里整理成评审用的版本，模块边界、基数和图例都标清楚；评审通过后，再给这个 ER 模型维护一份 Mermaid 文本，放到项目文档里，作为长期可追溯的版本记录。

这个流程的好处是，一份模型源，两个展示出口。模型源是真实的 SQL DDL，draw.io 服务于阶段性评审，Mermaid 服务于日常文档阅读。不会出现“画图画得很开心，但建表 SQL 居然没人维护”的尴尬局面。

6.3 一个小建议

如果你也在选 Web 端可用的开源数据库 ER 图设计工具，我建议先别急着下载全家桶，按你的实际使用场景在这三款里选一个，拿当前项目里最复杂的一张表结构做试用，重点关注三件事：能不能准确导入或导出 SQL，改完关系后别人能不能轻松评审，生成的文件能不能长期保存并进入版本管理。跑通了再决定，不然再好看的工具图也救不了混乱的表结构。