企业官网建设流程全解析

1. 从"diagram-design"这个标题说起：它到底在解决什么问题

第一次看到"diagram-design"这个标题，我脑子里冒出来的第一个念头是：这大概率不是一个单纯的"画图工具"，而是一套关于"如何把复杂信息用图形讲清楚"的方法论。为什么这么说？因为如果只是画图，标题通常会叫"diagram-tool"或者"chart-library"；而"design"这个词的出现，意味着重点在于设计决策——什么时候用流程图、什么时候用架构图、节点怎么排布、颜色怎么分配、信息密度怎么控制。

我在实际工作中接触过大量"图"的需求：技术方案评审要画架构图，产品需求评审要画流程图，给非技术同事讲系统要画数据流图，写文档要画状态机图。几乎每一次，真正让人头疼的都不是"用什么工具画"，而是"这张图到底该怎么设计才能让人一眼看懂"。工具只是载体，设计才是核心。这就是"diagram-design"这个主题的价值所在——它关注的是一张图从"信息"到"可读图形"的转化过程。

这篇文章适合几类人看：一是经常需要画技术图但总觉得画出来"不够专业"的开发者；二是需要给团队输出方案图、流程图的 product/项目角色；三是对信息可视化有兴趣、想把"画图"这件事从随手涂鸦提升到有章法可循的任何人。我会从图形类型的选择逻辑讲起，一路讲到布局、配色、标注、工具链，以及我自己踩过的那些坑。全程不堆砌术语，尽量用"你拿到一个需求之后该怎么做"的视角来展开。

需要先说明一点：下面涉及的具体工具、参数、代码示例，都是基于我个人的常见实践总结出来的合理方案，不是唯一答案。你可以把它当成一套"默认起点"，在此基础上按自己的场景调整。

2. 先选对图形类型，再谈画得好不好看

2.1 图形类型选错的代价，比画得丑大得多

我见过太多这样的情况：一个人花了两个小时把一张图画得非常精致，配色讲究、对齐完美，结果评审的时候别人第一句话是"这个图想表达什么？"。问题不在美观度，而在图形类型和表达意图不匹配。

举个具体的例子。假设你要说明"用户下单后，订单系统、库存系统、支付系统之间怎么交互"。如果你画成一张流程图（flowchart），用菱形表示判断、矩形表示步骤，那读者会默认这是一条"顺序执行"的路径，但实际上这三个系统之间是并发的消息交互，有请求有响应，还有超时和重试。这时候正确的选择应该是时序图（sequence diagram）或者数据流图，而不是流程图。

再比如，你要说明"一个服务的内部由哪些模块组成、模块之间怎么调用"。这时候用架构图（通常用分层或分组的方式表达）比用流程图合适得多，因为架构图强调的是"结构关系"，而流程图强调的是"执行顺序"。

我把常见的图形类型和它们的适用场景整理成一张表，方便你对照：

这张表我建议你存下来。每次拿到画图需求，先花三十秒对照一下，确认图形类型选对了，再动手。这三十秒能省掉后面两个小时的返工。

2.2 一个判断图形类型的实用口诀

如果上面的表你还是记不住，我给你一个更简单的判断方法，我管它叫"三问法"：

• 第一问：读者关心的是"顺序"还是"结构"？关心顺序，往流程图/时序图方向走；关心结构，往架构图/ER图方向走。
• 第二问：有没有"时间"这个维度？如果交互是有先后、有等待、有响应的，时序图几乎不会错。
• 第三问：有没有"状态"这个概念？如果某个东西会在多个状态之间切换，且切换有条件，状态机图是最清晰的表达。

这三问基本能覆盖八成以上的场景。剩下的两成，往往是复合需求，需要在一张图里融合多种表达，这时候就要考虑"主图+辅图"的方式，而不是硬塞进一张图里。

2.3 什么时候该拆成多张图

我个人的经验是：当一张图上的节点超过 15 个，或者连线交叉超过 5 处，就该考虑拆图了。这不是硬性标准，而是一个"可读性警戒线"。超过这个量级，读者的眼睛会在图上迷路，再好的配色也救不回来。

拆图的原则是"按关注点拆"，而不是"按数量平均拆"。比如一个电商系统的架构图，可以拆成"用户侧架构""交易侧架构""履约侧架构"三张，每张聚焦一个关注点。这样每张图都清爽，读者也能按需查看。

