企业官网建设流程全解析

1. 我为什么说diagram-design的核心不是"画"而是"想"

先说一个我自己的真实经历。去年某次架构评审会上，团队里一位后端同学投出了一张他花了两天时间画出来的系统架构图，色彩丰富、图标精致、连接线还带渐变。结果不到三分钟，评审组长打断他："你这个箭头是表示调用关系，还是数据流向？这个框为什么会同时出现在两层里？"他支吾了半天没解释清楚，最后只能说"我回头再调整一下"。

这个场景我想很多人都不陌生。问题出在哪？不是工具用得不好，也不是他不努力，而是他从一开始就跳过了"设计思考"这一步，直接进入了"画图"环节。diagram-design这个词，拆开看是diagram（图表）加design（设计），但绝大多数人只做到了前半段——把信息堆进画布里，却没有做后半段——对信息进行取舍、分层、组织、视觉编码。

这篇文章我想认真聊一聊，一张好图到底是怎么"设计"出来的。它适合谁看？如果你是经常需要画架构图的后端研发、要梳理业务流程的产品经理、做数据建模的数据工程师，或者你只是受够了被同事吐槽"你这张图我看不懂"，那这篇文章就是写给你的。我不会只讲空泛的设计原则，而是从需求梳理、图表选型、视觉规范到工具链选择，把整套方法和踩过的坑一次讲透。

还有一个重要前提：你不需要会手绘，也不需要美学天赋。diagram-design是一套可以按步骤执行的方法论，只要照做，产出的图就能达到"让外行看得懂、让内行觉得专业"的水准。

2. 最容易被忽略的一步：画图前的信息架构梳理

很多人拿起工具就开画，这是diagram-design里最致命的一个习惯。图本质上是"对信息的一种压缩表达"，如果你连自己手里有什么信息、哪些信息重要、哪些信息可以丢掉都没想清楚，画出来的东西必然是一盘散沙。

2.1 一图一主题，先定主谓宾

我在动笔之前，永远先强迫自己用一句话说清楚这张图要表达什么。这就是"一图一主题"原则。注意，是一句话，不是一段话。比如：

• 错的表述："我要画一下我们这个订单系统"
• 对的表述："这张图要展示一条订单从创建到结算的完整生命周期，重点标出异常退款路径"

看出差别了吗？前者是一个模糊的领域，后者是一个明确的逻辑命题。这个命题就像作文的立意，后续所有信息都必须围绕它服务，跟它无关的，再重要的功能也要狠心删掉。

2.2 用"重要性分级"代替"全部画上去"

信息架构梳理有一个很实用的操作方法，叫"三级信息划分"。准备一张纸或一个文档，把跟主题相关的所有信息全部列出来，然后逐个归类：

我在画微服务架构图的时候，刚开始总是忍不住把每台服务器的配置、每个中间件的版本、每处调用的端口号都堆上去。后来发现，读者根本记不住，图还变得极其拥挤。现在我会默认把P2信息全部移除，只在图下方的备注区用一行小字带过。

2.3 五步信息梳理法：实操流程

基于上面的原则，我整理出一套五步法。每次画图之前，我都会走完这五步，整个过程通常控制在二十分钟以内，但能省下后面几个小时的返工时间：

1. 列出全部事实。不带任何取舍地把跟主题有关的信息全部写下来，用列表就行。
2. 识别逻辑主线。问自己"读者看完这张图，我希望他记住什么"，把这个答案标记为主干。
3. 信息分级。逐条标记P0、P1、P2。
4. 寻找层级关系。P0信息里哪些是父子关系、哪些是兄弟关系、哪些是依赖关系，这一步会直接决定后面的布局。
5. 写一份"图例草稿"。用文字描述"图的左边是什么、右边是什么、从上往下怎么流动"，这相当于建图前的施工图纸。

这套方法我称之为"先写后画"。如果你发现自己还没写清楚，就已经打开了画图工具，那基本可以判断，后面一定会出现返工。

3. 图表类型选错，画得越精细错得越离谱

选图表类型这件事，看起来是个不起眼的决定，实际上决定了整张图的表达逻辑。类型选错了，后期再漂亮的视觉都救不回来。这就像你用螺丝刀去锤钉子，工具本身没问题，方向全错了。

3.1 六种最常见的diagram类型和应用场景

我根据自己的使用频率，把日常工作中最常用的图表类型梳理成一张表：

