做后端、全栈或者数据库设计绕不开 ER 图这件事。以前我画 ER 图基本离不开桌面软件比如 MySQL Workbench、Navicat、PowerDesigner装一整套 IDE 才能开工。后来发现真正高频的场景并不需要那么重的工具很多时候只要打开浏览器把实体和关系画清楚能导出给团队看就够了。这篇文章分享 3 款 Web 端就能用的开源数据库 ER 图设计工具diagrams.net、Mermaid Live Editor、PlantUML。它们覆盖了手动拖拽绘图、代码生成图表、脚本化自动建模三套不同玩法不管你是刚接触数据库设计的新手还是每天要和几十张表打交道的资深开发都能在里面找到顺手的一款。1. 为什么我需要 Web 端开源的 ER 图工具先说一个真实场景去年我给一个中小型项目做数据模型表有几十张还要跨三个人协作评审。最初我用本地的建模工具画画完导出图片丢到群里别人提完意见我再改再导出再丢群里。一个上午过去了光文件名就攒了五六个版本。后来我换成 Web 端工具直接在浏览器里改、实时分享链接整个评审流程从半天压缩到半小时。从那以后我就把主流建模需求全部迁到 Web 端工具上。1.1 桌面建模工具的三个痛点第一个痛点是环境依赖。桌面端工具通常需要安装客户端有些还依赖 Java 环境、专用驱动或对应数据库版本。换一台电脑、换一个操作系统环境就要重新配这还没算上团队里有人用 Windows、有人用 macOS 的兼容问题。第二个痛点是协作成本。桌面工具生成的工程文件通常是一个私有格式同事想看要么也装同样的软件要么你导出一张图片。图片最大问题是不能继续编辑一旦别人提出修改意见你必须回到自己的电脑上打开原始文件改完再导出一张新图流程图里的“版本地狱”就这么来的。第三个痛点是授权限制。很多成熟的建模工具都是商业软件按年订阅价格还不便宜。对于个人开发者、学生或者刚起步的小团队为了画一张 ER 图掏这个钱实在不划算。1.2 开源与 Web 化解决的真实问题Web 化解决的是“随时随地能用”的问题。只要浏览器能打开就不存在安装环境的问题也不存在平台隔离的问题手机、平板、低配电脑都能参与查看和编辑。对一个需要快速迭代的团队来说“零安装”本身就是效率。开源解决的是“可控”和“可持续”的问题。工具本身的代码公开协议允许你自由使用甚至自己部署一套。你不必担心授权到期也不必担心供应商调整收费策略后把你锁死。更重要的是开源社区通常意味着活跃的插件生态和持续维护遇到问题有迹可循甚至可以自己提交补丁。另外Web 端工具大多支持把图表内容序列化成文本XML 或 DSL这给版本管理带来了天然优势。ER 图不再是一张二进制大图而是一段可以放进 Git 仓库的文本每次改动都能 diff能审阅能回溯。这一点对开发团队尤其重要。2. diagrams.net手动绘制 ER 图最通用的一款2.1 它是什么样的工具diagrams.net 就是大家更熟知的 draw.io是一个老牌开源绘图工具代码在 GitHub 上以 Apache-2.0 协议开源。官方提供了在线版 app.diagrams.net也支持桌面离线版还能用 Docker 在团队内网自托管。它虽然不叫“数据库设计工具”但通过内置的实体关系图形库完全可以胜任 ER 图绘制工作。我把它放在第一位推荐是因为它的上限最高。你既可以画 ER 图也可以画架构图、流程图、时序图甚至线框图都行。对团队来说一套工具覆盖多种图表场景学习成本很低。特别适合要给客户出正式评审稿、要导出高清图嵌入文档的场景。2.2 完整绘制一张 ER 图的流程在浏览器打开 app.diagrams.net选择创建空白绘图。左侧默认是图形库如果你找不到实体关系相关的图形就点图形库底部的“更多形状”在“软件”分类下勾选“Entity Relations”这样就会加载实体、关系、属性等专用形状。绘制时我习惯按这个顺序来先用实体形状Entity拖出第一个表双击实体名称位置输入表名。在实体内部添加字段行可以用文本编辑框手动输入字段名和类型也可以用专门的表格形状Table模拟表结构。连续拖出多张表把同类型字段的样式统一一下比如主键加粗、外键用斜体。用连接线把表与表连起来终点选在对应字段附近表示外键关联。双击连接线添加关系描述比如1对N或者写上外键字段名。最后在顶部菜单“文件”里选择导出为 PNG 或 SVG也可以保存为 .drawio 源文件放进 Git 仓库。在线版编辑器的文本编辑体验其实很接近表格处理软件字段行可以上下移动也可以通过复制粘贴快速批量创建。画完核心表格后我会把颜色体系做一下统一主表用同一种底色字典表用另一种底色这样可以很快看出业务模块边界。2.3 我在实际使用中积累的经验第一不要用普通矩形拼凑表格。普通矩形再加多条文本看起来像表但移动和调整宽度时很容易错位也不方便统一设置字段行的背景色。直接用“表格”形状或“Entity Relations”库里的实体形状双击就能编辑行结构更清晰。第二连线一定要从连接点拖出不要随便从一个图形的边线中间拉线。连接点“”才是锚点从锚点出发的连线在图形移动时会自动跟随不容易断。直接从边线拉线看着随意后期整理却很容易乱。第三在线版默认数据保存在浏览器本地或你自己选择的云盘不会自动云同步。如果你在公司电脑画了一半回家想继续记得先导出 .drawio 文件。如果团队多人协作建议把 .drawio 文件放到 Git 仓库配合 VS Code 的 draw.io 插件就能在代码评审时直接看到 ER 图变更。3. Mermaid Live Editor用文本定义 ER 图3.1 先理解 erDiagram 的工作方式Mermaid 是一个基于 JavaScript 的开源图表工具最大的特点是“用 Markdown 风格的纯文本描述图表”然后由 Mermaid 渲染成图形。它支持流程图、时序图、甘特图等也支持 ER 图。官方在线编辑器叫 Mermaid Live Editor打开 mermaid.live 就能用左侧写语法右侧实时渲染非常直观。用 Mermaid 画 ER 图的核心是erDiagram关键字。你不需要拖拽、不需要调样式只需要按语法把实体名、字段和关系写出来图就自动生成了。这对开发者来说非常友好因为“代码即图”文本可以直接放进文档、提交到 Git甚至参加代码评审。3.2 一个订单场景的 ER 图示例我先给一个常见的电商订单场景示例代码块可以直接复制到 Mermaid Live Editor 里运行。erDiagram CUSTOMER ||--o{ ORDER : places ORDER ||--|{ ORDER_ITEM : contains PRODUCT ||--o{ ORDER_ITEM : includes CUSTOMER { int id PK string name string email } ORDER { int id PK int customer_id FK datetime created_at string status } ORDER_ITEM { int order_id PK, FK int product_id PK, FK int quantity decimal price } PRODUCT { int id PK string title decimal price }这里的关系行语法很关键。CUSTOMER ||--o{ ORDER表示一个用户可以有零个或多个订单||表示“恰好一个”o{表示“零或多个”|{表示“一个或多个”。Mermaid 支持的关系符号有|o零或一个、||恰好一个、}o零或多个、}|一或多个。组合起来能覆盖绝大多数数据库外键场景。实体内部的字段写起来也很直观。int id PK表示主键int customer_id FK表示外键多个属性可以用逗号分隔比如order_id PK, FK表示这个字段既是主键的一部分也是外键。Mermaid 会自动区分类型、主键和外键的视觉样式。3.3 如何接入文档和自动化流程Mermaid 最大的优势是嵌入能力。GitHub 的 Markdown 和很多平台的文档都原生支持 Mermaid 渲染你在仓库里写一段erDiagram别人打开文档就能直接看到渲染好的 ER 图不需要额外打开任何编辑器。如果需要在文档外使用可以用官方命令行工具 mermaid-cli把.mmd文件转换为 PNG 或 SVG命令大致是这样的mmdc -i er.mmd -o er.svg这个命令可以放进 CI 流程。每次数据库结构变更维护好对应的.mmd文件CI 自动生成最新 ER 图并发布到文档站点。对追求“文档与代码同步”的团队来说这是性价比最高的方案。3.4 使用 Mermaid 画 ER 图的注意点第一Mermaid 不支持直接连接数据库自动读取表结构它只是一个“画图引擎”。如果你要反查现网数据库得先想办法把表结构转换成 Mermaid 文本。第二实体多、字段多之后默认的横向布局会变得很宽阅读体验不太好。解决办法是拆模块不要把 30 张表放在一张图里按业务域拆成几张图再用文档目录组织。第三关系标签中的中英文混排没有问题但字段描述比较长时图上会出现很长的连接线。我的经验是精简字段ER 图只展示核心字段类型约束、索引、默认值留给 DDL 去表达。4. PlantUML适合脚本化和复杂建模的文本引擎4.1 PlantUML 与 ER 图的关系PlantUML 是另一款老牌开源文本绘图工具通常人们用它画 UML 时序图、用例图、类图但它同样可以画实体关系图。PlantUML 的语法比 Mermaid 更细布局控制能力更强因此在复杂模型、需要批量生成图表的场景下很有优势。PlantUML 的使用方式也比较灵活既可以访问官方 Web 服务即时渲染也可以在本地用 Java 命令行运行 jar 包还可以配合 VS Code、JetBrains 等编辑器的 PlantUML 插件预览。它对处理大图的支持比纯前端工具更成熟适合系统规模比较大的数据库建模。4.2 定义实体和关系的基本语法PlantUML 画 ER 图主要用到两个关键字entity定义实体relationship或者直接书写连接关系。以下是一个与前面 Mermaid 示例对应的订单模型startuml !theme plain left to right direction entity 用户 as user { * id : int PK * username : varchar(50) unique * email : varchar(100) } entity 订单 as order { * id : int PK * user_id : int FK * order_no : varchar(32) unique * created_at : datetime } entity 订单明细 as order_item { * id : int PK * order_id : int FK * product_id : int FK * quantity : int * price : decimal(10,2) } entity 商品 as product { * id : int PK * title : varchar(200) * price : decimal(10,2) } user ||--o{ order : 购买 order ||--|{ order_item : 包含 product ||--o{ order_item : 被购买 enduml这里entity 用户 as user定义了名为“用户”、代码标识为user的实体。花括号内部是字段列表*表示非空PK表示主键FK表示外键可以用自定义标签标记unique唯一索引。连接关系那几行的语义和 Mermaid 基本一致||--o{表示“一 对 零或多”||--|{表示“一 对 一或多”。4.3 渲染方式与团队协作PlantUML 官方在线渲染服务可以直接通过 URL 生成图片但日常我更推荐 IDE 插件。VS Code 里安装 PlantUML 扩展编辑.puml文件时按快捷键就能预览保存后还可以右键导出 PNG 或 SVG。团队协作时PlantUML 的价值体现在可组合性上。你可以把公共的字段定义抽到单独的.puml文件中然后通过!include在多个模型文件里复用。这样一旦团队规范改了字段标准只需要改一处。对于几十张表的大型模型这种模块化管理方式比手动画图可控得多。4.4 什么时候我更倾向用 PlantUML如果你只是快速画一张简单草图Mermaid 已经足够但当你需要处理复杂的数据库模型比如几十张表、多层业务域、大量外键关系时PlantUML 的布局控制会明显靠谱一些。它还能通过命令行参数批量导出一批模型文件方便嵌入到自动化脚本中。另外PlantUML 支持生成 ASCII 图这在纯命令行环境里非常实用。你在服务器上临时看一个表结构关系不需要图形界面直接输出一组文本符号就一目了然。5. 三款工具对比与选型参考5.1 核心参数对照表维度diagrams.netMermaid Live EditorPlantUML产品定位通用可视化绘图编辑器文本驱动的图表引擎文本驱动的建模引擎开源协议Apache-2.0MITGPL-3.0上手难度低中中高图表来源手动拖拽编辑文本描述自动渲染文本描述自动渲染版本管理友好度一般XML 文件可入 Git高纯文本可按 diff高纯文本可按 diff数据库连接不支持直接连接不支持直接连接不支持直接连接导出格式PNG、SVG、XML、PDF 等SVG、PNG、PDF通过 CLIPNG、SVG、ASCII、PDF 等典型场景客户评审、架构文档、跨团队通用绘图开发文档、GitHub 内嵌图、快速迭代大型模型、脚本批量生成、命令行环境5.2 不同身份和场景的选型建议刚入门的新手或者需要给业务方、客户讲清楚表结构推荐 diagrams.net。它的拖拽操作符合大多数人的直觉样式调整直观输出结果也足够专业。你不需要学习任何语法就能在十几分钟内画完一张核心 ER 图。如果你的团队以开发者为主文档和代码都放在 Git 仓库我强烈建议用 Mermaid。把 ER 图写在 Markdown 里别人看文档的时候直接看到图没有任何工具门槛。对代码评审来说Mermaid 文本可以像代码一样做 diff这比图片对比靠谱多了。如果你做的是企业级建模或者需要在一套流程里批量生成大量表结构图PlantUML 更合适。它虽然语法多但换来的是组合能力和导出方式的灵活性。你可以为不同数据域建立独立文件再用!include聚合生成一个大型全景图。5.3 一个组合使用的思路我现在的典型组合是Mermaid 打草稿diagrams.net 出正式交付图PlantUML 用于需要定时刷新的自动化模型。需求分析阶段我在 Mermaid Live Editor 里快速调整实体关系几分钟画一版跟同事确认完业务结构确认没问题后把最终版放到 diagrams.net 里精修排版加上标题、图例、模块底色导出高清图放进 PPT 或设计文档只要这套模型需要长期维护我会预留一套 PlantUML 源文件后续表结构有变更时通过脚本更新。6. 常见问题与避坑经验6.1 能不能连上数据库自动生成 ER 图这是被问得最多的问题。老实说这三款 Web 工具默认都不能直接连 MySQL、PostgreSQL 或 Oracle 数据库自动读表结构它们偏重“设计”而不是“逆向工程”。如果你需要从现网数据库快速逆向出 ER 图可以先用 DBeaver 这类带逆向功能的工具生成再导出为图片或中间格式也可以自己写一个小脚本从库里把表名、字段、主外键信息读出来再生成 Mermaid 或 PlantUML 文本。我自己的做法是先用 SQL 脚本把建表 DDL 导出来然后用脚本解析出每张表的字段和关系最后生成对应的.mmd或.puml文件。这个过程用 Python 或 Node.js 都能实现核心是把数据库的元数据转成文本 DSL后续维护就轻松了。6.2 ER 图画得太大、连线太乱怎么办很多人在 ER 图工具里画出几十张表后发现整个画布像一团毛线。我的经验是别追求一张图表现所有细节按业务模块拆图。比如一个电商系统把用户和订单画一张商品和库存画一张支付和退款画一张。每张图只展示核心表和关键外键数量控制在 10 张以内。这样不仅图面干净评审时也更容易聚焦。如果确实需要一张总览图可以每张子图只放模块主表然后用超链接或文档目录把子图串起来。另一个技巧是统一表名和字段名的展示规范。表名用英文大写字段只保留名称、主外键标记、类型不要一次性把所有索引、约束、默认值都堆上去。ER 图关注的是实体和关系不是完整的 DDL。6.3 Web 在线工具的隐私与安全问题有些人担心把表结构画到在线工具里会泄露业务信息这个顾虑合理。处理方法是分级使用非敏感项目的架构图可以放心用在线版涉及核心业务数据的模型建议把工具部署到内网。diagrams.net 和 PlantUML 都支持自部署Mermaid Live Editor 也有对应的本地要实现。通过 Docker 部署一套内网实例数据就不会出内网。如果连镜像都不想拉还可以用 diagrams.net 的离线桌面版本质上是一样的渲染引擎只是在本地运行。6.4 导出图片不清晰或字体错乱的处理导出图片不清晰通常和分辨率有关。diagrams.net 导出时如果没有选择“缩放”或高 DPI默认位图在放大后会模糊。解决方法是优先导出 SVG 矢量图或者把缩放比例调到 200% 再导出 PNG。字体错乱大多发生在跨平台场景比如在 macOS 上用的字体到了 Windows 就找不到。解决方案有两个一是换用通用字体比如思源黑体、Arial、微软雅黑等这些在主流的操作系统上都有二是导出前把文字转为路径但 diagrams.net 没有这个选项所以最好是统一团队的使用环境。最后再分享一个我坚持很久的习惯把 ER 图源文件作为项目文档的一部分跟着代码一起维护。在仓库里建一个docs/db/目录下面放 DDL、Mermaid 或 PlantUML 源文件、以及导出的 SVG 图。每次表结构有变动顺手更新对应的文本图文件提交的时候评审人能在 MR 里看到 ER 图 diff。这个习惯帮我们省掉了无数“上次那张图是哪一版”的无效沟通。工具会变习惯才是真正影响效率的东西。