3. 布局是图的骨架：为什么你的图总是"看着乱"

3.1 布局混乱的根源：没有确定"主方向"

一张图看着乱，九成情况下不是元素太多，而是没有一个明确的主方向。什么叫主方向？就是读者的视线应该沿着哪条线走。

流程图的主方向通常是"从上到下"或"从左到右"；架构图的主方向通常是"从上层到下层"；时序图的主方向是"从上到下"的时间轴。一旦主方向确定，所有元素都应该围绕这个方向排列，而不是东一个西一个。

我见过一张架构图，上层模块画在左上角，下层模块画在右下角，中间还穿插了几个横向的箭头。读者的视线被迫走"Z"字形，看三遍才能理清层次。这就是典型的主方向缺失。

3.2 分层与分组：让图有"呼吸感"

确定主方向之后，下一步是分层和分组。分层解决"上下关系"，分组解决"左右关系"。

以一张典型的后端架构图为例，我会这样分层：

1. 接入层：网关、负载均衡
2. 应用层：各个业务服务
3. 领域层：核心业务逻辑
4. 基础设施层：数据库、缓存、消息队列

每一层内部，再用分组框把相关的模块圈在一起。比如应用层里，"订单相关服务"放一组，"用户相关服务"放一组。这样读者一眼就能看出"哪些是一伙的"。

分组的时候有个细节要注意：分组框之间要留出足够的间距。我一般会让组间距至少是组内元素间距的 1.5 倍。这个比例能让视觉上自然形成"块"的感觉，而不是糊成一片。

3.3 连线：能少则少，能直则直

连线是图里最容易失控的元素。我的原则是三条：

• 能少则少：如果两个模块的关系可以通过分组隐含表达，就不要画连线。比如同一个分组内的模块，默认它们有关系，不必每个都连。
• 能直则直：优先用直线，其次用折线，最后才用曲线。曲线虽然好看，但容易和其他元素重叠，造成视觉干扰。
• 交叉要处理：如果两条连线必须交叉，用"跳线"（一条线在交叉处画个小弧跳过另一条）来区分，而不是让它们直接叠在一起。

关于连线的方向，还有一个经验：箭头方向要统一。如果一张图里有的箭头从左到右、有的从右到左、有的从上到下，读者会晕。统一成一个主方向，例外情况才用反向箭头，并且用颜色或线型区分。

3.4 对齐：最容易被忽视但最影响观感的细节

对齐这件事，说起来简单，做起来很多人会忽略。我见过太多图，节点大小不一、位置随意，看着就是"不专业"。其实只要做到两点，观感立刻提升一个档次：

• 同级元素对齐：同一层的节点，顶部或中心对齐。
• 等间距：同级节点之间的水平或垂直间距保持一致。

如果你用的是支持自动布局的工具（比如基于文本描述的绘图工具），这两点通常会自动帮你处理好。如果是手动拖拽的工具，那就得靠网格和参考线。我个人的习惯是打开网格吸附，间距统一设为 40px 或 60px，这样出来的图整齐度会高很多。

4. 配色与标注：让图"会说话"的隐形推手

4.1 配色的第一原则：颜色是信息，不是装饰

很多人画图喜欢用一堆鲜艳的颜色，觉得这样"好看"。但从信息传达的角度，颜色应该承载信息，而不是单纯为了好看。如果两种颜色没有表达任何区别，那它们就不该存在。

我的配色习惯是这样的：

• 主色调：整张图用一个主色系（比如蓝色系），用于大部分普通节点。
• 强调色：用一到两个对比色（比如橙色、红色），用于需要特别注意的节点，比如"核心服务""风险点"。
• 中性色：灰色用于辅助信息、背景分组框。

这样一张图里，颜色种类控制在 3 到 4 种，读者一眼就能分辨"哪些是重点"。

4.2 具体配色方案参考

如果你对配色没把握，可以直接用下面这套我常用的方案（十六进制色值）：

这套配色我用了很久，在各种投影仪和屏幕上表现都稳定。红色一定要慎用，一张图里红色节点超过两个，警示效果就失效了。

4.3 标注：把"图里说不清的话"补上

图能表达结构，但表达不了"为什么"。这时候就需要标注。标注的形式可以是图上的文字说明，也可以是图旁边的注释。

