先说你可能遇到过的场景项目里几十张表光看建表 SQL 根本拼不出完整结构想拉一张 ER 图理理关系手边要么是没装客户端工具要么是装好了但 License 到期了要么画到一半发现连不上共享文档同事问你要最新版还得重来一遍。后来我把主力工具换成了 Web 端可用的开源 ER 图设计工具浏览器打开就画画完导出 SVG 或 PNG 直接进文档甚至把图嵌到团队 Wiki 里自动渲染整套流程省事很多。这次就分享 3 款我实际测下来比较能打的diagrams.netdraw.io、Mermaid、DBML dbdiagram.io。后端开发、DBA、技术文档维护都能从中选到适合自己工作流的一款。1. 为什么我盯上了 Web 端 开源的 ER 图工具1.1 本地客户端工具到底卡在哪早年间我画 ER 图主要靠桌面端工具比如 MySQL Workbench、Navicat、Visio 这些。它们不是不能用而是有几个绕不开的痛点。第一是环境割裂。公司电脑、家里电脑、客户现场环境每台机器都要装一遍装的时候还得处理版本、驱动、系统兼容光是环境问题就能磨掉大半天。第二是分享困难。本地客户端画的图要么存在个人电脑里要么上传到云盘再下载中途版本一变链接就失效了。多人协作时你改一版、我改一版最后对不齐的情况太常见。第三是成本问题。Visio 这类商业软件 License 不便宜团队采购还得走流程开源桌面工具虽然免费但 ER 图功能往往绑定在完整数据库管理套件里启动重、操作繁琐。真正让我下决心切到 Web 端是有一次给客户梳理数据库关系。现场没有预装任何建模工具又不能随便联网装软件我打开浏览器用在线版 diagrams.net 快速把核心表结构画完导出 PDF 发给客户整个过程不到半小时。从那时起我就意识到Web 端工具的优势不是“能用”而是“随处可用、随取随分享”。1.2 选型时我给自己定了 4 条硬标准市面上 Web 端画图工具有不少但不是都适合做 ER 图更不是都开源。我选型时基本靠 4 条标准过筛子。第一条授权协议和部署方式。所谓开源不能只是“免费试用”我要的是能自己部署、能改、能放进公司内网的方案。Mermaid 是 MIT 协议diagrams.net 是 Apache 2.0这两款都可以放心自托管或嵌入自己的系统。DBML 语言和配套 CLI 工具也是开源的这点在 2.3 节我会把边界讲清楚。第二条是否能跟现有工作流打通。ER 图不是画完就结束的产物它要么进设计文档要么进代码仓库要么直接生成建表 SQL。所以工具必须方便导出 PNG、SVG、PDF最好还能和 Markdown、Wiki、代码仓库集成。Mermaid 在这方面优势明显GitHub、GitLab、VitePress 等平台原生支持渲染diagrams.net 可以嵌入 Nextcloud、Confluence也能导出 XML 文件进 Git。第三条从表结构生成 ER 图的成本。老项目很少有现成的模型图最理想的是从已有数据库或建表 SQL 自动生成初稿。diagrams.net 可以通过 CSV 批量生成表格形状DBML 可以从 SQL 转成模型定义Mermaid 需要手写代码但工作量可控。纯手工从零摆形状只在表数量少时划算。第四条学习成本。团队协作时工具学习成本太高推行阻力就大。Mermaid 要会写语法DBML 也要写定义diagrams.net 则是图形化拖拽基本没有门槛。三种工具覆盖三种人群后面我会说怎么选。2. 三款工具逐个拆适合谁、能干什么2.1 diagrams.netdraw.io浏览器里的万能画布diagrams.net 就是大家常说的 draw.io它是目前我用得最频繁的 Web 开源绘图工具。项目托管在 GitHub 上代码开源提供在线版 app.diagrams.net也可以下载离线 HTML 文件直接双击用浏览器打开断网也能画。它本质上是一个通用绘图工具不是专门为 ER 图而生的但它内置了「Entity Relation」模板打开后有一组数据库表形状、关系连线、主键外键样式够用了。而且它最大的优势是生态广可以嵌入 Jira、Confluence、GitHub、VS Code 等平台还可以通过 URL 参数直接把 XML 保存到本地或云端。我个人最常用的做法是在 app.diagrams.net 里画完图把文件导出成 .drawio 格式放在项目仓库的 docs 目录下后续修改直接打开仓库里的文件所有历史版本都能通过 Git 管理。对于纯 ER 图场景它的操作逻辑很直观拖拽表格形状双击添加字段名主键用 PK 标注外键用 FK 标注然后拉一条线连接两表。关系线可以设置成实线、虚线还可以加箭头和标签表达 one-to-many、many-to-many 都没问题。画完导出 SVG 或 PNG放到设计文档里就很清晰。有一个常被忽略但很有用的功能Arrange Insert Advanced From CSV它可以把 CSV 数据批量生成为图形。我的操作是先把表结构整理成 CSV比如一行一张表、一列一个字段然后导入draw.io 会自动生成对应的表格形状再手动拖一拖关系线。这样一来几十张表的框架可以几分钟搭完不用一张张拖。2.2 Mermaid ER 图代码即图表Mermaid 可能很多人第一反应是“给 Markdown 画流程图的那个库”其实它也可以画 ER 图而且是纯代码生成。它的核心思路是“用一段类似文本标记的代码描述结构再渲染成图”适合把图表直接放进文档、Wiki、代码注释和 CI 产物里。Mermaid 采用 MIT 协议完全开源默认支持 GitHub Markdown 渲染。你在仓库里建一个.md文件写入mermaid erDiagram ... 推到 GitHub 上就自动渲染成图。团队里做技术评审、接口文档、数据库设计文档时这个特性很舒服因为图和代码在一个文件里不用来回传图片。它的语法不算复杂核心是三块定义实体表、定义实体的字段、定义实体间关系。字段支持标注主键、外键、类型关系支持一对多、多对多、零或一、零或多等基数表达。相比拖拽式工具它没有可视化编辑界面改位置、调布局要靠算法自动排遇到复杂模型布局可能不够理想但胜在可版本化、可 diff、可自动生成。我个人习惯是新项目的数据库设计文档用 Mermaid 画写完建表 SQL 后同步维护一段 ER 图代码结构改动时图也跟着改PR 里 reviewers 能直接看到变更。对于需要长期维护的文档库来说这种方式比贴静态图片强太多。2.3 DBML dbdiagram.io把数据库结构当代码维护DBMLDatabase Markup Language是一种专门描述数据库结构的开源标记语言语法比 Mermaid 更贴近数据库设计本身。它支持定义表、字段、类型、约束、索引、外键关系还可以描述多对多关系的中间表。dbdiagram.io 是这套生态里的 Web 编辑器支持在线编辑 DBML 代码、自动排版 ER 图、导出图片和 SQL。这里有一点我必须如实讲清楚dbdiagram.io 的在线编辑器本身不是开源仓库真正开源的是 DBML 的语法规范、解析器、CLI 工具链。也就是说如果你想在企业内网完全自建可以直接用 dbml-cli 在命令行把 DBML 转成 SQL、JSON 等格式编辑器部分只是辅助。因为 DBML 的工具链全部开源所以我仍然愿意把它归入“开源数据库设计工具”的范畴来分享。DBML 的核心价值是“结构即代码”。你可以把schema.dbml放在代码仓库里任何一次表结构变更都有 git diff代码评审能看出哪个字段改了、哪个索引删了。结合 dbml2sql 可以把 DBML 直接转换成 MySQL、PostgreSQL、SQL Server 等数据库的建表 SQL真正实现从模型到数据库的一键生成。比手动维护建表 SQL 更不容易出错。dbdiagram.io 作为编辑器体验也很不错。左侧写 DBML右侧实时渲染 ER 图可以拖拽布局、缩放导出 PNG 或 SVG。对不想折腾命令行的团队来说它能把 DBML 的使用门槛降低很多。3. 实操记录从建表到导出 SQL 能跑通吗3.1 用 diagrams.net 从零画一张用户订单模型我拿一个典型的用户订单模型来演示。假设有 users 表和 orders 表一个用户可以有多个订单。打开 app.diagrams.net在模板选择里找到「软件」分类下的「Entity Relation」创建后画布上会出现预设的表格样式和关系线样式。第一步画 users 表。从左侧形状库里拖出表格形状调整单元格数量使其包含四列字段名、类型、约束、说明。填上 user_idPKbigint、namevarchar、emailvarcharunique、created_attimestamp。双击单元格就能编辑文本需要加粗或改颜色就选中单元格后调文字样式。字段较多时用表格形状会比普通矩形方便因为列宽、行高、对齐方式都更像真实表结构。第二步画 orders 表。同样添加 order_idPKbigint、user_idFKbigint、total_amountdecimal、statusvarchar、created_attimestamp。注意把 user_id 标注成 FK 或加注释让看图的人一眼分清主外键。第三步连接关系。从 users 表拉到 orders 表选择关系线。为表示“一个用户有多个订单”把线的两端设置成不同样式靠近 users 端是单竖线靠近 orders 端是多个圆圈或三叉线。具体操作是选中连线后在线条样式中选择“实体关系”箭头样式。画完后全选导出File Export as PNG缩放建议选 200%保证文字清晰。如果要把图嵌入项目文档导出 SVG 更好放大不糊。这个流程适合表数量不多且需要人工调整布局的场景。如果不喜欢手动一行行加字段可以把每张表的字段整理成 CSV用Arrange Insert Advanced From CSV批量生成所有表格形状再统一调整位置。我试过用这个方式处理过一张有 20 多张表的订单系统模型导入拉关系线大概半小时就能出初稿比一个个拖快得多。3.2 用 Mermaid 在项目文档里生成动态 ER 图Mermaid 的使用方式更偏开发。先在文档里定义好模型比如这样erDiagram USERS ||--o{ ORDERS : places USERS { bigint user_id PK varchar name varchar email timestamp created_at } ORDERS { bigint order_id PK bigint user_id FK decimal total_amount varchar status timestamp created_at }把这段代码放进支持 Mermaid 渲染的 Markdown 环境比如 GitHub、GitLab、VitePress、Docsify就成了实时渲染的 ER 图。线上评审时同事看到的不是一张死图片而是跟随代码更新的动态图。要导出为图片文件可以安装 mermaid-clinpm install -g mermaid-js/mermaid-cli mmdc -i schema.mmd -o schema.svg mmdc -i schema.mmd -o schema.png -b white我踩过的一个坑是中文显示问题。默认情况下Mermaid 生成图片中文可能显示为乱码或者方框因为底层渲染依赖本机字体。解决办法是在 mmdc 命令里指定字体配置或者在使用在线编辑器时把主题配置改成中文字体。简单做法是创建一个mermaid.config.json{ fontFamily: Microsoft YaHei, PingFang SC, sans-serif }然后在命令里加上-c mermaid.config.json导出的 PNG 和 SVG 中文就比较正常了。这个坑在文档里不写清楚新手第一次生成图片很容易懵。3.3 用 DBML 定义模型并自动导出 SQLDBML 的操作是另一条路线先写模型定义再生成图或 SQL。同样是用户订单模型schema.dbml内容如下Table users { user_id bigint [pk, increment] name varchar(255) [not null] email varchar(255) [unique] created_at timestamp } Table orders { order_id bigint [pk, increment] user_id bigint [ref: users.user_id] total_amount decimal(10,2) status varchar(20) created_at timestamp }写完文件后用 DBML CLI 可以直接生成 MySQL 建表语句npm install -g dbml/cli dbml2sql schema.dbml --mysql -o schema.sql生成的内容会包含 CREATE TABLE 语句、主键、外键约束和唯一索引比自己手写 SQL 更规范。如果只是想看 ER 图把schema.dbml内容粘贴到 dbdiagram.io 左侧右侧会实时渲染出表结构图和关系线。导出的 PNG/SVG 可以直接放进设计评审文档。这套流程最爽的地方在团队协作。schema.dbml进入 Git 仓库后每次改字段都是一次 commit代码评审时能清楚看到“哪个表改了哪些列”。我自己的做法是配合 GitHub Actions在 main 分支更新时自动执行dbml2sql把生成的 SQL 作为 artifact 发布这样整个设计的变更链路都是可追溯的。4. 常见问题与排查思路4.1 三款工具各自的小坑diagrams.net 最常见的问题是导出图片时中文字体发虚或样式错乱。解决方法是导出前把画布缩放调高导出时选择更大的缩放比例同时设置成“不透明背景”的 PNG。如果是要放在深色背景的文档里记得在画布背景设置中改成白色否则透明背景导出后叠加在深色页面上看不清。Mermaid 的坑主要在中文渲染和复杂布局。中文问题刚才已经说过了布局方面表数量很多、关系很复杂时Mermaid 自动排版可能会出现连线交叉、实体重叠的情况。这时候没有太多技巧建议手动调整实体顺序或者在实体名上加注释来影响排序权重也可以接受“图不完全完美”的现状毕竟它的定位是文档自动化而非出版级排版。DBML 和 dbdiagram.io 的坑主要在在线编辑器的稳定性和导出细节。dbdiagram.io 免费版在处理大模型时会有明显卡顿字段超过 200 个以后拖拽和缩放都不太流畅。另外在线编辑器如果不注册账号过一段时间内容有丢失风险。我的建议是始终以本地schema.dbml文件为唯一事实来源在线编辑器只用于预览和导出不承担存储职责。DBML 文件本身是纯文本必须纳入 Git 管理。4.2 怎么选能力对照表维度diagrams.netMermaidDBML dbdiagram.io开源协议Apache 2.0MITDBML 规范与 CLI 开源图形化拖拽支持不支持在线编辑器支持代码驱动弱点强很强生成 SQL DDL不支持不支持支持多数据库嵌入文档/Wiki导出图片后嵌入或 iframe 嵌入原生于 Markdown/Wiki 渲染导出图片后嵌入自托管/离线支持支持CLI 自用编辑器在线学习成本低中中高适合场景通用画图、方案图、演示开发者文档、README、Wiki新项目设计、结构即代码、CI 集成这三款工具不是替代关系而是不同场景的互补。给老板汇报、给客户讲表结构diagrams.net 最稳因为它可以精细调整排版做出好看的图开发团队沉淀文档Mermaid 最顺手因为它在 GitHub 里一键渲染新项目要快速定模型并最终落库DBML 最合适因为可以从模型直接生成 DDL。5. 我的最终选择建议做了几年数据库设计和架构梳理我现在的工作流是分工使用正式交付文档里的 ER 图几乎都用 diagrams.net 画因为它能精确控制版式画完导出高清图项目仓库里的数据库设计文档主推 Mermaid因为它和 Markdown 结合得太好代码评审时可以直接看变更新项目启动阶段设计表结构我会先用 DBML 快速定义模型生成 SQL 后在数据库里验证确定无误再补 Mermaid 文档和 diagrams.net 的归档图。这个组合本质上是在“可维护性”和“表达效果”之间取平衡。ER 图这个事真正重要的不是工具本身有多炫而是整个团队能不能用一套可持续的方式维护数据库结构。代码能进 Git 的尽量进 Git能自动生成的不要手工画必须人工精修的再交给图形工具处理。希望你也能从这三款工具里找到适合自己团队节奏的那一款别再让 ER 图变成一次画完就失联的一次性文件。