企业官网建设流程全解析

画 ER 图这件事，几乎每个做数据库设计的人早晚都会碰上。不管你是做课程设计需要画几张实体关系图交作业，还是开发前要梳理表结构，甚至只是想给老项目的数据库反推出一份能看懂的关系图，一个趁手的 ER 图设计工具能省下大量时间。

市面上的 ER 图工具不少，但很多要么是桌面客户端要先安装，要么是收费软件需要授权。我一直偏好 Web 端可用的开源方案，因为浏览器一开就能用，换个电脑也不耽误，还能拿去给别人演示或部署到内网。这篇文章就分享一下我实际用过、觉得值得收藏的 3 款开源 ER 图设计工具，包括各自的定位、核心功能、实操步骤，以及我踩过的一些坑。如果你正在找数据库建模或者可视化工具，这篇内容可以直接“抄作业”。

1. 为什么数据库设计需要专门的 ER 图工具

1.1 画 ER 图的常见场景和对工具的真实需求

很多人以为画 ER 图就是拿 Visio 或者 PPT 画几个方框、连几条线。这事儿如果只是画两三张表确实够用，但一旦实体数量上去了，比如二三十张表、表间关系复杂一点，手动画图就会变成一场灾难：连线交叉、布局混乱、改了表结构图又要重画，浪费时间不说，图还容易和真实数据库脱节。

我总结下来，真正需要认真画 ER 图的场景主要有三类。第一类是数据库课程设计和毕业设计，老师通常要求提交 ER 图，而且还得区分实体、属性和关系，方框、椭圆、菱形一个都不能少，这种场合对图形规范有要求。第二类是项目开发前的正向建模，你先设计好 ER 图，再生成建表 SQL，这样可以避免开发过程中反复改表、到处打补丁。第三类是接手老项目后的反向梳理，数据库可能已经跑了很多年，文档早没了，表之间靠什么外键关联也没人说得清，这时候需要工具连接数据库或者导入 SQL 脚本，自动把 ER 图还原出来。

针对这些场景，我对 ER 图设计工具的核心需求就三条：支持从 SQL 脚本或者数据库连接自动生成 ER 图，也就是反向工程能力；支持把设计好的模型导出成 SQL DDL 语句，也就是正向生成能力；第三就是操作要快，最好能在浏览器里完成，不用安装一堆依赖。

1.2 三种画图方案横向对比，Web 端开源工具赢在哪里

为了说清楚为什么推荐 Web 端开源工具，我把目前常见的画 ER 图方案放在一起做了个对比。

Web 端开源方案最大的优势是“零门槛”。你不用先想自己是什么操作系统，也不用担心安装包体积和授权文件，只要有个浏览器就能干活。很多这类工具还支持把图直接分享给别人查看和编辑，这对小组作业或者团队协作特别重要。另外，开源意味着代码可以审查，核心数据掌握在自己手里，你要是愿意甚至可以部署到内网服务器，配合公司或学校的网络环境使用。

我个人的建议是：如果你的目标只是快速出一张能交差的图，选其中任何一款都可以；如果你想系统地做数据库建模，在多种数据库之间对比表结构，那么优先考虑带“直连数据库”或“SQL 导入导出”功能的工具。

2. 三款值得关注的 Web 端开源 ER 图工具

说句实话，市面上号称“开源 + Web 端”的 ER 图工具并不算多。我陆陆续续试过不少，有的要么停止维护了，要么只支持单一数据库，有的号称开源但核心功能锁在付费版里。以下三款是我实际体验下来最顺手的，它们分别代表了三种不同的设计思路，你可以根据自己的使用习惯来选择。

2.1 draw.io：功能全面的老牌开源绘图工具，反向生成 ER 图很稳

draw.io（现在也叫 diagrams.net）严格来说不只是一个 ER 图工具，它是一个通用的开源绘图软件，支持流程图、架构图、思维导图、UML 图等，ER 图只是它能干的活之一。

它的开源和 Web 端属性很明确：源码在 GitHub 上完整开源，项目由社区维护；官方直接提供在线网页版，也支持 Windows、macOS、Linux 桌面客户端。最让我满意的是，它可以直接从 SQL 建表语句自动生成 ER 图，菜单路径是 Arrange -> Insert -> Advanced -> SQL，选择 MySQL 或者其他数据库类型，把 CREATE TABLE 语句粘进去，点 Generate，实体框和表间关系就自动画出来了。

但 draw.io 也有它的局限。因为它是通用绘图工具，它对“数据库建模”这种垂直场景没有做特别深入的优化，比如不会帮你检查外键引用是否合法，也不会生成 ALTER TABLE 之类的变更脚本。它更适合你把 ER 图当作交付文档的一部分去绘制，而不是作为数据库开发的驱动工具。如果你需要的是“把表结构变成图”，那 draw.io 是一把非常称手的刀。