我常用的标注方式有三种：

• 节点内标注：在节点框里写清楚模块名 + 一句话职责，比如"订单服务（负责下单、取消、查询）"。
• 连线标注：在连线上标注协议或数据，比如"HTTP/JSON""异步消息"。
• 图例：在图的一角放一个图例，说明颜色和线型的含义。

标注的文字要短。我见过有人在节点里写了三行字，结果节点框被撑得巨大，整张图比例失调。节点内的文字控制在 10 个字以内，详细说明放到图外的文档里。

4.4 一个反直觉的建议：先画黑白稿

这是我个人的一个习惯，也是我强烈推荐给别人的：先用黑白灰画一版，确认信息结构没问题，再上色。

为什么？因为颜色会"掩盖"结构问题。一张结构混乱的图，上了色之后看着好像还行，但把颜色去掉，问题立刻暴露。先画黑白稿，强迫自己只靠布局和文字把信息讲清楚，等结构稳了，颜色只是锦上添花。

5. 工具链选择：从手写到代码化绘图

5.1 三类绘图工具，各有各的适用场景

市面上的绘图工具大致分三类，我按"控制粒度"从低到高排一下：

• 拖拽式工具：鼠标拖拽节点，所见即所得。上手快，但精细控制难，版本管理麻烦。
• 文本描述式工具：用代码或标记语言描述图，工具自动渲染。适合需要版本管理、需要批量生成的场景。
• 代码绘图库：用编程语言直接画图，控制粒度最细，适合嵌入到自动化流程里。

这三类没有绝对的好坏，关键看场景。如果是临时给会议画一张图，拖拽式最快；如果是技术文档里的图，需要跟着代码一起版本管理，文本描述式更合适；如果是自动化生成报表图，代码绘图库是唯一选择。

5.2 文本描述式绘图：为什么我越来越偏爱它

我这两年越来越偏爱文本描述式的绘图方式，原因有三个：

1. 可版本管理：图的源文件是纯文本，可以放进 Git，每次修改都有记录，能 diff、能回滚。
2. 可复用：常用的图形片段可以抽成模板，下次直接引用。
3. 一致性：样式由统一的配置控制，不会出现"这张图蓝色、那张图绿色"的混乱。

以常见的文本绘图语法为例，画一个简单的流程图大概是这样：

graph TD A[用户请求] --> B{是否登录} B -->|是| C[查询订单] B -->|否| D[跳转登录] C --> E[返回结果]

这段描述渲染出来就是一张从上到下的流程图。改起来也方便，想加一个节点就加一行，不用重新拖拽布局。

5.3 代码绘图库的适用边界

代码绘图库（比如用 Python 的绘图库直接生成图）适合的场景比较特定：需要批量生成、需要和数据处理 pipeline 集成。比如你有一个服务依赖关系的数据源，想每天自动生成一张最新的架构图，那用代码绘图库就是对的。

但如果是手工维护的、变化不频繁的图，用代码绘图库就有点"杀鸡用牛刀"了，维护成本反而更高。我一般只在"图的数据来源是动态的"这种情况下才用代码绘图。

5.4 工具选型的一个实用决策流程

我把工具选型的决策过程整理成一个简单的流程，你可以照着走：

1. 这张图需要版本管理吗？需要 → 排除纯拖拽式，选文本描述式或代码绘图。
2. 图的数据是动态的吗？是 → 选代码绘图库。
3. 图需要频繁手工调整吗？是 → 文本描述式更灵活。
4. 只是临时画一张？是 → 拖拽式最快。

按这个流程走，基本不会选错。

6. 实操中踩过的坑与排查思路

6.1 坑一：图渲染出来和预期完全不一样

这是用文本描述式工具时最常见的问题。你写了一段描述，渲染出来发现节点位置、连线走向和你想象的完全不同。

排查思路：先检查语法有没有写错，尤其是缩进和箭头符号。文本绘图工具对语法很敏感，一个空格错了就可能导致整张图结构变化。如果语法没问题，那就是布局引擎的"自动决策"和你的预期不一致。这时候不要硬刚，而是调整描述的结构——比如把某个子图单独抽出来，或者改变节点的声明顺序，往往能引导布局引擎给出更合理的结果。

6.2 坑二：图太大，渲染出来糊成一团

