企业官网建设流程全解析

做数据库设计的人，大概都经历过那种尴尬：表结构改了三轮，ER 图还停留在最老的版本上。我最近整理一个老项目的数据库文档，20 多张表的字段、外键、索引都要梳理清楚，还得画一张能放进 PPT 的数据库 ER 图。翻了一圈手头能用的工具，要么是客户端软件要装驱动，要么是商业授权收费，最后我把目光锁在三款 Web 端可用的开源数据库 ER 图设计工具上。这篇文章就把我的实测体验完整写出来：选型思路、每款工具怎么上手、适合什么场景、会踩哪些坑，一次讲透。

1. 先想清楚：你需要的到底是“画图”还是“建模”

1.1 ER 图工具和普通绘图工具的本质区别

很多新人第一次接触 ER 图，第一反应是打开 PPT 或者在线白板开始画矩形、拉箭头。画几张小表没问题，一旦表超过十张，字段超过三五十个，白板式画法就完全失控了：框线对不齐，字体改到怀疑人生，同事改了一个字段名，你整个图都要手动同步。

真正的数据库 ER 图设计工具，核心价值在于它能理解“实体、属性、关系”这三层语义。它知道你画的那个矩形是一张表，矩形的每一行是一个字段，表与表之间的连线是外键关联，连线的端点还能表达基数关系：一对一、一对多、多对多。只有理解了这些语义，工具才能帮你从建表 SQL 自动生成模型图，或者反过来，从模型图自动生成建表 SQL。这就是“绘图工具”和“建模工具”的分水岭。

所以在选工具之前，你得先问自己一个问题：我画这张 ER 图，是为了给人看，还是为了给数据库用？如果只是给同事讲清楚表结构，普通绘图工具勉强够用；如果要让图成为数据库开发的依据，那必须具备 SQL 导入导出能力。

1.2 为什么我坚持用 Web 端开源方案

这次选型我给自己定了两个硬条件：必须 Web 端可用，必须开源。

Web 端可用意味着不用装客户端，换电脑、换系统、临时在会议室机器上演示，打开浏览器就能干活。团队里如果有人只是看看图、提个意见，也不需要为 ta 专门装一套建模软件。开源意味着工具本身免费，协议允许商用，代码被人审计过，不用担心上传的建表语句被人拿去训练模型或者卖数据。更要紧的是，开源项目通常可以私有化部署到内网，对数据敏感的业务来说，这是商业 SaaS 很难替代的优势。

当然，Web 端开源方案也有代价：功能丰富程度通常比不过商业客户端，一些复杂建模能力要自己折腾。但对我日常梳理表结构、输出文档、做课程设计这类需求来说，已经绰绰有余了。

1.3 三类典型使用场景

我这次梳理下来，发现需要 ER 图的人大概分三类，工具选择完全不同。

第一类是“展示型需求”，比如给新同事做数据库培训、给项目答辩做 PPT、给领导汇报表结构设计。这类场景看重的是图要好看、清晰、容易调整布局，最好能直接导出 PNG、SVG。

第二类是“文档型需求”，比如把 ER 图写进项目 README、写进接口文档、放进代码仓库跟着版本走。这类场景看重的是文本化、可 diff、可自动渲染，不需要手动拖拽布局。

第三类是“设计型需求”，比如新项目从零开始建表，要先画模型、讨论字段、确认外键关系，再生成建表脚本。这类场景看重的是 SQL 导入导出能力、字段类型支持、以及增量修改的便利性。

我选出的三款工具，恰好分别对应这三类场景。接下来一个个说。

2. 三款工具实测：diagrams.net、Mermaid、erd-editor

2.1 diagrams.net：全能型选手，逆向生成 ER 图利器

diagrams.net 这个工具老读者应该不陌生，它以前叫 draw.io，后来改了名字，在线版地址是 app.diagrams.net，桌面版和在线版并存，开源协议是 Apache 2.0，代码在 GitHub 上可以找到。

说它是“全能型选手”，是因为它的定位是一个通用图表绘制工具，不只是画 ER 图。UML、流程图、架构图、思维导图、原型图它都能画。你要做 ER 图，打开软件之后在左侧图形库里勾选“Entity Relation”或者“UML”相关的图形组，就能找到常用的实体框、主键标记、关系连线。

