1. 从"diagram-design"这个标题能读出什么
第一次看到"diagram-design"这个标题，我的直觉是：这大概率不是一个单纯的"画图工具推荐"或者"设计规范文档"，而是一个把图表设计这件事当成一个完整工程问题来对待的项目。为什么这么说？因为如果只是教人怎么画流程图，标题通常会写成"flowchart-tutorial"或者"diagram-guide"；而"design"这个词放在后面，意味着它强调的是设计决策——也就是"为什么这张图要这样画""什么场景该用什么图""怎么让图真正传达信息而不是制造噪音"。
图表设计这件事，看起来门槛很低，实际上坑极多。我见过太多团队，技术能力很强，但一画架构图就变成"方框加箭头大乱炖"，读者看三秒就放弃。也见过不少人在做技术分享时，PPT里的图信息密度过高，讲的时候自己都找不到重点在哪。这些问题的根源，都不是"不会用工具"，而是没有把图表当成一种需要设计的信息产品。
所以这篇内容，我想围绕"diagram-design"这个核心，把图表设计从认知层、选型层、执行层到维护层完整拆一遍。适合谁看？三类人：一是需要频繁输出架构图、流程图、时序图的技术从业者；二是要做汇报、写文档、做知识沉淀的职场人；三是对信息可视化有兴趣、想让自己的图"一眼就懂"的创作者。不管你用的是哪款工具，这套思路都能直接迁移。
我自己的经验是，图表设计能力带来的回报被严重低估了。一张好的架构图，能让新人在半小时内理解一个跑了三年的系统；一张糟糕的图，能让一个小时的评审会变成互相猜谜。下面我就按我实际做项目时踩过的顺序，一层层展开。
2. 图表设计的第一性问题：图到底为谁而画
2.1 先定读者，再定画法
很多人画图的第一步是打开工具，第二步是拖方框。这个顺序是反的。正确的第一步应该是问自己：这张图给谁看，他看完要做什么决策？
我举个真实场景。同一个后端服务，如果给运维看，重点是部署拓扑、实例数量、依赖的外部组件；如果给新入职的开发看，重点是模块划分、调用关系、数据流向；如果给管理层看，重点是业务价值链路和关键节点。这三种读者，画出来的图完全不一样，甚至用的图形语言都不同。
我踩过的一个坑是：早期做系统设计文档时，我画了一张"全能图"，既想展示部署，又想展示调用，还想展示数据模型。结果评审时，运维问"实例在哪"，开发问"这个箭头是同步还是异步"，谁都没得到答案。后来我改成一图一目的，同一套系统画三张不同视角的图，反而所有人都看懂了。
所以这里有个硬性原则：一张图只回答一个问题。如果一张图需要配一大段文字解释才能看懂，那这张图本身就是失败的。
2.2 信息层级：什么该画，什么必须删
图表设计的本质是信息取舍。新手最容易犯的错是"什么都想画上去"，因为怕漏掉信息。但读者的注意力是有限资源，你画得越多，重点越模糊。
我的做法是给每个元素打一个"必要性标签"：
| 元素类型 | 判断标准 | 处理方式 |
|---|---|---|
| 核心节点 | 去掉后图就讲不通 | 必须保留，视觉加重 |
| 支撑节点 | 解释核心节点如何工作 | 保留，视觉弱化 |
| 背景信息 | 只是"顺便提一下" | 移到图注或正文 |
| 实现细节 | 只有特定角色关心 | 单独出图 |
这个表格我几乎每次画图前都会在脑子里过一遍。实测下来，一张图里核心节点控制在5 到 9 个是比较舒服的区间，超过这个数量，人眼就开始"扫读"而不是"理解"了。这不是玄学，是认知负荷的基本规律——工作记忆能同时处理的组块数量就那么多。
提示：如果你发现核心节点超过 9 个，通常说明这张图承担了太多职责，应该拆图，而不是硬塞。
2.3 图表不是装饰，是论证工具
这一点我想特别强调。很多人把图当成"文档的配图"，觉得文字是主角，图是点缀。但在技术沟通里，图往往是论证的主体。一张好的架构图，本身就在论证"这个设计是合理的"——它通过清晰的边界、合理的分层、明确的依赖方向，让读者自己得出结论。
反过来，一张糟糕的图会暴露设计的混乱。我有个习惯：画图的过程就是检验设计的过程。如果我发现某个模块的箭头怎么连都别扭，那大概率不是画法问题，而是设计本身有问题。图是设计的镜子，画不顺，说明想不清。
3. 图表类型选型：别用流程图硬套所有场景
3.1 常见图表类型与适用边界
选错图表类型，是比画得丑更严重的问题。我整理了一张对照表，覆盖技术场景里最常用的几类：
| 图表类型 | 核心表达 | 典型场景 | 常见误用 |
|---|---|---|---|
| 流程图 | 步骤与分支 | 业务流程、算法逻辑 | 用来表达系统结构 |
| 架构图 | 模块与依赖 | 系统分层、组件关系 | 混入过多时序信息 |
| 时序图 | 交互与顺序 | 接口调用、协议流程 | 用来表达静态结构 |
| 状态机图 | 状态与迁移 | 订单状态、连接生命周期 | 用来表达流程步骤 |
| ER 图 | 实体与关系 | 数据建模 | 用来表达服务依赖 |
| 思维导图 | 层级与发散 | 知识梳理、方案拆解 | 用来表达有环依赖 |
这张表我建议存下来。每次画图前对一下，能避免 80% 的"图不对题"问题。
我印象很深的一次，某团队用流程图去画一个微服务的调用关系，结果因为服务之间有循环依赖，流程图里出现了回环箭头，看起来像"流程倒退"，评审时被反复追问。其实那个场景应该用架构图表达依赖，用时序图表达调用顺序，两张图各司其职，问题就没了。
3.2 什么时候该用"组合图"
现实场景里，单一图表类型往往不够用。比如描述一个完整的支付流程，既需要时序图表达"谁先调用谁"，又需要状态机图表达"订单状态怎么变"。这时候我的建议是拆成多张图，用统一的视觉语言串联，而不是硬塞进一张图。
统一视觉语言的意思是：颜色含义一致、图形语义一致、命名风格一致。比如蓝色永远代表"外部系统"，圆角矩形永远代表"服务"，虚线永远代表"异步"。这样读者看完第一张图，看第二张时认知成本就大幅降低。
3.3 选型的一个实用判断法
我自己总结了一个快速判断法，叫"动词测试"：
- 如果图的核心是"先做什么、再做什么"，用流程图或时序图；
- 如果图的核心是"谁依赖谁、谁属于谁"，用架构图或 ER 图；
- 如果图的核心是"在什么条件下变成什么"，用状态机图；
- 如果图的核心是"有哪些、分几类"，用思维导图或树形图。
这个测试的关键是找到图里最重要的那个动词或关系词，然后匹配图表类型。听起来简单，但能挡掉大量选型错误。
4. 视觉编码：让图"自己会说话"的细节
4.1 颜色不是用来好看的
颜色在图表里承担的是语义编码功能，不是审美功能。我见过太多图，颜色用得五彩斑斓，但没有任何含义，读者反而被干扰。
我的配色原则是：颜色数量控制在 3 到 4 种，每种颜色绑定一个固定语义。比如：
- 主色（如深蓝）：核心系统或主流程；
- 辅色（如浅蓝）：支撑组件；
- 警示色（如橙）：外部依赖或风险点；
- 中性色（如灰）：背景或次要信息。
这样读者不需要看图例就能猜出大概含义。如果颜色超过 5 种，基本可以判定这张图的语义编码失控了。
另外提醒一点：考虑色盲友好。红绿搭配是最常见的坑，大约每 12 个男性里就有 1 个红绿色觉异常。如果必须区分正反状态，用蓝橙搭配比红绿安全得多。
4.2 箭头方向与线型的信息量
箭头是图表里信息密度最高的元素之一，但很多人用得极其随意。我的规范是：
- 实线箭头：同步调用、强依赖、主流程；
- 虚线箭头：异步消息、弱依赖、可选路径；
- 双向箭头：双向通信，但要谨慎使用，容易造成"循环依赖"的误读；
- 无箭头连线：仅表示关联，不表示方向。
线型一旦定义，全图甚至全文档都要一致。我踩过的坑是：同一份文档里，第一张图虚线表示异步，第二张图虚线表示"已废弃"，读者直接懵了。后来我强制自己维护一份"视觉规范小抄"，每张图都对照检查。
4.3 布局：从左到右还是从上到下
布局方向看似小事，其实影响阅读效率。我的经验是：
- 流程类：从左到右，符合阅读习惯，也方便横向排版；
- 层级类：从上到下，上层是抽象，下层是具体；
- 循环类：环形布局，但要注意别让箭头交叉太多。
还有一个细节：对齐。手画的图最容易出现的问题就是方框大小不一、间距不均，视觉上显得很"业余"。其实只要做到"同层同高、同列同宽、间距一致"，图的专业度立刻上一个台阶。这个不需要什么设计天赋，纯粹是纪律问题。
4.4 文字：少即是多
图里的文字，我的原则是能用一个词就不用一句话，能用名词就不用动词短语。因为图是快速扫描的媒介，长句子会打断扫描节奏。
具体做法：
- 节点名称用名词短语，如"订单服务"而不是"处理订单的服务"；
- 箭头标签用动词或简短说明，如"创建"而不是"调用创建接口"；
- 图注放在图外，不要塞进图里。
如果某个节点确实需要详细说明，用编号加图注的方式，而不是把说明文字硬塞进方框。这样图保持清爽，细节也不丢失。
5. 工具链与工作流：从手绘到版本管理
5.1 工具选型的三个维度
图表工具五花八门，我不推荐具体品牌，但可以给三个选型维度：
- 表达力：能不能画出你需要的图表类型，支不支持自定义样式；
- 协作性：能不能多人编辑、评论、版本对比；
- 可维护性：改一个节点，相关连线会不会自动调整；能不能用文本描述生成图。
第三点特别重要。我早期用纯图形工具画架构图，系统一改，图就得大改，维护成本极高。后来转向**"图即代码"**的思路，用文本描述图表结构，改起来就是改几行文本，效率天差地别。
5.2 "图即代码"为什么值得投入
"图即代码"的核心价值是可版本管理。图变成了文本，就能进代码仓库，就能 diff，就能 review。这对技术团队意义重大——架构图的变更可以和代码变更一起评审，图和实现不容易脱节。
我实际用下来，收益主要有三点：
- 改图成本从"重画"降到"改几行"；
- 图的历史变更可追溯，能回答"这个模块是什么时候加的"；
- 多人协作时冲突可合并，不像二进制文件那样只能二选一。
当然，它也有代价：学习成本、样式精细度不如专业设计工具。所以我的建议是技术图用代码化工具，汇报图用设计工具，各取所长。
5.3 一个可复用的画图工作流
我把自己的画图流程固化成了五步，分享出来：
- 写一句话目的：这张图要回答什么问题，写在最上面；
- 列元素清单：把所有想画的节点列出来，然后按必要性删减；
- 定视觉规范：颜色、线型、形状的语义先定好；
- 画草图：先用最粗糙的方式摆位置，确认逻辑通顺；
- 精修与自检：对齐、间距、文字精简，最后用"陌生人视角"看一遍。
第五步的"陌生人视角"很关键。我经常把图发给不熟悉这个系统的同事，问他"你看完这张图，能说出这个系统大概怎么工作吗"。如果他说不出来，说明图还有问题。
6. 那些年我在图表设计上踩过的坑
6.1 信息过载：一张图塞进一个系统
这是我最早也最严重的坑。当时做一个跨平台系统的设计文档，我想"一张图搞定所有事"，结果画出来密密麻麻，自己看着都头疼。评审会上，有人直接说"这图我看不懂"。
后来我复盘，根本原因是我把图当成了文档的替代品，想用一张图承载所有信息。但图的优势是"快速传达结构"，不是"完整记录细节"。正确做法是：图负责结构和关系，文字负责细节和边界条件，两者配合，而不是互相替代。
6.2 语义不一致：同一个形状两种含义
第二个坑是语义漂移。同一份文档里，我一会儿用圆角矩形表示服务，一会儿又用它表示数据库，读者根本分不清。这个问题在多人协作时更严重，每个人有自己的习惯。
解决办法就是前面说的视觉规范小抄。我现在做任何多图文档，第一步就是定一份规范，贴在文档开头，所有人对照执行。规范不用复杂，一张表就够：
| 视觉元素 | 固定含义 |
|---|---|
| 圆角矩形 | 服务/应用 |
| 直角矩形 | 外部系统 |
| 圆柱 | 数据存储 |
| 实线箭头 | 同步调用 |
| 虚线箭头 | 异步消息 |
6.3 忽视读者：用自己熟悉的缩写
第三个坑很隐蔽：我在图里用了大量团队内部缩写，自己看着很顺，但跨团队评审时，别人完全看不懂。比如某个内部代号，我们叫惯了，外部人根本不知道是什么。
这个坑的教训是：图的读者范围决定了你能用多少"内部语言"。如果图只给本团队看，缩写没问题；如果要跨团队、跨层级，就必须用通用词汇，或者加图例说明。
6.4 只画不改：图与实现脱节
最后一个坑是维护问题。图一旦画完就没人管，系统改了图没改，半年后图就成了"历史文物"，谁也不敢信。这个问题的根源是图没有纳入变更流程。
我的解法是把图放进代码仓库，和代码一起 review。架构变更的 PR 里，如果涉及结构变化，必须同时更新图。这样图就有了"保鲜机制"，不会腐烂。
7. 让图表设计能力真正沉淀下来
7.1 建立自己的图表素材库
图表设计能力不是靠看教程看出来的，是靠反复画、反复改练出来的。我的建议是建一个自己的素材库，把画过的图分类存起来：架构图、时序图、状态图各一组，标注好场景和当时的取舍理由。
这个库的价值在于：下次遇到类似场景，你可以直接复用结构和视觉规范，而不是从零开始。我现在的很多图，都是在旧图基础上改的，效率高很多，风格也统一。
7.2 用"图评"代替"图看"
什么叫"图评"？就是像代码 review 一样，对图做结构化评审。评审的问题清单可以是：
- 这张图回答了什么核心问题？
- 核心节点是否一眼可见？
- 视觉编码是否一致？
- 有没有可以删掉而不影响理解的元素？
- 一个不了解背景的人能看懂多少？
我带着团队做过几次"图评"，效果很好。因为画图的人往往有"知识诅咒"，觉得自己懂的别人也懂，而图评能强制打破这个假设。
7.3 把图表设计当成沟通能力的一部分
最后我想说一个认知层面的东西。很多人把图表设计当成"工具技能"，觉得学会某个软件就行了。但我的体会是，图表设计本质上是沟通能力——它是把复杂信息压缩成可快速理解的形式的能力。
这种能力，在写文档、做汇报、带新人、做评审时都会用到。它和写作能力、口头表达能力是一体的。你图画的清楚，说明你想的清楚；你想的清楚，图自然画的清楚。
所以别把画图当成负担，把它当成训练自己结构化思考的方式。每次画图，都是一次把混乱想法整理成清晰结构的机会。这个能力练出来，受益的不只是图，而是你处理所有复杂问题的方式。
我在实际项目里最深的一个体会是：图的质量，往往反映的是团队对系统的理解深度。一个团队如果连一张清晰的架构图都画不出来，大概率对系统的边界和依赖也没有想清楚。反过来，能把图画的干净利落的团队，通常设计也不会太差。这大概就是"diagram-design"这件事最值得投入的原因——它不只是让图好看，而是让思考更清晰。