3.2 一个真实的选型翻车案例

去年我们做一个数据中台项目，有位同事要展示"数据从采集到应用的完整链路"，他画了一张精密的架构图，各层分得清清楚楚。但评审的时候，领导问了一个问题："这个链路中哪一步是可能导致数据延迟的瓶颈？"架构图根本回答不了这个问题，因为它表达的是静态关系，不是时间流动。

正确做法是画一张泳道图，横向泳道分配给各个系统，纵向能清晰看到数据在每个环节的停留和流转，瓶颈自然暴露出来。后来我们把这张图重画了，问题一眼就被发现了。

这个案例给我的启示是：选类型之前，先确认你要表达的"逻辑主谓宾"中的动词是什么。如果动词是"调用、依赖、包含"，用架构图；如果动词是"流转、判断、流转到"，用流程图或泳道图；如果动词是"按顺序交互"，用时序图；如果动词是"更新、触发、变更为"，用状态图。

3.3 组合使用的进阶做法

实际工作中，复杂业务经常需要多图组合。我见过比较优秀的做法，不是把N种信息硬塞进一张图，而是把一张"总览图"加若干张"局部细节图"结合起来。总览图只画P0信息，建立全局认知；局部图针对某个复杂环节单独展开。

比如订单系统，可以先画一张简洁的状态机图表达订单状态流转，再单独画一张时序图表达下单场景下各服务的调用顺序。两张图各司其职，比硬塞进一张大图清晰得多。这种"一总多分"的组合，是我个人最推荐的信息表达方式。

4. 视觉规范：决定你是"专业选手"还是"业余玩家"的分水岭

信息结构对了、图表类型选对了，图其实已经完成了百分之六十。剩下百分之四十，考验的是视觉表达能力。很多人的图一眼看过去就很"业余"，往往不是内容错，而是视觉层面犯了低级错误。

4.1 网格系统：所有元素都要有"落点"

我见过最典型的"业余感"来源就是元素摆放错落无致。两个相邻的框间距忽大忽小，框和框之间没有对齐关系，整张图看起来像随手撒上去的。

解决办法很简单：心里始终有一张隐形网格。所有框体要么左对齐、要么居中对齐、要么沿同一水平线排列；同层级的元素间距保持一致；连线尽量走水平或垂直方向，不要出现莫名其妙的斜线。

我在用画布类工具的时候，习惯先设置好网格吸附。比如Draw.io里把Grid设为10px并开启Snap to grid，Figma里则是用Smart Selection调整间距。这类小设置能保证你画出天然规整的图，不需要事后手工微调。

4.2 配色的"三色原则"和语义化用色

颜色是diagram-design里最容易被滥用的元素。一张图超过五种颜色，基本就会开始制造视觉噪音。我用的是"三色原则"：

• 主色：用于核心模块、主要流程，比如深蓝或深绿
• 辅助色：用于支撑模块，比如比主色浅一到两个明度的灰蓝
• 强调色：只用于异常路径、重点模块、警示信息，比如橙色或红色

还有一个很重要的点：颜色必须是语义化的，不能是装饰性的。也就是说，看到某种颜色，读者应该能联想到它的含义。比如所有"危险/异常"节点统一用红色，所有"外部依赖"统一用灰色，而不是因为"这个颜色好看"才用。

我在团队里推行过一份简单的配色约定，效果立竿见影：主流程蓝、支撑模块浅灰蓝、外部系统白底灰色虚线框、异常路径红色、注释文字深灰。所有成员画出来的图放在一起，风格统一得像同一个人的作品。

4.3 连接线的语义：箭头比线型先说话

连接线是图里最容易被随意对待的元素，但它的语义准确性直接决定了图的专业度。我总结出三条铁律：

• 有方向的箭头必须表达明确的动词关系。不要画一条没有箭头的线表示"有关系"，读者会猜"到底是谁依赖谁"。
• 不同箭头样式要有明确约定。实线箭头表示"调用/依赖"，虚线箭头表示"回调/异步通知"，空心箭头表示"继承/实现"。全图画完后，在左下角放一个图例，防止读者误读。
• 连线不要穿过其他模块。宁可在画布上绕行，也不要用线直接穿框，穿线是业余图最明显的特征之一。