我实测最顺手的一条路径是逆向导入：数据库里已经有一堆表，我想快速生成对应的 ER 图。diagrams.net 提供了从 SQL 插入的功能，入口在菜单栏 Extras 下面，叫 Insert from SQL。点开之后，选好数据库方言，我通常选 MySQL，然后把建表语句粘贴进去，点插入，工具会自动解析出实体框，每个实体框里带着字段名和字段类型。如果 SQL 里写了外键，它还能自动生成关系连线，省掉大量手工拖线的功夫。

举个例子，我有一段最简单的两张表建表语句：

CREATE TABLE users ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, email VARCHAR(100) UNIQUE ); CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, total_amount DECIMAL(10,2), created_at DATETIME, CONSTRAINT fk_orders_user FOREIGN KEY (user_id) REFERENCES users(id) );

粘贴进去之后，diagrams.net 会生成 users 和 orders 两个实体框，orders 表里有 user_id 字段，外键连线也会一并出现。对于二十几张表，生成出来的图通常比较乱，需要手工整理位置、调整分组，但总比从零开始画省力得多。

反过来，如果你处于正向设计阶段，想先在图上画好模型再生成 SQL，diagrams.net 也能做。在 Extras 菜单里能找到编辑 SQL 配置的相关入口，配置好生成规则之后，它能把图形里的表结构转换成 DDL 脚本。不过说实话，这个方向不如专业建模工具顺滑，我更推荐在逆向导入的场景用它。

优点很突出：免费、跨平台、无需注册、图形样式丰富、支持导出 PNG/SVG/PDF，还能对接 GitHub、GitLab、Google Drive 等存储，方便团队共享。缺点也很明显：它毕竟不是专门为数据库建模设计的，字段类型校验、主外键语义、基数标记这些都需要自己维护，图一旦大了，布局整理非常费时间。

2.2 Mermaid：代码即图形，把 ER 图写进 Git 文档

第二款是 Mermaid，准确说它是一个基于文本的图表渲染引擎，开源协议是 MIT。它本身不提供图形化的拖拽界面，而是用类似 Markdown 的文本语法描述图表，然后渲染成 SVG 或 PNG。在线编辑器 mermaid.live 可以直接在浏览器里写文本看效果，也可以导出图片。

我第一次用 Mermaid 画 ER 图时觉得特别神奇：不需要拖框、不需要连线，只要把实体和关系用文本写出来，它就能自动排版、自动布局。这对于习惯写代码的人来说，比任何图形化工具都顺手。

Mermaid 画 ER 图用的是 erDiagram 关键字，实体定义放在大括号里，字段可以用 PK、FK、UK 标记主键、外键和唯一键，实体之间的关系用一组字符组合表达。我直接贴一段实测过的示例：

