diagram-design这个词，翻译过来就是“图表设计”，但很多人把它理解成了“把方块摆整齐”。我在实际工作中接触过不少技术方案、产品功能设计，发现大部分图的问题不是画得不好看，而是根本没说清一件事：这张图到底想表达什么关系。diagram-design的核心从来不是绘图技巧，而是“结构设计”——你要先想清楚节点之间的逻辑关系，再谈配色、布局和美观。这篇内容适合要画系统架构图、业务流程图、功能模块图的开发者、产品经理和设计师，也适合刚入行、一打开画布就不知道从哪下手的同学。
我最早画图也是拿到空白画布就懵，后来踩过不少坑才总结出一套能直接复用的方法。这篇文章就是把这套方法完整拆开：从图型选型、布局逻辑、配色规范，到实操流程和常见翻车现场，都给你捋一遍。
1. 先想清楚图是给谁看的，再动手画
很多图之所以最后变成一团乱麻，问题往往出在最开始：压根没思考这张图的用途和读者。diagram-design的第一步不是打开工具，而是先回答三个问题：给谁看、看什么、在什么场景下看。
1.1 图的本质是“看得见的关系”
为什么技术方案总要配图？因为文字是线性的，而关系是网状的。架构图的核心价值在于把“服务A依赖服务B，B又依赖C”这种隐含关系，变成一眼就能扫完的视觉结构。所以你在设计图的时候，本质上是在做“信息结构设计”。
我见过最典型的错误是：有人把架构图画成了一张“截图拼贴”，把所有服务图标贴上去，再用箭头连一圈。看起来信息很全，实际上读者根本分不清主次，也不知道该按什么顺序看。这个问题的根源就是把“画图”当成“记录”，而不是“表达”。
在设计之初，我建议你先做一次“信息降维”：把所有要表达的内容写在一张纸上，然后问自己，这些内容里哪些是核心主干、哪些是支撑细节、哪些干脆可以不放。删除永远是diagram-design里最难也最重要的一步。
1.2 五种高频图型与选型逻辑
不同的关系形状对应不同的图型，选错图型是硬伤。我常用的是下面五类：
| 图型 | 表达的关系 | 典型场景 | 核心要求 |
|---|---|---|---|
| 架构图 | 组件间的层次与依赖 | 系统整体设计、模块划分 | 分层清晰、依赖方向明确 |
| 流程图 | 过程与分支 | 业务流转、算法逻辑 | 节点明确、路径无遗漏 |
| 时序图 | 时间顺序与交互 | 接口调用、消息传递 | 顺序准确、消息标注完整 |
| 状态图 | 状态与事件触发 | 订单状态机、任务调度 | 状态完备、事件无歧义 |
| 组织图/树形图 | 归属与层级 | 权限体系、目录结构 | 父子关系直观、粒度一致 |
选型逻辑很简单：你核心想表达的是“有哪些东西”，还是“它们怎么运作”，还是“按什么顺序发生”？比如你要说明订单系统，如果你重点讲“下单、支付、退款”的过程，那就是流程图；如果你重点讲“订单状态有哪些、哪些事件让状态变化”，那就是状态图。很多人画图不顺手，不是工具不熟，而是选错了表达方式。
1.3 动笔前的三分钟草稿法
我在正式画图前，一定先在草稿纸上画一个极简的草图，不追求好看，只追求把结构和流向说清楚。这个过程通常不超过三分钟，但能节省后面三十分钟的返工时间。
具体做法是：先画出核心节点（一般不超过7个），用方框代表模块、圆圈代表外部系统、菱形代表判断。然后用带方向的线连接它们，标上关键动词或数据流。这一步的产出不是“图”，而是一个“逻辑草稿”。之后打开绘图工具，本质上就是把草稿搬运到画布上，同时优化布局和样式。
这个习惯我推荐给所有团队成员，尤其是刚接触diagram-design的初学者。因为草稿阶段没有美观压力，你会更专注于“关系”本身，一旦关系理顺了，后面的一切都只是技术活。
2. 布局与结构：图好看的核心不是配色，是对齐与层次
很多人以为图的好看程度取决于配色，实际上关系不大。真正决定一张图专业与否的，是布局的秩序感。
2.1 阅读方向决定视觉流
人眼的阅读习惯是固定的：从左到右、从上到下。如果一张图的流向是自下而上，或者从右往左，读者的视觉流就会被打破，读图成本直线上升。我画业务流图时，习惯把起点放在左上角，主流程从左向右推进，第二层流程换行继续从左向右。这样读者可以像读文章一样读图。
架构图则略有不同，通常采用“自上而下的分层”：用户层在最上面、业务层中间、数据层在下面。这种布局本身就是一种语义——上层依赖下层、下层支撑上层。如果你把数据层画在中间，用户层画在底部，就算用再粗的边框标明“这是数据层”，读者也会反复迷惑。
2.2 对齐与网格：让图“立起来”
你是否见过那种每个框都对不齐、间距忽大忽小的图？即使内容完全正确，也会让人觉得“草率”。秘诀其实特别朴素：打开网格吸附功能，让每一个节点都对齐到网格线上。
我实际操作时，会先在画布上设置一个基础网格间距，比如20像素。所有节点框都放在整数倍网格坐标上，节点间距保持统一。这样图面会产生一种“整齐感”，这种整齐感会让读者下意识地觉得内容“靠谱”。别小看这个细节，技术评审时，一张对齐良好的架构图能明显提升方案的可信度。
间距也有讲究。核心相关的节点之间，间距应该小于非相关节点的间距。比如“网关”和“鉴权服务”关系紧密，它们之间的距离就应比“网关”和“日志服务”更近。这种“距离即关系”的布局会让图的信息密度更高，同时也更易读。
2.3 分组：容器、泳道与子图
当节点数量超过10个时，就必须引入“分组”手段，否则图会迅速失控。我常用的分组有三种：
- 容器分组：用一个大圆角矩形把一组相关模块包起来，在左上角标注分组名称，比如“基础设施层”“第三方服务”。这是最直观、最常用的方式，适合架构图。
- 泳道分组：用横向或纵向泳道按“角色”“系统”划分区域，每个角色在自己的泳道内活动。适合流程图，能同时表达“谁做的”和“先做什么后做什么”。
- 子图分组：把一部分逻辑折叠起来，主图只保留一个入口节点，想看细节的人再展开或者查看子图。适合内容过多、塞不进一页的大场景。
选哪种分组不是随意的，核心逻辑看“关系维度”。如果分组维度是“归属层级”，用容器；如果维度是“角色职责”，用泳道；如果是“逻辑模块”，可以考虑子图。
2.4 连线是图的语法，不是装饰
连线是最容易被忽略又最容易出问题的地方。我见过大量“蜘蛛网”图，问题出在哪里？出在线条横跨大半个画布去连接远处节点。
布线几个基本纪律：连线尽量走水平或垂直方向，转角用圆角，不要画斜线；交叉越少越好，如果必须交叉，想办法通过调整节点位置来避开；两条线并行时保持等距，不要一会儿近一会儿远。更关键的是，连线上手写线索“连接哪两个节点”，而不是“画一条线过去”。每画一条线前，先问自己：这条线代表什么关系？依赖？调用？数据流？实在区分不清时，用不同的线型——实线代表强依赖、虚线代表异步或弱关联——并在图例里说明。
同样的关系，线型统一也很重要。如果一张图里有些依赖用实线箭头，有些用无箭头直线，读者就会疑惑：没有箭头是表示“双向依赖”还是“忘了画箭头”？我在审图时最常问的一句话就是：“这根线是什么意思？”如果作者答不出来，说明这根线本身就是多余的。
3. 配色、字体与细节规范：克制是最高级的风格
当布局理顺了，才进入“美化”环节。很多人的误区是上来就选一组渐变色，结果整个图花花绿绿、主次不分。diagram-design的美化原则只有一条：让视觉服务于信息层级。
3.1 颜色数量控制与语义色
我给自己定了一个硬性规则：一张图里的大面积着色不超过4种。这4种颜色各司其职，形成一套“语义色”体系：
- 主色：用于核心模块，通常是整个系统或流程的主角。比如架构图中的“业务系统层”，用主色填充。
- 辅色：用于支撑模块。比如基础设施、公共组件，用辅色区分。
- 中性色：用于外部系统或依赖方，常用灰色系，弱化存在感。
- 警戒色：用于需要特别说明的异常节点、备份链路或风险点，用暖色系。
我来举一个实际例子：画一个电商订单系统架构图时，核心交易链路（订单、支付、库存）用主色，支撑服务（消息推送、日志、监控）用辅色，外部依赖（支付网关、物流平台）用中性灰，而“库存超卖补偿”这种风险链路用警戒色。读者一眼就能看出哪些是主干、哪些是枝叶、哪些要小心。
3.2 对比度与可读性
图里的文字最终是要被看清楚的，这里有几个可量化的指标。正文与背景的对比度至少要达到4.5:1，这个标准是从无障碍设计里来的，但套用到架构图上同样成立，尤其是投影仪评审场景。浅灰背景配白字，看着高级，实际投出来根本看不清，属于典型的“为了美牺牲用”。
我一般用深灰（#333333）做正文，背景用浅色（#F7F8FA），节点底色用高明度但不刺眼的颜色。选色时有一个技巧：不要直接用红黄蓝绿的原色，而是用它们的“低饱和度变体”，比如蓝灰、藕色、奶黄。这些颜色既保持了区分度，又不抢主体内容的注意力。
3.3 字体、字号与命名规范
字体方面，中文用常规无衬线字体，英文用等宽字体或常规字体，整体字号分三个层级：方块标题（12-16）、内容文字（10-12）、注释图例（8-10）。字号层级要和视觉层级一致，否则就会出现“大标题是小字、注释比内容大”的混乱。
节点命名是另一个常常被忽略的细节。我要求所有命名遵循“名词+动词短语”的规范，避免“服务”这样没信息的词。比如，不要写“内存”，而是写“Redis缓存”；不要写“MQ”，而是写“消息队列（下单事件）”。命名里带上用途或者关键参数，读者读图时就能少猜很多。
另外，统一的加粗规则也很重要。我习惯只加粗“节点标题”“关键结果”和“核心链路标识”，其余一律常规字。加粗是一种强调手段，如果整张图都是粗体，那就等于没有加粗。
4. 实操全流程：从空白画布到一张能过评审的图
这章我完整走一遍实操流程，从工具选型到最终导出，给大家一个可以直接照搬的作业流程。
4.1 工具选型：不同阶段用不同的工具
diagram-design这件事，工具真的不是越贵越好，关键是匹配你的场景。
- 快速草图：直接用纸笔或白板工具。特点是什么都不用装、上手零成本，适合前期理逻辑。
- 正式架构图：我用开源的绘图工具比较多，支持本地文件、支持导出矢量图，画架构图的基础元素完全够用，且没有版权问题。它的图层和样式复制功能对批量操作很友好。
- 在线协作：需要多人同时编辑时，用在线白板或文档内嵌的画板工具。适合评审讨论场景，但注意权限管理，避免被顺手改了格式。
- 代码生成：如果你本身是开发者，且图的节点数量很多（比如50个以上），可以考虑用“描述式绘图”工具，通过代码语言来定义节点和连线。优点是版本可控、可以自动化生成，缺点是调试样式比较费时间，适合维护大型架构图。
我给团队的建议是：日常方案用开源绘图工具，评审协作用在线白板，大型系统维护用代码生成。不要指望一个工具解决所有问题。
4.2 标准绘制六步法
这套流程是我自己反复迭代之后固定的，每一步都有明确产出。你照着走，至少不会跑偏。
第一步，明确画布范围。开画之前先用“锚点框”把图的四周边界框出来。这个锚点框不是最终图的一部分，而是为了告诉画布“内容和边界都限制在这里”，防止画着画着无限扩展。内容超过一屏时，果断拆图。
第二步，摆放核心节点。根据草稿，把所有核心节点先拖到画布上，但不对齐也不连线。这一步是“把信息倒进来”，不要想着一次排好。
第三步，全局连线。按照草稿的关系，先连主链路，再连次要链路。连线时先忽略美观，把关系全部表达完。
第四步，重新布局。把所有节点对齐到网格，调整间距，确保主线不被弯曲折线搞乱。我常用方法：先拖拽核心链路节点，把它们排成一条水平或垂直直线，再让次要节点围绕它们布局。
第五步，样式统一。批量设置填充色、边框、字体、字号。用组件库或主样式，保证同类节点长得一样。检查一遍语义色是否贯穿全图。
第六步，评审与迭代。把画好的图发给一个不在项目里的同事，请他描述他理解的系统结构。如果他的描述和你预期一致，说明图合格；如果偏差很大，说明图的信息传递有问题，需要调整。
4.3 导出与交付：格式要根据场景选
图的交付格式也有讲究。核心技术评审时，用矢量格式（比如SVG），放大不糊，方便别人标注；嵌到文档中时，用高清位图（PNG，2倍分辨率），避免打印模糊；如果要让别人二次编辑，直接发源文件，这是最重要的。很多图的后续改动，如果只有位图，就不得不重新画一遍，浪费大量时间。
我一般习惯在交付时同时提供三种格式：源文件（可编辑）、SVG（矢量引用）、PNG（文档嵌入）。这样对方的任何使用场景都能覆盖到。多花一分钟导出，能省下后面“帮我改一个字”来回来回传文件的麻烦。
5. 高频翻车现场：五个最常见的图设计问题与对策
画图这件事，经验都是从坑里爬出来的。我把这几年见过的高频翻车场景整理成速查表，每个问题都附上对应的对策。
| 问题 | 现象 | 根因 | 对策 |
|---|---|---|---|
| 信息过载 | 一张图塞了30个节点，谁也看不清 | 该拆图时没拆 | 按分层或模块拆成两张以上子图，主图保留主干 |
| 交叉线成网 | 连线横穿全图、交叉成网 | 布局顺序不对 | 先排主线，再排支线；用容器收拢跨构图节点 |
| 样式混乱 | 同类节点颜色不一、粗细不一 | 没有用主样式批量修改 | 定义好主样式，所有同类节点强制套用 |
| 冗余标注 | 每条线上都标箭头还有文字说明 | 信息重复 | 线型即语义，箭头代表依赖方向，不要让文字重复说明 |
| 无图例 | 读者看不懂颜色和线型含义 | 作者自认为“一眼就懂” | 右下角加图例，标注颜色、线型的含义 |
5.1 信息过载与切割策略
信息过载是图表设计里最普遍的“病”。症状很清晰：一张图又挤又密，放大之后看局部还行，缩小看整体什么都记不住。
对策是“分层切割”。把系统的核心业务流程画一张主图，把“部署环境”“监控指标”“数据模型”等内容分别画成附属子图，在主图上以“链接”或“参考标记”的方式标记。很多人舍不得分割，总觉得“一张图全展示”才完整。但实际评审时，评审人只会听你讲主线，细节问题到提问阶段再翻子图也来得及。
5.2 连线交叉与布线优化
交叉线是布局阶段最难解决的问题，尤其在没有分层的情况下。我常用的一个技巧是“L型布线”：从一个节点引出的线先水平走到目标节点的垂直方向，再拐一个直角下来。这样交叉的概率比斜线小得多，而且视觉上更整齐。
如果实在避免不了交叉，就把交叉点设计成“跨越”而不是“穿过”——比如在交叉处用半圆弧跳线，或者让其中一根线“断开”一小段。这样读者知道它们只是物理交叉、逻辑无关联。同理，如果两根线在图上走同一路径但代表不同语义，优先处理成“合并后分流”并标注，避免读者误以为有联系。
5.3 样式一致性：先把主样式定死在前面
样式混乱的问题，多半出在多人协作或长周期迭代时。今天你加一个模块用了一个新颜色，明天他加一个模块复制了上一块再改了个色，最后越来越乱。解决办法是在图的“标准化”阶段就定死主样式，并放到固定位置。后面所有新增节点，一律从已有节点复制而不是新建。
再强调一次：复制，不是新建。复制会保留所有样式属性，样式乱就无从谈起。如果你用开源绘图工具，还可以把公共组件放到单独的库或页面里，引用复用，而不是到处另存。
5.4 版本管理与变更记录
图的版本管理比代码难得多，因为图形文件不像代码有直观的diff。我的习惯是：文件名带上日期和版本号，例如“订单架构_v20250113_release”或“订单架构_v2.1_评审稿”。同时建立一份“变更说明”列表，每改动一次就追加一行，写明“改了谁、为什么改”。
这个习惯在一次跨团队协作里救过我的命。那次评审会开完，两个方向都提了修改意见，因为有变更记录，我才能把“A方向改过的内容”和“B方向的建议”分类回复，而不是根据模糊记忆临场发挥。
5.5 图例与自释性设计
最后一条，也是很多“老手”最爱犯的错——不画图例。你以为“这个颜色代表服务层”读者能看出来，实际上大多数读者只会注意到“这个颜色挺好看”。我要求所有正式交付的图必须带图例，图例里写清楚：
- 每种颜色代表什么层级或角色；
- 实线、虚线、点线各代表什么关系；
- 特殊符号（比如星号、警告标识）的含义；
- 图的核心阅读顺序（用序号或箭头标出“从哪里看起”）。
加了图例的图，才是一张“能自我解释”的图。这也是diagram-design和随手画一张示意图最大的差别。
6. 我自己的几个绘图习惯与总结思路
说了这么多结构化的方法，最后分享几个我个人的绘图习惯，也算是我踩过不少坑之后的“肌肉记忆”。
第一个习惯是：每张图都画完一版后，我先盯住“线”看十分钟，不看节点只看线。只看线能发现很多问题：是不是有冗余连线、是不是有方向不明、是不是有跨越太长的“飞线”。节点画得再漂亮，线一旦乱，整张图就废了。
第二个习惯是：永远在文档里配一段“读图指引”，两三句话就够。比如“本图从左上角入口开始，主干链路为A到B到C，灰色为外部依赖，虚线为异步消息”。别嫌麻烦，这段文字能帮你挡住至少一半“你这个图是什么意思”的追问。
第三个习惯是：把图当作活文档来维护，而不是交付件。系统演进、代码重构之后，图必须同步更新。如果更新不及时，图就变成“失真地图”，比没有图更危险。我一般会在任何架构变更的评审前，先把图更新一遍，再拿图去开会。
diagram-design是一项熟能生巧的技能，核心逻辑绕不开“结构清晰、布局整齐、颜色克制、标注到位”这四件事。你画的每一张图，本质上都是把复杂关系翻译成简单视觉的语言，这门语言越练越顺。希望这篇内容能让你下次打开画布时，少一点毫无头绪，多一点从容。