关于自动布局工具，Mermaid这类代码型工具有时候会自动生成折线，我一般会调整一下路由方式。比如Mermaid里可以用flowchart LR加手动定义的边去控制线的出口和入口方向，虽然麻烦一点，但线的走向会清晰很多。

4.4 分层与聚类的视觉表达技巧

架构图里最常见的是"分层表达"。我的做法是：每个层使用一个大的背景色块作为容器，层内模块放在这个色块里，层与层之间用明确的留白分割。这样读者一眼就能识别出层级结构，不需要逐字读文字。

这里有个细节很多人会忽略：层背景色的透明度不要太高。透明度低于百分之十几乎看不出来，高于百分之三十又会干扰内部文字的可读性。我一般控制在百分之十五左右，既能看到分层边界，又不抢夺内部内容的视觉权重。

分组同理。如果某几个模块之间关系紧密，用虚线框括起来，比硬塞进一个实线框要更合适。虚线框自带"这是一个逻辑分组，不是物理边界"的语义。

5. 工具链选择：代码型还是画布型，取决于使用场景

关于diagram工具，市面上的选择五花八门。我在不同阶段用过Visio、ProcessOn、Draw.io、Figma、Excalidraw、Mermaid、PlantUML、Graphviz，各有各的适用场景。这一节我直接给结论和选型建议，不铺开讲功能清单。

5.1 两大类工具的对比

先给一张对比表，后续再逐个拆解：

5.2 我的主力组合：Mermaid加Excalidraw

个人主力工具是双轨制。需要放进技术方案文档或仓库README的图，我用Mermaid。理由很简单：文本即图，改起来飞快，还能跟代码一起走Code Review。

比如一个订单状态的流转，用Mermaid写出来就是一个文本文件，评审意见直接在PR里提"把'待支付'到'已取消'那行加个超时条件"，比在画布上等同事改完再截图高效得多。

需要做对外汇报、需要精细控制版式的时候，我用Excalidraw。它手绘风格的线条和框架，天然适合演示场景，而且多人协作体验很好。Excalidraw搭配它的网格吸附和Arrow系统，画出来的图自带一种干净的手绘感，比像素级对齐的Figma更有人情味。

PlantUML我偶尔用于时序图。它的时序图语法支持非常完备，能精确表达激活条、异步消息、组合片段。Mermaid的时序图虽然也在进步，但复杂交互表达上，PlantUML还是更成熟一些。Graphviz我只在需要自动布局树形结构或复杂图结构的时候用。它的dot语言能自动做布局计算，虽然默认排版偶尔需要手工调，但在大数据量图面前，自动布局是唯一可行的方案。

5.3 工具选型的三个决策条件

如果你还在纠结用哪个，不妨按以下三个条件筛选：

1. 图的更新频率是高是低。频繁改动的图，选代码型；一次性定稿的图，选画布型。
2. 使用人群是开发为主还是混合团队。开发多用Mermaid不会造成协作阻碍；混合团队建议选画布型，代码门槛会把非技术同事挡在外面。
3. 使用场景是文档沉淀还是现场汇报。文档内嵌图优先考虑代码型，便于后续维护；现场汇报需要视觉冲击力，必须用画布型。

6. 两个从0到1的实战案例，完整走一遍设计流程

这一节我把前面所有理论方法落到两个完整案例里。案例选取的是日常工作中最高频的两类需求：业务流程图和系统架构图。

6.1 实战一：订单退货链路流程图

需求背景：电商后端要做一次退货流程优化，我需要画一张"用户发起退货到退款到账"的流程图，用于评审会展示。

第一步，信息梳理。我列出了全部事实：用户发起退货、填写原因、上传凭证、商家审核、审核通过/驳回、用户寄回商品、商家验收、验收通过/拒收、退款原路返回、退款到账通知、超时自动通过。

第二步，识别主线。这张图的核心逻辑是"退货流程状态流转"，动词是"流转、判断、变更"。所以用流程图来表达，重点突出审核和验收两个决策分叉。

第三步，分级。P0信息是完整状态路径和两个判断分支；P1信息是"上传凭证"这种支撑操作；P2信息是超时策略。

第四步，写Mermaid代码。核心代码如下：

flowchart TD A[用户发起退货] --> B[填写退货原因并上传凭证] B --> C{商家审核} C -->|驳回| D[订单关闭，退回原状态] C -->|通过| E[用户寄回商品] subgraph 验收阶段 E --> F{商家验收} F -->|验收通过| G[退款原路返回] F -->|拒收| H[订单重新打开，进入争议流程] end G --> I[退款到账通知用户] H --> F