节点一多，自动布局就容易失控。我遇到过一次，一张图有 40 多个节点，渲染出来连线密密麻麻，完全没法看。

解决办法：拆图。前面说过，超过 15 个节点就该考虑拆。拆的时候按"关注点"拆，每张图聚焦一个主题。如果实在不能拆，那就用"子图"（subgraph）的方式把节点分组，让布局引擎按组来排布，会好很多。

6.3 坑三：中文字体显示异常

用某些绘图工具时，中文可能显示成方块或者字体很难看。这通常是字体配置的问题。

解决办法：在配置里显式指定一个支持中文的字体。如果是网页端渲染，确保 CSS 里 font-family 包含了中文字体；如果是本地渲染，检查系统字体是否安装。我一般会指定一个"无衬线中文字体 + 英文回退"的组合，保证中英文都好看。

6.4 坑四：改了图但忘了同步文档

这是流程上的坑，不是技术坑。图改了，但引用这张图的文档没更新，导致文档和图对不上。

解决办法：把图的源文件和文档放在同一个仓库里，改图的时候顺手检查引用。如果工具支持，尽量用"引用"而不是"复制粘贴"的方式在文档里嵌入图，这样图一改，文档自动更新。

6.5 一个通用的排查心法

遇到绘图问题，我的通用排查顺序是：先查语法，再查结构，最后查样式。语法错误最容易发现也最容易修；结构问题需要调整描述方式；样式问题最后处理，因为样式不影响信息传达，优先级最低。按这个顺序排查，效率最高。

7. 从"能画"到"画得好"：几个提升图质量的习惯

7.1 画之前先写一句话说明

我现在的习惯是：动手画图之前，先用一句话写下"这张图要说明什么"。比如"这张图要说明订单创建后，库存和支付两个系统的协作流程"。这一句话就是图的"主题句"，画的过程中随时对照，确保没有跑偏。

这个习惯看起来简单，但效果显著。很多图之所以乱，就是因为画的人自己都没想清楚要表达什么，边画边想，最后画出一堆无关的东西。

7.2 画完之后"隔夜再看"

这是一个很土但很有效的办法：画完图之后不要马上交付，放一晚上，第二天再看。隔了一夜，你对图的"作者视角"会淡化，更容易用"读者视角"发现问题。我很多次都是第二天一看，发现某个连线多余、某个标注不清。

如果时间不允许隔夜，那就至少离开座位走一圈再回来看，效果也有个七八成。

7.3 让别人给你讲一遍

终极检验方法：把图给一个不了解背景的同事，让他照着图给你讲一遍流程。如果他能讲对，说明图合格；如果他卡在某处，那处就是图的"信息断点"，需要补标注或调整结构。

这个方法我强烈推荐。自己看自己的图，永远觉得"很清楚"，因为脑子里有背景知识。只有别人讲一遍，才能暴露真正的可读性问题。

7.4 建立自己的图形素材库

画得多了，你会发现很多图形片段是重复的：网关、数据库、消息队列、用户图标……与其每次重画，不如建一个自己的素材库，把这些常用元素存起来，下次直接引用。

素材库不用很复杂，一个文件夹放几个模板文件就行。关键是持续积累。我现在的素材库里有几十个常用片段，画新图的时候能省掉一半以上的时间。

8. 关于 diagram-design 这件事，我最后想说的

画图这件事，工具永远在变，但"把复杂信息讲清楚"这个核心目标不会变。我见过用最朴素的工具画出极清晰图的人，也见过用最花哨的工具画出让人看不懂的图的人。差别不在工具，在于画图的人有没有想清楚"这张图给谁看、要传达什么"。

如果你刚开始接触 diagram-design，我的建议是：先别急着学工具，先练"用一句话说清一张图"的能力。拿到需求，先想清楚图形类型、主方向、分层分组，这些想明白了，用什么工具画都是水到渠成的事。

至于工具，选一个顺手的，用熟它，比换来换去强。文本描述式也好，拖拽式也好，能稳定产出清晰图的工具就是好工具。我自己是文本描述式和拖拽式混着用，看场景切换，没有执念。

最后分享一个小技巧：如果你觉得一张图"差点意思"但又说不出哪里不对，试试把它缩小到 50% 看。缩小之后，结构问题会放大，配色问题会缩小，你更容易判断到底是结构还是样式的问题。这个技巧我用了很多年，屡试不爽。