另外，如果你是课程设计或者毕业设计需要画那种教科书风格的 ER 图——实体用矩形、属性用椭圆、联系用菱形，draw.io 也能画，模板和形状库里都有对应图形，具体怎么组织比较费心，但有现成形状可以拖拽。

2.2 dbdiagram.io：用代码写 ER 图，DSL 驱动模型让导入导出极其顺滑

dbdiagram.io 是一个“ER 图即代码”风格的 Web 工具。它不像普通画图工具那样靠拖拽，而是通过编写一种叫 DBML（Database Markup Language）的轻量级 DSL 来描述表结构，然后自动渲染成 ER 图。写表和表关系的方式很接近写代码，非常适合程序员习惯。

先声明一个问题：dbdiagram.io 本身是商业产品，核心服务并没有完全开源，但它的语言规范 DBML 是开放的，而且免费版在 Web 上就能用，对于大多数建表和反推结构的场景已经足够了。如果你对“完全开源”有硬性要求，建议把它当作一个辅助工具来使用，同时把 ERDCloud 作为主力。

它在实操中非常强大的地方主要体现在两端：一个是绘制效率高，因为不再需要拖拽对齐方框，只需要打字描述 Table 和 Ref；另一个是它支持把 DBML 转成多种数据库的 SQL 建表语句，国内很多人在做课程设计的时候，先画完 ER 图，然后一键导出 MySQL 或 PostgreSQL 的建表 SQL，比自己手写快太多。

我通常会把 dbdiagram.io 当成“正向建模”的主力工具，建好模型后导出 SQL，再放到数据库里去执行，整个过程能控制在十分钟以内。它链接分享的方式也很方便，把公开链接发给同学或者同事，对方在线就能查看 ER 图，省去发文件的来回沟通。

2.3 ERDCloud：完全开源、可自部署的团队协作型 ER 图设计工具

ERDCloud 是我最近一段时间用得最多的工具。它是真正意义上完全开源的 Web 端 ER 图设计工具，后端基于 Go 语言，前端使用 Vue，你可以在 GitHub 上找到完整源码，也可以直接用官方提供的公共网站。如果你在公司里想搭一套内部使用的数据库设计平台，它非常合适。

相比前两款工具，ERDCloud 的定位更垂直：它就是专门做数据库 ER 图设计的。它支持多种主流数据库，包括 MySQL、PostgreSQL、MariaDB、SQL Server 等，也支持通过连接数据库连接串直接反向生成 ER 图。当你输入数据库的连接信息以后，工具会连接远端数据库，自动读取里面的表、字段、主键、外键和索引信息，然后渲染成可视化的 ER 图。这意味着即使你手上没有建表 SQL，只要数据库在线，就能快速生成一份结构图，非常适合用来梳理老系统。

ERDCloud 的另一大特色是团队协作。它可以创建项目，邀请成员一起编辑同一个 ER 图，同时支持版本历史管理，改坏了可以回滚。这一点对团队开发非常有用，架构师画好总表结构，后端同学可以直接在图上补充字段说明，前后端都对数据库结构有一个共识，减少沟通成本。部署方面，官方提供 Docker 镜像，几行命令就能起一个服务，也可以部署到内网，数据安全完全自己掌控。

3. 实操过程与核心环节实现

3.1 用 ERDCloud 从零搭建一个数据库建模环境

我建议第一次接触 ERDCloud 的人先从官方的在线站点开始，因为不用配置环境，打开浏览器注册一个账号就能用。整个流程可以分为三个环节：创建工作区、导入表结构、调整关系图。

第一步，注册登录以后，点击创建一个新的“项目”，项目名称建议直接用你的数据库名或者业务模块名，这样后面分组管理比较清楚。ERDCloud 会引导你选择创建一个空白模型，或从数据库导入，或从 SQL 文件导入。如果你手里已经有建表 SQL 文件，直接选择“从 SQL 导入”是最快的。我用过的版本里，它支持 MySQL 方言的 CREATE TABLE 语句，大部分网上找的课设脚本都能导入成功，但存储过程、触发器这类内容不在 ER 图工具的处理范围内，它会自动忽略。

第二步，如果是直连数据库，你需要填 host、端口、数据库名、用户名和密码。这里有个关键细节：如果数据库服务器在内网，而 ERDCloud 部署在公网，连接很可能会超时，一般建议把 ERDCloud 部署在同一内网环境，或者使用 SSH 隧道。用官方在线站点连接本地数据库时经常报“connection refused”，不用怀疑是软件问题，大概率就是网络不通或者数据库没开远程访问权限。

