Web端开源ER图工具实测：三款主流方案对比与选型指南

做ER图这事儿放到五年前我可能张口就是PowerDesigner、Navicat、ERwin现在再让我推荐我基本只挑Web端能用的开源方案。原因很简单一个项目要画ER图的人往往不只是数据库管理员还有后端开发、产品经理、刚接手老系统的实习生。让所有人都装一个几GB的桌面客户端压根不现实。我也踩过不少坑本地装的建模工具导出的文件发给同事对方电脑上连字体都渲染不对改了一版表结构所有图要手动重画一遍团队在Git里根本没法对ER图做Diff最后图跟实际库越走越偏。后来我把目光转向“浏览器里直接用、源码开放、能跟研发流程打通”的工具这才算彻底把这块补上。这篇文章不搞推荐榜式的空谈我会直接拆三款我实测过、Web端可用、标着开源的数据库ER图设计工具把它们的原理、适用场景、实际操作流程和坑位都写清楚。内容适合后端开发、数据开发、刚开始做数据库课程设计的学生以及想给老系统补文档的维护者。读完你至少能回答一个问题手头这个项目ER图到底该用哪款工具、怎么画、怎么让图不变成一次性的废纸。1. 为什么我盯上“Web端开源”这个组合1.1 传统ER设计工具的三个痛点先说痛点不然你理解不了我为什么折腾这么久。传统工具最大的问题是授权门槛PowerDesigner和ERwin这种专业建模工具正式授权价格不低学生和个人开发者基本不会自费买。其次是平台绑定严重很多经典建模工具只好好支持WindowsmacOS和Linux用户要么开虚拟机要么找替代品协作时文件格式还不互通。第三个痛点是“图”和“库”脱节我在工具里改了字段数据库里的DDL不会自动同步反过来数据库结构变了图也不会自动更新。团队里一旦没人手动维护ER图很快就会变成一张过期的装饰画。这些痛点组合起来对现代开发流程的杀伤力很大。现在不少团队走的是GitOps路线数据库结构用迁移脚本管理文档跟着代码走。桌面建模工具的文件格式往往是一坨二进制或者私有XML放在Git里根本没法Review。我见过最典型的情况代码合并请求里改了五张表ER图却还是上个月的评审的人对着旧图看新代码怎么看怎么别扭。开源Web工具解决的就是这个循环——文件格式开放、能进版控、能自动从库里拉取最新结构。1.2 Web化与开源化给ER设计带来的变化Web化最直观的好处是零安装、零配置。打开浏览器输入网址就能用换来的是上手成本急剧下降。我以前带过一个刚入行的同学让他画订单模块的ER图他第一反应是“我电脑上没有Visio怎么办”。后来我把工具链接发过去五分钟之后他就开始拖表了。Web工具还有天然的平台无关性Windows、macOS、Linux、Chromebook只要浏览器能跑就能画团队协作时不用再互相迁就。开源带来的好处则更偏向工程化。第一你可以自托管。数据库ER图往往涉及表结构、字段名这些算得上内部敏感信息扔到公网SaaS上很多公司不放心。开源工具里像ChartDB、draw.io都支持私有部署数据不出内网。第二文件格式开放可控。draw.io的本质是个XML编辑器dbdiagram.io的模型是纯文本DSL这两个都能进Git做Diff。第三可定制。如果你有自动化需求完全可以写脚本调用它们的导出接口、解析它们的文件格式把ER图生成流程整合进CI。2. 三款工具逐个拆解2.1 diagrams.netdraw.io通用图表工具里的隐藏高手很多人知道draw.io是因为画流程图、架构图但它做ER图的能力经常被低估。draw.io是完全开源的GitHub上仓库叫jgraph/drawio核心代码用Apache 2.0协议授权官网diagrams.net和桌面版都可以直接用自托管也完全免费。它做ER图有两种玩法一种是从空画布开始手动拖拽表格形状、连线、设置主外键另一种更高级——它内置了一个“从SQL导入”功能你可以直接把建表语句丢进去它自动生成表格形状和关系连线这个我后面实操部分会细说。draw.io的表格形状虽然不如专业建模工具那么“ER味”但胜在灵活。每个表格就是一个容器里面每一行是一个字段你可以给主键字段加粗、加钥匙图标外键用不同颜色标出来。连接线支持各种箭头样式可以标注1:1、1:N、N:M的基数关系。开源插件生态也丰富社区有人开发了数据库逆向导入扩展可以直接连接MySQL、PostgreSQL拉取表结构。不过要提醒一句draw.io本质上是个“通用图表编辑器”没有严格的“ER模型校验”概念——你画两个表之间有连线它不会自动识别这是外键约束。所以它更适合做“给人看的ER图”而不是“给机器校验的ER模型”。2.2 ChartDB为数据库ER“反向工程”而生的新锐ChartDB是这三款里“专为数据库ER图而生”的一位。仓库在GitHub上叫chartdb/chartdbMIT协议完全开源。它主打的能力是反向工程你给它一个数据库连接串它连上库之后自动扫描所有表、字段、索引、约束然后生成一张可以交互的ER图。我头一回用的时候确实被惊到了——之前手动画了三天的图它几十秒就出来了而且关系线是根据外键约束自动连的不会出现“明明有外键但图上没连线”这种漏网之鱼。ChartDB是纯浏览器应用官方在app.chartdb.io上提供在线服务也支持Docker自托管。它现在的数据库支持已经很全PostgreSQL、MySQL、MariaDB、SQLite、SQL Server、ClickHouse、Redis等等都在列表里。生成图之后你可以做三件很实用的事继续在图上调整布局、给表加注释说明把整个模型导出成SQL DDL把图导出成PNG/SVG图片。对于“接手老项目第一天想快速摸清楚数据库大概长什么样”这种场景ChartDB几乎是无脑首选。它的局限在于正创建模能力相对弱它擅长的是“从库到图”不太适合“从图到库”的纯正向设计流程当然你仍然可以手动加表但体验没有专业建模工具那么丝滑。2.3 dbdiagram.io用DSL快速“正向建模”dbdiagram.io是这三款里最“程序员友好”的。它的核心是DBMLDatabase Markup Language一种专门描述数据库表结构和关系的DSL。你写十几行纯文本定义表、字段、主键、外键右边画布上就实时渲染出ER图同样这份DBML还能反向生成建表SQL。我第一次用的时候感觉像是在写代码而不是画图这个思路对习惯用文本工具的程序员来说接受度非常高。这里要说清楚授权问题因为它不像前两款那么“根正苗红”。dbdiagram.io的在线服务是免费但闭源的注册账号后就能用免费额度对一般项目足够而DBML语言规范本身和它的解析器是开源的GitHub上有dbml-lang组织维护。严格抠字眼的话“dbdiagram.io整个网站”不算完全开源但“DBML这套建模语法”是开放的。如果你在公司里使用在意合规建议跟法务确认一下服务条款如果只是在个人项目里画个图问题不大。我在选型建议部分还会再提一个纯开源替代思路不怕麻烦的可以往下看。DBML最大的价值是可审查、可版本化。一段DBML文件放到Git里每次提交都能看到表结构怎么变化Review起来跟看代码一样。这个特性让它很适合“正向设计”新项目启动时先用DBML快速建模评审通过后生成SQL然后数据库迁移脚本就可以从这套定义里持续演进了。3. 实操三条路线把ER图真正用起来3.1 路线一用dbdiagram.io从零正向建模我通常怎么用dbdiagram.io给新模块建模下面用一个精简版电商订单模型举例读者可以直接把这段代码粘到dbdiagram.io左侧编辑器里看效果Table users { id int [pk, increment] username varchar(64) [not null, unique] email varchar(128) created_at timestamp [default: now()] } Table products { id int [pk, increment] name varchar(128) [not null] price decimal(10,2) [not null] stock int [default: 0] } Table orders { id int [pk, increment] user_id int [not null, ref: users.id] status varchar(32) [default: pending] created_at timestamp [default: now()] } Table order_items { id int [pk, increment] order_id int [not null, ref: orders.id] product_id int [not null, ref: products.id] quantity int [default: 1] price decimal(10,2) }保存之后右侧马上会生成四张表users和orders之间、orders和order_items之间、products和order_items之间会自动出现关系连线。字段名前会标出PK、FK的小标识红绿乱七八糟的颜色也可以自己在主题里调。工具栏里有一个“Export”按钮可以直接导出PostgreSQL、MySQL、SQL Server等方言的DDL脚本。比如它生成的PostgreSQL DDL里orders表会是这样的CREATE TABLE orders ( id int PRIMARY KEY, user_id int NOT NULL, ... CONSTRAINT orders_user_id_fkey FOREIGN KEY (user_id) REFERENCES users (id) );注意一个细节DBML里的increment属性在导出MySQL时会自动变成AUTO_INCREMENT在PostgreSQL里则是SERIAL或IDENTITY具体取决于你选的方言版本。所以同一个模型在不同数据库之间迁移时DBML的复用价值就体现出来了。这个工具最适合“我脑子还没想清楚要建哪些表”的阶段。写代码改模型比拖拽绘图快得多改一个字段名就是改一行文本改完关系自动更新。我个人的经验是先写草稿版DBML确认主外键关系再生成SQL最后落到迁移脚本里。这样避免了很多“图画完了SQL还得手写一遍”的重复劳动。3.2 路线二用ChartDB从已有数据库反向生成ER图假设你现在接手一个老系统库里面几十张表文档啥都没有。这个场景就直接上ChartDB。具体操作是这样的访问app.chartdb.io或者你自托管的ChartDB实例点击创建图表它会让你选择数据库类型和连接地址。以MySQL为例需要填主机名、端口、用户名、密码、数据库名。填完之后点连接它会扫描整个schema随后画布上就会铺满表——每张表一个方块字段名、类型、主外键标得清清楚楚。关系连线是自动根据外键约束画出来的这一点比手动建模靠谱得多人眼可能会漏掉某条外键数据库约束不会骗人。扫描完成后默认视图是全量展示表多的时候会有点乱。这时候我习惯先在右上角的“schema视图”里勾选业务模块对应的表比如只选orders、users、products先看核心链路确认核心关系没问题之后再逐步展开其他表。左侧边栏可以编辑表名、加描述、改字段注释这些注释会跟着模型走。等图整理得差不多点导出就能拿到结构清晰的PNG/SVG也能导出整套DDL做备份或重建。我自己试过一次很典型的场景一个跑了五六年的系统里面有一张表既没有主键也没有外键ChartDB导出来的图里它是“孤岛”——没有任何连线。顺着这张“孤岛表”去翻业务代码果然发现它被当成了“配置缓存”在用数据一致性全靠业务侧保证。这种问题要不是ER图自动生成光靠人眼阅读建表语句得花好几倍的时间才能发现。3.3 路线三用draw.io手动绘制并清洗关系draw.io的典型使用场景是你已经有ER图素材但需要整理成“能拿出去评审、能贴到文档里”的正式版。我强烈不建议从零开始拖表画ER图——效率太低但它那个“从SQL导入”的功能值得认真讲讲。在draw.io画布上展开菜单栏的Arrange排列找Insert插入再点Advanced高级里面有一个From SQL选项。点开之后会弹出一个文本框让你粘贴CREATE TABLE语句。draw.io会解析这些DDL把每张表转成一个表格形状字段一行一个主键和外键会在解析后自动连上线。我粘贴一份简化版建表语句做示例CREATE TABLE department ( id INT PRIMARY KEY, name VARCHAR(50) ); CREATE TABLE employee ( id INT PRIMARY KEY, name VARCHAR(50), dept_id INT, FOREIGN KEY (dept_id) REFERENCES department(id) );粘贴进去点Insert画布上会出现department和employee两个表格中间连了一条外键关系线。到这里draw.io的“自动能力”就结束了剩下的活儿得自己上手把表排列整齐设置表头颜色隐藏不重要的字段行给连线上标上基数符号。好在draw.io的表格形状可以调整每一行的可见性右键点某一行就能删除该行的显示不会影响形状本身这个特性非常适合做“下一代接口用的对外版ER图”——只展示重要字段不暴露内部实现字段。draw.io我最常用它的场景是“开架构评审会”。把draw.io的在线白板投到屏幕上大家一边讨论一边改连线、加批注改完直接导出SVG放进Confluence或者飞书文档。因为它是XML格式我甚至会用脚本批量替换里面的一些样式字符串快速统一整套图的颜色和字体。这种灵活性是那些封装死的建模工具给不了的。4. 常见问题与排查技巧4.1 数据库连接不上、报错频繁用ChartDB这类工具连接数据库时最常见的报错是“Connection refused”或“Access denied”。先别急着怀疑工具多数情况下是网络和权限问题。数据库如果跑在内网你需要在服务器上把目标端口MySQL的3306、PostgreSQL的5432对当前出口IP放过防火墙如果数据库只绑定了127.0.0.1那工具从外部自然连不上需要改成0.0.0.0监听并配置好安全组。另外要检查账号授权有时候工具会用非本机来源的host连接比如你本机IP不在用户的授权列表里就会被拒。还有一类坑是连接字符串带了多余参数。比如某些工具会在数据库名后面自动拼上?useSSLfalse之类的参数不同驱动对参数格式要求不一样解析失败就会报“Unable to connect”。我的习惯是先在命令行用mysql/pg客户端把连接信息验证一遍确认能连再去图形界面里填这样能省去大量排查时间。还有一个容易被忽视的问题数据库驱动版本。ChartDB在线版会自动匹配驱动但如果你自托管的是旧版本镜像里面的驱动很可能不支持新版数据库的认证插件。最典型的就是MySQL 8默认的caching_sha2_password老驱动连不上去。解决方案是升级ChartDB版本或者在MySQL侧把该用户的认证插件改成mysql_native_password注意考虑安全问题生产环境慎用。4.2 字段中文乱码涉及到中文表名、字段名和评论的场景往往在数据库连接和文件导出两个环节出问题。连接环节务必确认客户端连接字符集是utf8mb4MySQL或UTF8PostgreSQL否则扫描出来的表注释会是一串问号。导出环节如果是PNG/SVG这类图形文件字体渲染可能导致中文变方块——draw.io里如果发现导出的PNG文字发虚或变成乱码检查一下画布字体设置通常把字体切换成系统自带的Noto Sans CJK或微软雅黑就能解决。ChartDB在线版一般没有这个问题但自托管的Docker容器如果缺中文字体导出图片时也会翻车需要在镜像里安装fonts-noto-cjk这类包。4.3 表一多ER图就乱成蜘蛛网几十张表一股脑全塞到一张画布里谁来了都理不清。这不是工具不行是使用姿势不对。我常用的三招第一按业务模块拆图用户域、订单域、商品域分开画需要看全景时再靠工具的分组/多页功能整合。draw.io支持多页签每页可以画一个子域ChartDB可以通过筛选schema只显示部分表。第二隐藏非关键字段。ER图的作用是传达结构关系不是数据库字典的复刻。把不需要的字段行隐藏掉整体可读性会大幅提升。第三利用自动布局。draw.io右上角的Layout菜单里有多种自动排列算法可以让连线横平竖直ChartDB的自动布局虽然不是每次都能完美避开交叉线但多按几次“随机重排”往往能找到干净的角度。手动拖表的时候我建议按“上层主数据表在左下层业务流水表在右”的习惯摆放关系线基本都是清晰的从左到右流向。4.4 ER图和实际数据库结构对不上这几乎是所有ER设计工具的通病图画完没人维护过两个月就废了。要解决这个问题我的建议是把ER图的生成或者校验做成自动化。用dbdiagram.io的DBML可以直接把DBML文件提交到Git仓库配合CI脚本每天定时连接测试库重新生成一遍最新DBML跟仓库里的旧版本做diff一旦有差异就在CI里报错。用ChartDB也类似它可以生成带时间戳的SQL DDL你可以把这份DDL提交进仓库哪天想核对了就拉出来比对。draw.io的XML文件也能进Git但Diff体验差一些更推荐把它当作“对外发布文档”的最终加工环节而不是唯一数据源。5. 我的选型建议与经验5.1 按场景选型不迷信单一工具我见过不少人把三款工具用成“三选一”实际用下来会发现它们定位完全不一样很多团队是组合使用。为了更直观我把自己的选型逻辑整理成了一张表场景推荐工具原因新项目从零正向建模dbdiagram.ioDBML文本可Diff快速产出SQL DDL接手老项目摸清库结构ChartDB直连数据库自动生成ER不漏外键画给甲方/评审看的正式图draw.io排版灵活导出SVG/PNG质量高未交付前的内部脑暴draw.io白板即时协作随时修改需要自托管、数据不出内网ChartDB/draw.io两者都支持Docker私有部署想纳入CI做结构校验dbdiagram.io的DBML文本格式适合脚本处理与Diff这里有一个我踩过的坑不要为了“统一工具”强迫团队只用一个。我有一段时间希望团队所有人都在draw.io里画ER图结果研发嫌拖拽麻烦每次都是画到一半就放弃后来允许“各画各的最终文档统一导出成draw.io”局面才顺了。工具切分跟代码分层一样找准边界比什么都重要。5.2 我的一些实操心得第一命名规范是ER图好用的前提。这话听着像废话但真见过太多库里的表和字段名随心所欲。如果在模型阶段就统一用snake_case或团队约定的大小写风格命名主键统一叫id外键统一用xxx_idER图生成之后几乎不需要任何手动整理。反过来一个库里的表名一会儿单数一会儿复数、外键名不带关联表名任何工具都救不了。第二把ER图当作“活的文档”来管理。我现在的习惯是项目仓库docs/db目录下放一个db.dbml文件它是数据库结构的权威来源每次表结构变更先改DBML再生成迁移SQLCI里跑一个脚本当有人改完SQL但没同步DBML时自动告警。这样ER图不再是事后补交的作业而是整个变更流程的第一站。对于已有数据库我在自托管的ChartDB里定时跑一次扫描对比之前导出的DDL有变化会收到通知相当于给老系统装了一套“结构监控”。第三不追求一张图塞下所有东西。很多同学画ER图恨不得把每个字段都写上去结果图导出来拉伸到好几屏评审时谁也看不全。我的处理方式是分层全量模型图包含全部字段放在内部文档库作为数据库字典的补充对外展示用的ER图只保留关键字段和关系控制在A4纸范围内。这两个图可以由同一份DBML/DDL生成只是导出时过滤字段的粒度不同。可能有人觉得这样要维护两份图其实不是核心只有一份模型定义展示粒度只是它的一个“视图”而已。用了一段时间这些Web端工具之后我最大的感受是开源工具拼的不是单个功能多复杂而是它们怎么融进你的工程流程。以前画ER图是个独立的、画完就结束的动作现在DBML可以跟着代码走ReviewChartDB能帮你盯住线上库结构的变化draw.io把最后的PPT环节也包圆了。我个人现在的主力组合是“dbdiagram.io建模 ChartDB反向校验 draw.io出评审图”如果你刚起步先挑其中一款用起来就行——毕竟不管哪一款都比手工维护一张永不过期的JPG强得多。