erDiagram CUSTOMER ||--o{ ORDER : "places" ORDER ||--|{ ORDER_ITEM : "contains" PRODUCT ||--o{ ORDER_ITEM : "is included in" CUSTOMER { int customer_id PK string name UK string email } ORDER { int order_id PK int customer_id FK datetime created_at } ORDER_ITEM { int order_item_id PK int order_id FK int product_id FK int quantity } PRODUCT { int product_id PK string name decimal price }

这段文本放到 mermaid.live 里，渲染出来的图有四个实体框，字段、主外键都标得清清楚楚，三对关系也会自动连线。特别适合直接写进 README、GitHub Wiki 或者 GitLab 的 Markdown 文档里，任何人打开仓库都能看到最新的 ER 图。

这里我踩过一个大坑，必须提醒你：Mermaid 的关系符号是有方向的，||--o{这种写法，左边是“一”端，右边是“多”端。最常见的CUSTOMER ||--o{ ORDER读作“一个客户可以有零个或多个订单”，语序是父实体在左、子实体在右。如果你把方向写反了，渲染出来的关系语义就完全反了，尤其是多对多关系拆成中间表的时候，稍微不留神就把外键指反了。

另外一个有意思的点是，GitHub 和 GitLab 原生支持渲染 Mermaid 代码块，也就是说你把带 ```mermaid 的代码块提交到仓库里，在网页上打开这个文件时图表直接就显示出来了，不需要任何插件。这一点对团队协作简直友好到不行：ER 图跟着代码走，Review 的时候谁改了哪个表、加了哪个字段，在 diff 里看得一清二楚。

Mermaid 的短板在于它是“自动布局”，你没法手工拖动某个实体到指定位置，微调排版的能力很弱。实体一多，布局会显得比较密，关系线交叉也难免。另外，实体名和字段名的取值字符有一定限制，如果表名带括号、引号、特殊符号，需要按文档要求加双引号；中文字段名在部分版本里会渲染异常，我实际处理时习惯用英文表名和字段名，中文含义单独写注释。

如果你追求的是“一张图在文档里永远不过期”，Mermaid 是目前最省心的方案，没有之一。

2.3 erd-editor：为数据库建模而生的 Web 编辑器

第三款是我这次新发现的开源工具，GitHub 上叫 erd-editor，是一款专门的 ER 图 Web 编辑器。它的定位和 diagrams.net 完全不同，它是一个垂直的数据库建模工具，打开网页就能看到左侧的实体列表、中间的画布、右侧的属性面板，整个界面更像 Navicat 这类数据库客户端的模型设计器。

我是在搜索“开源 ER 图工具”的时候翻到它的，仓库地址在 GitHub 的 erd-editor/erd-editor，MIT 协议。它支持从数据库连接信息直连、也支持直接粘贴 DDL 文本，实测中我用得最多的还是粘贴 DDL。

操作流程很直观：打开在线页面，新建一个模型，然后在左上角找到导入 SQL 的入口，选择 MySQL 方言，把建表语句粘贴进去，点一下解析，画布上就会自动生成各个实体框，表名、字段名、字段类型、主外键标识都排得整整齐齐，外键关系线也会自动连线。后续你可以拖拽实体框调整位置，右侧属性面板里改字段名、改类型、加注释，一切操作都是可视化响应。

导出方面，它支持导出 PNG、SVG 等图片格式，也支持导出 SQL DDL。这点很实用：我先在 erd-editor 里把新项目的模型画好，确认无误后导出建表 SQL，再扔到数据库里执行，整个流程比手写 DDL 稳得多。

我实际操作的一个场景是帮一个课程设计团队整理数据库模型。他们的表结构前前后后改了五六版，每次改都靠口头沟通，经常 A 改了 users 表、B 不知道，两边 SQL 对不上。我把他们的历史 SQL 导入 erd-editor，生成一张总览图发到群里，后面每次改动先在工具里改模型、导出 SQL、再发变更说明，沟通成本明显降下来了。

优点方面，erd-editor 对“数据库建模”这件事的理解比通用绘图工具深很多，像是字段类型下拉选择、主外键标识、索引标记这些细节都做得比较到位，而且它也支持连接真实数据库做反向工程。缺点方面，项目的社区规模相对小，中文资料少，个别数据库方言的边缘类型可能解析不了，我导入 Oracle 的某些脚本时就遇到过类型识别异常，需要手工修正。

如果你主要工作是数据库结构的设计和维护，不是偶尔画两张示意图，erd-editor 值得放进收藏夹。

3. 三款工具横向对比与选型建议

3.1 一张表看懂差异

为了更直观地比较，我把三款工具的核心参数整理成一张表。这里的“协作方式”我指的是多人同时维护同一份模型的方式，不是说实时协作编辑。

这张表基本把三款工具的性格差别体现出来了。diagrams.net 强在外观和通用性，Mermaid 强在文本化和版本管理，erd-editor 强在建模语义和 SQL 往返能力。

3.2 按场景选型，不纠结

如果你现在只想快速把现有数据库的表结构画成一张图，发给同事或者放进 PPT，直接选 diagrams.net。它的 SQL 导入入口最好找，图形样式也最多，画出来的图比较符合大众审美。唯一的心理准备是：导入之后布局会比较乱，你要预留半小时左右整理。

如果你是开发者，想把 ER 图沉淀到代码仓库里，以后每次表结构变更都跟着代码提交、在线上文档里直接渲染成图，那就用 Mermaid。你不用考虑布局，只要维护文本，Git 天然帮你记录了每一版变更。缺点是它不适合精细排版，复杂模型的阅读体验弱一些。

如果你是在做新项目的数据库设计，需要频繁调整字段、讨论外键关系，还要生成建表脚本，erd-editor 最合适。它的建模语义会让你非常舒服，改字段类型、换主键、加索引这些操作远比在通用画图工具里改矩形舒服。需要注意的是，它的在线版本适合小项目和个人使用，如果数据非常敏感，建议部署到内网再用。

我自己现在的组合方式是这样的：新项目用 erd-editor 做正向建模，画图、改字段、导 SQL 一条龙；确认稳定之后，把最终模型转成 Mermaid 文本写进 README，保证文档里的 ER 图永远跟代码走。diagrams.net 则用来做临时的、对外展示的图，比如培训材料、答辩 PPT。

4. 实操中的常见坑与排查技巧

4.1 diagrams.net 的 SQL 导入并不是万能解析器

用 diagrams.net 从 SQL 生成 ER 图，最常遇到的问题有三个。

第一是方言不匹配。同一个 DDL，MySQL 和 PostgreSQL 的写法差异很大，比如 PostgreSQL 的 SERIAL 类型、JSONB 类型，如果你在对话框里选的是 MySQL 方言，解析结果就会残缺。解决方法是导入前先确认你要导入的脚本到底属于哪种数据库，选对语言再粘贴。

第二是外键关系识别不出来。很多现有项目的建表脚本里，外键并不一定写在 CREATE TABLE 里，而是后面单独用 ALTER TABLE 添加。diagrams.net 解析这种脚本时，实体框能生成，关系线却可能漏掉。我的排查方法是不只靠工具自动连线，导入完成后自己对着数据库外键清单过一遍，缺哪条线手动补上。

第三是复杂类型的显示问题。比如字段类型带长度、带 unsigned、带注释，导入后实体框里的文字又长又乱。这种没有特别好的办法，只能接受它，毕竟工具只是帮你快速生成一个底稿，不是最终成品，整理布局和精简显示还是得人工来。

4.2 Mermaid 的关系语法最容易搞反

Mermaid 的 ER 图语法本身不难，难的是把关系语义写对。我第一次写多对多关系的时候，老老实实建了中间表 ORDER_ITEM，结果关系连线全画反了，后来才发现问题出在方向理解上。

常见的几个关系符号，我建议直接记住这张表：

核心记忆方法是：竖线越多，约束越严格；字母 o 表示可选项；花括号 { 表示“多”。写关系的时候，把父实体写在左边、子实体写在右边，形成“一 对 多”的习惯，能够减少大部分错误。

另一个 mermaid 的坑是特殊字符。如果表名是order这种跟关键字重叠的词，或者是user info这种带空格的词，直接用是不行的，需要给实体名加双引号。字段名同理。写中文表名在我测试的版本里也能渲染，但有边界情况会失败，为了稳妥，我建议实体和字段统一用英文，中文注释放在实体描述里，或者干脆写在文档正文中。

4.3 erd-editor 部署与协作注意事项

erd-editor 的在线版本用起来很方便，但有一个事我特别想提醒：不要随手把含敏感表结构的 SQL 直接粘贴到第三方在线页面上。数据库表结构本身属于重要的业务信息，用户表、订单表、支付表的字段设计，逆向推导出业务逻辑一点都不难。如果你在给企业做项目，或者涉及真实业务数据，务必优先选择内网部署或离线使用的方式。

GitHub 仓库里提供了自部署的路径，前端构建产物可以托管在任何静态服务上，也支持 Docker 方式一键起服务。我在内网服务器上部署过一次，过程不复杂，之后访问的就是内网地址，数据不经过公网，心里踏实很多。

还有一个小建议：不管用哪款工具，ER 图画完之后最好导出一次 PDF 或者 PNG 存档。尤其是做课程设计或者项目验收的时候，有图有真相，等到答辩前一晚再发现图丢了，那个滋味不好受。我自己吃过这个亏，现在养成了每周五把画布导出备份的习惯。

4.4 一张问题速查表

最后把我实际踩过的一些高频问题整理成速查表，方便你在现场直接对着排查。

5. 最后说点我自己的使用体会

工具这东西，没有绝对的好坏，只有合不合适。我这次从需求出发筛完一圈，最大的感受是：三款工具并不冲突，它们分别解决“画得好看”“改得方便”“建得专业”这三种诉求，关键看你在什么阶段需要什么。

如果你现在正被一堆表结构搞得焦头烂额，我的建议是从 diagrams.net 开始，先把你现有的表导入成图，对全局有个直观认识。等你想把这份资产长期维护起来，再引入 Mermaid 写进文档。真正开始新项目设计时，erd-editor 会是你的得力帮手。

最后还是那句老话：再好的工具也只是手段，把数据库关系想明白、把需求对齐，才是真正的核心。工具能帮你节省画图的时间，却不能替你做设计决策。希望这篇文章能让你少走点弯路，选到趁手的那一款。