注意上面代码块里的语言标记我故意写成mermaid，但实际渲染出来之后，我用这些细节控制整体观感：

• 判断节点全部用菱形，并给每个分支加上明确的标签文字。
• 验收阶段做成单独的subgraph，从视觉上表达这是流程里的独立阶段。
• 拒收分支回流到原节点，用一条虚线边表达"重新进入验收"，避免和主流程的实线混淆。

第五步，评审验证。画完之后我习惯做一个自查：把图给一个不熟悉业务的人看，让他讲一遍他理解的故事。如果讲出来的方向和我的意图一致，说明图是成功的。

6.2 实战二：一个微服务系统的架构图

需求背景：新项目立项，需要一张微服务架构图给团队和技术委员会看清楚系统的整体结构。

第一步，确定主题句："这张图展示XX业务系统分四层部署的服务结构和调用关系，重点标出基础服务层的通用依赖。"所以这张图的动词是"分层、依赖、调用"，选架构图。

第二步，信息分层。我把核心服务分成了四层：接入层（网关/鉴权）、业务层（订单/用户/商品）、基础服务层（消息/缓存/文件）、数据层（MySQL/Redis/ES）。

第三步，分级。P0信息是四层结构和层之间的依赖关系；P1信息是各层内部的细分服务名称；P2信息是数据库的主从配置、具体的端口号。

第四步，代码实现。这里我用嵌套subgraph表达分层：

flowchart TB subgraph 接入层 A1[API Gateway] A2[Auth Service] end subgraph 业务层 B1[Order Service] B2[User Service] B3[Product Service] end subgraph 基础服务层 C1[Message Queue] C2[Cache Cluster] C3[File Storage] end subgraph 数据层 D1[(MySQL Cluster)] D2[(Redis Cluster)] D3[(ES Cluster)] end A1 --> B1 A1 --> B2 A1 --> B3 B1 --> C1 B2 --> C1 B3 --> C2 B1 --> C3 B1 --> D1 B2 --> D2 B3 --> D2

第五步，视觉与配色。渲染完成后，我在Excalidraw里把它重新精修了一版。层背景色使用深浅递进的不同蓝色，强调基础服务层是所有业务服务的公共依赖，用浅橙底色单独标出。外部系统用虚线框括起来。整体颜色控制在四种以内。

6.3 实战复盘：两张图暴露出的共同陷阱

每次画完图我都会问自己一个问题：如果三个月后的我回头看这张图，能不能在三秒钟内抓住重点？如果回答犹豫了，说明图的结构还需要优化。

这两个案例反复出现的陷阱有两个。第一个是连接线的"万箭齐发"问题——框里的每个角都伸出连线，视觉极度混乱。我的对策是统一连线的出口方向。比如"业务层到基础服务层"的调用，全部从下层框的顶部出线，上层框的底部入线。这样线就形成了统一的瀑布流效果，图面立刻整洁很多。

第二个陷阱是"图例缺失"。无论是流程图里的箭头语义还是架构图里的颜色含义，都会在第二张图之后开始混乱。我现在画完图的第一件事就是在左下角补上图例，哪怕只是三行文字：实线=同步调用、虚线=异步通知、红色=异常链路。这个小习惯帮我和读者都省了不少沟通成本。

最后的经验之谈

diagram-design真正磨人的不是某一个环节，而是每个环节都不出错。我见过太多人卡在"工具熟练但图很乱"的瓶颈期，其实根源就是跳过了信息架构和图表选型这两步，直接扎进了视觉细节里。

我个人这几年最大的改变是：把画图从"表达过程"变成了"思考工具"。一张图如果画不出来，往往不是因为工具不会用，而是因为思路还没理清。所以现在遇到复杂问题，我的第一反应不是写文档，而是尝试用一张图把自己的理解画出来。画到一半发现某个关系解释不通，那就是系统设计本身出了问题。这种思维转变，比任何工具技巧都更有价值。

最后再分享一个特别实用的检查习惯：每次准备把图发出去之前，把画面缩小到原来的百分之五十，看看还能不能一眼分清主要结构。如果缩到一半就变成一坨色块，说明图中信息密度太高，需要拆分或删减。这个方法帮我砍掉了无数张冗余的连接线，推荐你试一试。