第三步，导入之后你会看到左侧是所有表的列表，右侧是 ER 图画布。ERDCloud 会自动布局，但自动布局有时候会有线交叉，你可以手动拖拽调整实体框的位置。它可以显示字段类型、主键、外键、默认值、注释，建议把“注释”列打开，这样每张表的业务含义会比较直观。

如果你所在团队有自建服务的需求，官方仓库里有 Dockerfile 和 docker-compose 示例，一般只需要配置数据库连接信息和管理员账号，然后docker compose up -d就能跑起来。自己部署的好处除了数据不出内网，还可以让团队所有人免注册直接用内部 SSO 登录。

3.2 用 dbdiagram.io 通过 DBML 快速建模并导出 SQL

我个人非常喜欢 dbdiagram.io 这种“写代码出图”的方式，因为它的数据结构描述非常紧凑。一个简单的用户表和订单表示例的 DBML 长这样：

Table users { id integer [pk, increment] username varchar(50) [not null, unique] email varchar(100) [not null] created_at timestamp [default: `now()`] } Table orders { id integer [pk, increment] user_id integer [not null] amount decimal(10,2) [not null] status varchar(20) [default: 'pending'] created_at timestamp [default: `now()`] } Ref: orders.user_id > users.id

把这段代码粘贴到 dbdiagram.io 左侧编辑区，右侧会自动渲染出 users 和 orders 两张表，以及它们之间的外键关联连线。这里有几个细节值得注意：[pk]表示主键，[increment]表示自增，[not null]表示非空约束，Ref: orders.user_id > users.id表示订单表的 user_id 引用用户表的 id。你是通过文字描述来指定约束的，而不是靠鼠标点选，所以复查只需要读代码，很直观。

导出 SQL 也相当方便。点击左上角的 Export 按钮，选择 MySQL、PostgreSQL 或 SQL Server 等目标数据库，工具会生成对应的CREATE TABLE语句。如果后续表结构调整了，它还支持生成 ALTER 语句，不用人工比较差异。这个功能对于开发阶段反复微调表结构特别实用。

这里提醒一点：dbdiagram.io 免费版创建的 Diagram 默认是公开的，只要拿到链接谁都能看。如果你在课程设计里用了它，记得在导出 SQL 之后把链接设为私有，或者干脆把内容复制到本地保存，防止别人顺着链接看到你的设计稿。

3.3 用 draw.io 把已有 SQL 脚本变成 ER 图，适用于文档和答辩场景

draw.io 不支持直连数据库，它更擅长的工作是把一段建表 SQL 翻译成图。入口是顶部菜单 Arrange -> Insert -> Advanced -> SQL，或者在形状库中直接选择“SQL”图形。选择数据库类型为 MySQL（PostgreSQL 也支持，具体取决于版本），然后把 SQL 粘贴进去。

draw.io 会解析建表语句中的表名、字段名、主外键，并在画布上生成对应的表和连线。它生成的表结构比较“朴素”，如果你要用于正规的课程设计文档，可能需要统一调整一下样式，比如把表头背景色改成一致的颜色、把外键字段加粗标出来。好在 draw.io 的样式编辑功能非常强，选中元素后可以调整填充色、字体、边框等，修改完以后导出为 PNG 或 SVG 图片，放进论文或答辩 PPT 里都很清晰。

有一点要提前说明：draw.io 生成的“ER 图”更接近数据库表结构图，它不会自动把每个字段的“属性”单独画成椭圆。如果你要的是教科书里那种“实体-属性-联系”的标准 ER 图，还是需要自己在画布上补充属性节点和联系菱形节点。

4. 常见问题与排查技巧实录

4.1 连接数据库失败，先检查驱动、防火墙和认证插件

使用 ERDCloud 直连数据库的时候，连接失败是最常见的问题。我整理了一份排查顺序，下次遇到报错可以按这个来。

先看网络层。如果数据库跑在本地，而你是通过云服务器访问，默认 MySQL 地址通常是 127.0.0.1，外部根本连不上，需要改成 0.0.0.0 监听并配置防火墙规则。注意修改 bind-address 后要重启 MySQL 服务。接着看账号权限，确认你的数据库用户允许从某个主机连接，'user'@'localhost'和'user'@'%'是不同的概念，很多连接失败其实是授权表没写好。

然后看认证插件。MySQL 8.x 默认使用 caching_sha2_password 认证，一些老旧的驱动或工具可能不支持，具体表现为连接报错Authentication plugin 'caching_sha2_password' cannot be loaded。解决办法是在建账号时指定使用 mysql_native_password，或者在工具这边选择新版驱动。ERDCloud 这类基于 Go 的工具一般依赖新版驱动，理论上不冲突，但如果你用的是老版本部署，就可能踩到这个坑。

