说实话我最早画 ER 图用的是 Navicat 自带的模型工具后来也试过 MySQL Workbench。工具本身不差但有一个绕不开的问题它是桌面客户端。团队里要一起评审、交接、看文档的时候电脑上没装的同学就只能看截图截图一多就没法改了。所以后来我给自己定了个规矩除非必须否则 ER 图一律用 Web 端可用的方案。折腾一圈之后手边留下的就是这三款draw.io、Mermaid、CloudBeaver都是开源或者底层开源的浏览器里就能搞定。这篇文章就把它们的使用场景、操作步骤和坑一次性说清楚。1. 为什么我开始把 ER 图从桌面客户端搬到浏览器1.1 客户端建模工具的三大尴尬不是说我否定桌面工具而是桌面工具在实际协作流程里暴露的问题太具体了。第一是安装成本Navicat 要授权MySQL Workbench 版本一多界面就乱DBeaver 对普通同事来说又太工程师化。每次团队来了新人光装工具、配连接、对齐版本就能耗掉半天。第二是协作成本ER 图画完以后存成.mwb或者.navicat-model这种文件其他人根本打不开。评审会上大家对着投影仪看会后想自己放大看清字段就变成奢望。第三是环境绑定公司电脑、家里电脑、临时借来的电脑工具装一次要用一周换个机器一切都得重来。Web 端方案把这几个问题一次性解决了。浏览器几乎是所有设备的公共环境打开链接就能看到内容不用安装、不用激活、不用考虑版本兼容。更关键的是Web 端工具导出的文件格式往往更开放比如 draw.io 的文件本质上是 XML可以直接放进 Git 仓库做版本管理。对于团队协作来说这比一个封闭的模型文件实用太多。1.2 浏览器方案真正解决的协作问题很多人觉得 Web 端画 ER 图是退而求其次认为功能一定比桌面端弱。实际用下来我觉得这个判断是错的。对大多数项目来说ER 图的核心价值不是画得漂亮而是关系清楚、能评审、能改、能复用。Web 端工具在这几个维度上反而更占优势。以最典型的场景为例需求评审。以前画完 ER 图我要把它导出成图片贴到文档里然后和产品、前端、测试在评论里反复讨论。前端说订单状态字段我需要多一个枚举值测试说用户和订单的关系是一对多还是多对多每改一次我就得重新截图、重新上传。用 Web 端方案之后我直接把 draw.io 的编辑链接发到群里或者把 Mermaid 代码嵌到文档里谁都能实时看谁都能提意见改完以后大家看到的是同一份最新版。这个体验上的差距是功能是否够用没法衡量的。1.3 三类使用场景决定你该选哪款我后来发现选工具不能只看功能列表得先搞清楚自己属于哪类用法。我自己把 ER 图的需求分成三种。第一种是从零设计新表结构。这时需要的是白板式的自由绘制能力可以把实体、属性、外键关系从无到有地摆出来反复调整位置。这类场景最适合交互式的可视化工具draw.io 就是主力。第二种是代码化表达。很多技术方案评审并不需要一张精准到像素的图而是需要可复现、可 diff、可内嵌到文档的模型描述。这时候用 DSL领域特定语言写 ER 图比拖拽高效得多Mermaid 和它的关系符号就是为这种场景准备的。第三种是逆向梳理已有数据库。老项目或者同事留下的系统表结构散落在几十张 DDL 里光看字段很难建立起关系网。这时候最好的方式是让工具直接连上数据库自动识别外键并生成 ER 图CloudBeaver 干的就是这个活。这三类需求不是互斥的一个项目里很可能三个阶段都要走一遍。理解这一点三款工具的定位就不会搞混了。2. 第一款draw.iodiagrams.net——最稳妥的 Web 画布式 ER 图设计2.1 为什么先提它开源背景和兼容性draw.io 现在的主域名是 diagrams.net不过大家还是更习惯叫它 draw.io。它是一款 Apache 2.0 协议的开源绘图工具GitHub 上仓库一直在活跃维护。最关键的一点是它不算专门的数据库设计工具而是一个通用绘图平台但它的模板库里包含了非常完整的 ER 图、数据库关系图、UML 类图等模板拿来画 ER 图完全不违和。我推荐它的第一理由是可访问性拉满。它有在线版打开浏览器直接进也有桌面版支持 Windows、macOS、Linux而且桌面版的离线体验和在线版几乎一致还可以自托管到自己的服务器上。第二理由是文件格式开放它保存的文件本质上是 XML可以用文本编辑器打开可以放 Git 仓库可以嵌入到 Confluence、Notion 这些文档平台。对搞技术的人来说这种文件可控感非常重要。2.2 用 draw.io 从零画数据库 ER 图的实操过程具体操作步骤看起来简单但有几个细节新手很容易忽略。打开 draw.io 之后第一步建议选择软件 - 实体关系模板而不是直接用空白画布。这个模板自带了实体表格和关系连线样式能省掉很多重复的样式调整。画实体时我一般不用默认的矩形而是用左侧图形栏Table分类下的实体形状。这个形状自带“表头 字段行”结构双击就能添加字段。字段命名建议直接按数据库习惯来比如id INT PK、user_name VARCHAR(50)画完图之后可以直接对着建表不用再翻译一遍。关系连线是画 ER 图最核心的环节。draw.io 里连线默认是带箭头的线条但 ER 图需要的是“实体间的关系线”建议选中线之后在右侧样式面板里把线型改成直线并把端点的标记改为空或小圆点这样看起来更像数据库建模工具的画法。在线上加外键说明时可以用文本标签标出1 : N或1 : 1如果字段较多建议直接用FK前缀标记字段行比在连线上写得密密麻麻更清晰。2.3 draw.io 的强项和短板draw.io 最大的强项是万能。我不仅拿它画 ER 图还画架构图、时序图、流程图一个工具覆盖所有。它支持自定义样式、导入导出各种格式包括 SVG、PNG、PDF甚至能导入部分其他工具的文件配合 Git 做版本管理非常舒服。短板也比较明显。第一它不会自动生成 SQL画出来的 ER 图是图不是模型不能一键导出建表语句。第二大图性能会下降当表数量超过三十张关系线一多拖拽和缩放会有明显卡顿。第三它没有真正意义上的模型校验比如你删除一个实体时和它关联的连线不会自动处理需要手动清理。这些都是我在画大项目时踩过的坑所以它更适合做最终交付图而不是建模推演工具。3. 第二款Mermaid Live Editor——用代码写 ER 图最适合放进文档和评审记录3.1 Mermaid 的 ER 图语法入门Mermaid 是 MIT 协议的开源图表工具本质是一个 JavaScript 库但普通人可以通过它的在线编辑器直接使用。它最大的特点是用文本描述图表我经常把它类比成画图的 Markdown。只要你写过 Markdown就能很快上手 Mermaid。它的 ER 图语法非常直观。开头写erDiagram声明这是一张 ER 图然后依次定义实体。每个实体用实体名开头在{}里声明字段。看一个最基础的三表结构erDiagram CUSTOMER }|..|| ORDER : places ORDER ||..|{ ORDER_ITEM : contains ORDER }|..|| PRODUCT : ordered as这个例子定义了客户、订单、订单明细、产品四个实体之间的关系。关系符号我觉得是所有 ER 工具里表达力最强的一套||表示恰好一个}|表示零个或多个o{表示零个或多个可选组合起来就能精确描述业务规则。比如CUSTOMER }|..|| ORDER的意思是一个客户可能有很多订单但一个订单必须归属于一个客户。字段定义在另一个代码块里比如erDiagram USER { int id PK string name string email UK datetime created_at } ORDER { int id PK int user_id FK decimal total_amount datetime order_time } USER ||--o{ ORDER : has这样一套代码就是一张完整的 ER 图。渲染出来以后字段、主键、外键、关系基数、关系名都清清楚楚。3.2 一个完整示例用户、订单、订单明细三张表实际项目里我经常用 Mermaid 快速搭出提案级的 ER 图。举个例子假设要设计一个极简订单模块三张表分别是用户表、订单表、订单明细表erDiagram USER { bigint id PK varchar nickname varchar phone UK tinyint status datetime created_at } ORDER { bigint id PK bigint user_id FK varchar order_no UK decimal total_price datetime paid_at tinyint status } ORDER_ITEM { bigint id PK bigint order_id FK bigint product_id FK int quantity decimal unit_price decimal subtotal } USER ||--o{ ORDER : creates ORDER ||--|{ ORDER_ITEM : contains在 Mermaid Live Editor 里粘贴这段代码右侧会实时渲染出 ER 图。我通常把这段文本直接贴到技术方案文档里团队评审时看到的不仅是图还有这一段准确的模型描述。更重要的是这段文本可以放进 Git 仓库做 diff改了一个字段提交记录里清清楚楚这是任何拖拽式工具都给不了的体验。3.3 Mermaid 适合谁用、不适合谁用Mermaid 特别适合三类人第一类是长期写技术文档的人把 ER 图内嵌到 Markdown、语雀、GitHub、GitLab 里都极其顺滑第二类是喜欢文本即模型的开发者用代码管理图意味着图可以被 review、被 diff、被版本化第三类是快速验证阶段的人画草图、出提案、讨论关系模型比拖拽工具快得多。但它不适合所有人。如果你需要精细控制布局——比如让某个实体出现在画布的绝对位置或者让关系线绕开另一个实体——Mermaid 在这方面几乎无能为力。它的自动布局偶尔也会出现线从奇怪的地方穿过去的情况。另外它不擅长处理超大规模的模型实体超过二十个之后文本代码会变得冗长渲染出来的图也会比较难阅读。所以我把 Mermaid 定位为建模沟通工具而不是最终交付图的制作工具。4. 第三款CloudBeaver——连接真实数据库反向生成 ER 图4.1 CloudBeaver 和 DBeaver 的关系以及为什么它是 Web 端CloudBeaver 是 DBeaver 团队出的 Web 版数据库管理工具开源协议是 Apache 2.0。DBeaver 用户应该很熟悉那个生态CloudBeaver 相当于把 DBeaver 的核心能力搬到了浏览器端。它不是简单的在线 SQL 客户端而是具备完整的数据库对象浏览、SQL 执行、用户权限管理以及对表结构、外键关系的可视化能力。我把它放进这篇推荐的原因很直接它是我见过的从已有数据库反向提取 ER 图最快的开源 Web 方案。不需要导出 DDL、不需要手动整理字段只要配置好数据库连接它就能把表与表之间的外键关系自动识别出来并以图形化方式展示。对于接手老项目的人来说这一步直接节省半天到一天的工作量。4.2 Docker 一键部署 CloudBeaverCloudBeaver 官方的部署方式很多最省事的是 Docker。我贴一下我实际使用过的命令docker run -d --name cloudbeaver \ -p 8978:8978 \ -v /data/cloudbeaver/workspace:/opt/cloudbeaver/workspace \ dbeaver/cloudbeaver:latest启动之后浏览器访问http://localhost:8978第一次进入需要创建管理员账号。之后在界面里点击“创建连接”选择数据库类型填写地址、端口、用户名、密码就能连接上数据库。它支持 MySQL、PostgreSQL、Oracle、SQL Server、SQLite 等主流数据库对于大多数项目来说完全够用。连接成功之后左侧会列出所有数据库和表。右键点击任意表选择“查看 ER 图”CloudBeaver 会基于外键关系自动生成实体关系图。你也可以直接选整个数据库 schema一次展示所有表之间的关系。这个功能在梳理老项目时简直是救命稻草尤其是只有线上库没有文档的情况。4.3 CloudBeaver 能做的和不能做的CloudBeaver 的优势主要集中在这几个方面反向生成 ER 图非常快所有字段、类型、主键、外键信息都来自真实数据库所以准确性有保障支持直接查看表的 DDL 和索引信息方便我判断要不要补索引、补外键它本身也是一个很强的 Web 端 SQL 客户端日常查询、导出数据都能干算是一个附带 ER 图功能的数据库管理平台。但它不是专业建模工具和 Navicat Data Modeler、MySQL Workbench 的模型编辑体验相比还是有差距。在 CloudBeaver 的 ER 图视图中你可以查看关系、可以缩放拖动画布但很难像专业工具那样手动调整实体位置并保存一个精心排版的交付图。它更擅长帮你理解数据库而不是帮你做视觉级的设计稿。另外当数据库本身没有外键约束时CloudBeaver 也没法自动推断关系这时候还是得靠经验人工识别。5. 三款工具搭配组合以及替换 Navicat 建模的心得5.1 工具对比一款一款拆开看定位完全不同工具开源状态Web 可用性核心定位上手难度适合阶段draw.io / diagrams.netApache 2.0在线版、自托管通用可视化绘图含 ER 图模板低最终交付图、手绘设计、团队评审Mermaid Live EditorMIT在线编辑器 文档内嵌代码化 ER 图DSL 驱动低技术方案、版本管理、快速草案CloudBeaverApache 2.0自托管 Web 应用数据库管理 反向 ER 图生成中已有数据库逆向梳理、日常巡检这三款没有谁是全面替代者组合起来才是完整的工具链。draw.io 管最终长什么样Mermaid 管快速迭代和文档同步CloudBeaver 管真相来源——直接看向数据库里实际存在的结构。5.2 我的推荐工作流接老项目时我的固定三步骤可以分享出来。第一步CloudBeaver 先上。连接数据库生成全库 ER 图快速了解总共有哪些表、哪些表之间真正建立了外键关系、哪些表看似有关联实际上没有任何约束。这个阶段的目标不是画图而是建立全局认知。第二步Mermaid 重建模型。把 CloudBeaver 里看到的表关系用 Mermaid 代码整理出来写成一份新的文档。这一步我会顺手做模型治理该补外键的补外键、该拆冗余字段的拆出来、命名不规范的一一标记。因为 Mermaid 是纯文本我可以很清楚地把改动记录提交到 Git后续评审也有迹可循。第三步draw.io 出交付图。当模型调整完毕、各方评审通过后我再把最终结构用 draw.io 精修成一张视觉上舒服的 ER 图导出 PNG 或者 SVG 放进正式文档。之所以不在第一步直接用 draw.io是因为手工排布几十张表太浪费时间等模型稳定下来再画一次到位。这套流程的核心思路是先用自动化工具获得真相再用 DSL 快速推演最后用可视化工具沉淀成果。每一步都用它最擅长的部分。5.3 几个容易踩的坑先说中文乱码问题。draw.io 在 Windows 上导出图片时偶尔会碰到中文字体显示为方块的情况解决方法是在导出前到额外选项里把字体调整为系统中已安装的中文字体比如微软雅黑或思源黑体。Mermaid 在线编辑器一般没有这个问题但如果你把 Mermaid 集成到自己部署的服务里要注意渲染容器的字体配置。再说 Mermaid 语法的坑。实体名大小写敏感关系符号容易混淆||o{和}|o{的细微差别足以导致语义完全错误错了还不好看出来。我自己的习惯是每定义一个实体关系就立刻在注释里写一句业务规则比如USER ||--o{ ORDER : 一个用户可以有多个订单这样既方便自己检查也方便同事读代码。CloudBeaver 的坑主要是权限问题。连接数据库时如果账号没有查 information_schema 的权限ER 图里的外键信息会不完整甚至整个 schema 都加载不出来。建议专门创建一个只读账号用于梳理既安全又不影响别人操作。最后是关系线混乱的问题。三款工具在表多的时候都会出现关系线交织这是 ER 图本身的物理限制不是工具问题。我的解决办法是分层画把核心业务表画在一张图把配置类、日志类的表放到另一张图必要时再用一张总览图显示所有表但不连关系线。这样每张图都干净、可读评审效率高很多。我自己现在基本不用桌面客户端画 ER 图了。如果是个人开发推荐直接用 Mermaid 写进 README如果是团队项目draw.io 的文件放 Git 仓库如果是接手老项目CloudBeaver 会帮你省掉大量梳理时间。三款工具都是开源或者底层开源的数据始终掌握在自己手里你拿去用一遍就知道区别了。最后分享一个我自己的习惯无论用哪款第一件事把主键、外键和索引在图上标清楚否则到后面关系一多越改越乱。