4.2 SQL 导入乱码和中文字段注释丢失，怎么处理

从 SQL 文件导入时，中文注释最容易出问题。乱码的根源一般是文件编码和工具默认编码不一致。建表 SQL 最稳妥的保存格式是 UTF-8，注意不是 UTF-8 with BOM。如果你用记事本保存带 BOM 的文件，部分解析器会把 BOM 当成立即字符显示成乱码，建议用 VSCode、Notepad++ 这类编辑器统一改成 UTF-8 无 BOM。

字段注释丢失的情况也有两种可能。一是原 SQL 里本来就没写 COMMENT，自然导入不到 ER 图里；二是工具解析时忽略了 COMMENT 子句。如果工具本身不支持解析 COMMENT，那只能手动在 ER 图里补注释，或者在导入前用文本处理把 COMMENT 信息提取出来。分享一下我的经验：dbdiagram.io 的 DBML 导入功能对 MySQL 的 COMMENT 支持得不错，ERDCloud 对常见 COMMENT 也支持，如果你用的是 draw.io，它只会生成字段名称，不显示注释，需要在后端表格里手动加说明。

4.3 表非常多时画布混乱，布局管理怎么做

导入几十张表以后，工具默认的自动布局经常让人一言难尽，线在图上绕来绕去，根本看不出业务分层。我用了几个工具后的心得是：ER 图不是越全越好，画布上展示的表越多，阅读成本越高。合理的做法是按业务模块拆分，不要把整库所有表都放到一张图上。

ERDCloud 和 dbdiagram.io 都支持按主题或者分组管理表，你可以把用户中心相关的表放一组，订单相关的表放另一组，每组单独出一张图。这样既方便汇报，也方便后面的评审。draw.io 虽然没有专门的分组概念，但你可以借助容器形状（Container）把相关表框起来，视觉上自然形成模块边界。布局的时候，尽量让关联关系紧密的表挨在一起，外键线越短越好，这样看图的人一眼就能抓住核心链路。

4.4 导出图片不清晰，答辩文档需要高分辨率配图怎么办

很多人在最终交文档的时候发现，从工具里导出的 PNG 图片放到 Word 或 PPT 里变得模糊，这是导出分辨率不够导致的。解决方式有两个思路。

一个是导出矢量图。draw.io 和 ERDCloud 都支持导出 SVG 格式，矢量图放大多少倍都不会失真，插入 Word 时建议用“插入图片”而不是直接复制粘贴，因为直接粘贴有时会被转成位图。另一个是提高导出分辨率，dbdiagram.io 的导出选项中一般可以设置缩放比例，比如把 Scale 调到 200% 或 300% 再导出 PNG，图片尺寸会成倍增加。

如果图片已经导出了但依然不够清楚，还有一个偏方：在浏览器中按 Ctrl + 加号把页面放大，然后再用浏览器截图工具截图。这样截出来的图分辨率会更高，虽然不算正规做法，但在时间紧急的时候能救急。

注意：无论用哪种方式导出，最终插入文档前，建议把图片边缘多余的白边裁剪掉。很多工具导出时会在四周留下大块空白，既占版面也不美观。

5. 选型建议与我的日常工作流

这三款工具我用下来的感受是：它们不冲突，反而可以组合成一条高效的数据库设计流水线。

给我的读者一个直接的建议：如果你只想要一个工具解决“从数据库生成 ER 图”这个需求，优先选 ERDCloud；如果你习惯写代码、希望快速从模型导出 SQL，优先选 dbdiagram.io；如果你要的是一份可以放进论文或答辩 PPT 的精美通用图形，优先选 draw.io。

我目前的日常工作流是这样的：项目一开始，用 dbdiagram.io 通过 DBML 快速定义表结构，迭代出第一版模型；确认字段和关系后，导出 MySQL 建表 SQL，在数据库里执行；数据库部署好以后，再用 ERDCloud 连接数据库，反向生成一份 ER 图，作为团队内部同步的文档；等到写技术方案文档或者评审汇报的时候，才会用 draw.io 对特定模块的 ER 图进行美化，导出高清配图。

这个流程其实有一个核心思想：工具不是目的，数据库结构才是资产。任何 ER 图都是表结构的投影，如果表结构和 ER 图脱节，那这张图只是废纸。所以我强烈建议你形成习惯，表结构变更之后第一时间同步更新 ER 图，不要让图和库慢慢变得不一致。

最后分享一个小技巧：无论你用哪款工具，数据库设计阶段都把注释写完整，包括表注释和字段注释。这样 ER 图工具在反向导入的时候才能把业务含义展示出来，不然生成的图上只有一个一个干巴巴的英文字段名，过一个月连你自己都看不懂这是干什么的。好的注释，是比任何工具都重要的资产。