1. 从diagram-design这个标题能读出什么第一次看到diagram-design这个标题我脑子里蹦出来的第一个判断是这不是一个具体的技术栈名称也不是某个框架或库的专有名词而是一个领域指向型的命名。它大概率指向的是图表设计这个方向——可能是流程图、架构图、时序图、状态机图、数据可视化图表也可能是更广义的用图形语言表达信息结构这件事。为什么我敢这么判断因为如果它指的是某个具体工具标题通常会带上工具名比如xxx-diagram或者diagram-xxx如果它指的是某个具体业务场景标题里通常会带业务词比如order-flow-diagram。而diagram-design这个组合把图表和设计两个词并列说明它的核心关注点是如何设计出好的图表而不是如何用某个工具画图。这个区分很关键。工具是术设计是道。工具会过时但什么样的图能让读者三秒看懂这件事十年后依然成立。基于这个判断我决定把这篇博文定位成一篇面向所有需要画图的人的方法论实操指南。不管你是后端工程师要画架构图还是产品经理要画业务流程图还是技术写作者要画概念关系图下面这些内容都能直接用上。先说说我自己的背景方便你判断我的经验是否对你有参考价值。我在一线做技术方案和文档工作超过十年画过的图从最早的Visio时代到后来的各种在线工具从手绘草图到自动化生成踩过的坑包括但不限于图画得太复杂没人看、图例不统一导致误解、颜色用得太花反而干扰信息、导出格式不对导致印刷模糊、版本管理混乱导致引用过期图。这些经验构成了下面内容的底色。2. 图表设计的第一性原理先想清楚谁在看2.1 图表的本质是信息压缩很多人画图的时候第一反应是我要把我知道的都画上去。这是最大的误区。图表的本质不是展示信息而是信息压缩——把一段用文字描述需要五百字的内容压缩成一张图让读者用五秒就能抓住核心结构。这个认知一旦建立你的画图逻辑就会彻底改变。你会开始问自己这张图里哪些信息是必须保留的哪些是可以省略的哪些是可以放到图注里的我举个具体的例子。假设你要画一个微服务架构图。新手常见的做法是把每个服务的端口号、数据库表名、中间件版本都标上去。结果图密密麻麻读者根本看不清服务之间的调用关系。而正确的做法是第一层只画服务名和调用箭头端口号和版本号放到旁边的表格里数据库只画一个圆柱体图标标注持久层不展开具体表结构。一个实用的判断标准如果你的图缩小到50%之后还能看清主干结构说明信息密度是合理的如果缩小后变成一团糊说明你塞了太多东西。2.2 读者决定图的粒度同一个系统给不同的人看应该画不同的图。这不是偷懒而是受众适配。给CTO看的架构图重点在系统边界、关键依赖、风险点不需要出现具体的类名和方法名。给新入职工程师看的架构图重点在模块职责、代码目录结构、本地如何跑起来需要具体到包名和启动命令。给运维看的部署图重点在节点数量、网络分区、监控埋点需要标注IP段和端口范围。我见过最糟糕的情况是一张图想同时满足所有人结果所有人都看不懂。所以我的建议是在动手画之前先用一句话写下这张图是给谁看的他看完之后应该能回答什么问题。如果这句话写不出来说明你还没想清楚先别打开画图工具。2.3 图表的三种叙事结构从叙事结构上分常见的图表可以归为三类类型核心作用典型场景阅读方向结构型展示由什么组成架构图、组织图、思维导图从上到下或从中心向外流程型展示先做什么后做什么流程图、时序图、状态机图从左到右或从上到下关系型展示谁和谁有什么关系ER图、依赖图、网络拓扑图无固定方向看聚类这个分类看起来简单但实际画图时很多人会混用。比如把流程图画成了结构图的样子读者就不知道箭头代表数据流还是控制流。我的经验是一张图只讲一件事。如果既要展示结构又要展示流程拆成两张图或者用主图局部放大图的方式。3. 工具选型别在工具上纠结超过十分钟3.1 按图的类型选工具而不是按流行度市面上画图工具太多了我按实际使用频率和适用场景给你一个直接的对照表工具类型代表工具最适合不适合代码生成类文本描述转图表工具架构图、时序图、ER图自由布局的创意设计拖拽式在线工具各类在线白板流程图、思维导图、快速草图需要精确对齐的复杂图桌面专业工具传统绘图软件印刷级图表、复杂矢量图快速迭代和协作手绘风格工具手绘风在线工具概念图、教学图、非正式分享正式文档中的架构图我的核心建议是技术类图表优先用代码生成类工具。原因有三个第一版本可控图的内容就是文本可以进Git第二修改成本低改一行文本比拖拽十个节点快得多第三风格统一不会因为手抖导致对齐不一致。3.2 代码生成类工具的实操细节以最常见的文本转图表工具为例说几个我踩过坑之后总结的细节。第一节点命名用英文ID显示名用中文。很多人直接用中文当节点ID结果在某些渲染环境下会出现乱码或者布局异常。正确的做法是A[用户服务] -- B[订单服务] B -- C[支付服务]这里的A、B、C是ID方括号里是显示文本。这样即使显示文本很长布局引擎也能正确处理。第二箭头类型要区分。实线箭头通常表示同步调用或强依赖虚线箭头表示异步消息或弱依赖。这个约定不是强制的但一旦你在图例里定义了就要全图统一。我见过一张图里实线虚线混用但没有任何说明读者完全懵。第三分组用子图而不是靠视觉 proximity。如果你想让读者知道某几个服务属于同一个业务域用子图subgraph显式包裹而不是仅仅把它们画得近一点。因为布局引擎可能会因为优化连线而把它们拉开。subgraph 交易域 B[订单服务] C[支付服务] end subgraph 用户域 A[用户服务] end A -- B B -- C3.3 什么时候该放弃代码生成改用手动拖拽代码生成不是万能的。以下情况我建议直接上手拖图里有大量非标准图形比如自定义的图标、特殊的容器形状需要精确控制每个元素的位置比如做海报、做PPT配图图的内容是一次性的不需要版本管理需要和不懂代码的人协作编辑判断标准很简单如果你发现自己在反复调整代码里的布局参数而不是在调整内容本身那就该换工具了。4. 一张好图的五个硬指标4.1 对齐最容易被忽视但最影响观感对齐是图表设计的呼吸感来源。人对不齐的东西天生敏感哪怕你说不出哪里不对就是会觉得这张图看起来不舒服。具体怎么做三个层次节点对齐同一层级的节点顶部或中心线对齐。如果是横向流程垂直居中对齐如果是纵向层级左对齐或居中对齐。间距对齐同级节点之间的水平间距相等层与层之间的垂直间距相等。不要出现这两个挨得近、那两个离得远的情况。文字对齐节点内的文字要么全部居中要么全部左对齐。混用会显得很乱。代码生成类工具通常会自动处理对齐这也是我推荐它们的原因之一。手动拖拽的话记得打开网格吸附和对齐辅助线。4.2 配色不超过三种主色配色是重灾区。我见过太多图红橙黄绿青蓝紫全用上结果读者根本不知道哪种颜色代表什么意思。我的原则是主色不超过三种每种颜色必须有明确的语义。比如蓝色正常服务橙色需要关注的服务如性能瓶颈红色故障或废弃的服务灰色外部依赖或不在本次讨论范围内的组件如果颜色不够用用形状或线型来区分而不是继续加颜色。比如同样是蓝色实线框表示同步服务虚线框表示异步服务。一个快速检验方法把图转成灰度如果还能区分出不同类别说明你的设计不依赖颜色这是好设计。4.3 图例必须有且要放在读者第一眼能看到的位置图例不是装饰是阅读说明书。没有图例的图读者只能靠猜。图例的位置有讲究。如果图是从左到右阅读的图例放右上角或右下角如果图是从上到下阅读的图例放右侧。不要放在底部因为读者看完图才看到图例就晚了。图例的内容要克制。只放读者必须知道才能看懂图的符号说明。不要把每个节点的详细定义都塞进图例那是表格该干的事。4.4 文字能横排就不竖排能短就不长竖排文字是阅读效率的杀手。除非是极短的标签比如是/否否则一律横排。如果空间不够宁可把节点画大一点或者把文字拆成两行。文字长度方面节点内的文字控制在不超过八个汉字。超过的话考虑用缩写或者把详细说明放到图注里。比如用户身份认证与授权服务可以简写成认证服务详细职责在下方用文字补充。4.5 留白图不是越满越好留白不是浪费空间是给读者眼睛休息的地方。一张图如果每个角落都塞满了内容读者的认知负荷会急剧上升。具体建议图的四周留出至少10%的空白边距节点之间的间距至少是节点高度的30%如果图里有分组框分组框内部要有内边距不要让节点贴着边框。5. 从需求到成图的完整实操链路5.1 第一步用文字列出所有元素和关系不要一上来就打开画图工具。先用纯文本把图的内容写出来。比如你要画一个订单系统的流程图元素 - 用户 - 订单服务 - 库存服务 - 支付服务 - 通知服务 关系 - 用户提交订单 - 订单服务 - 订单服务检查库存 - 库存服务 - 库存充足 - 订单服务创建订单 - 订单服务请求支付 - 支付服务 - 支付成功 - 订单服务更新状态 - 订单服务发送通知 - 通知服务 - 通知服务推送给用户这一步的好处是你可以专注于逻辑是否完整而不是被布局和配色分散注意力。我经常在这一步发现哎这里少了一个异常分支或者这个关系好像画反了。5.2 第二步确定图的阅读方向和信息层级根据上一步的文字判断这张图应该用什么阅读方向。上面的订单流程明显是从左到右的流程型。那么第一层是用户第二层是订单服务第三层是库存、支付、通知三个并行分支。信息层级决定了哪些元素应该放大、哪些应该缩小。主干流程上的节点可以大一点异常分支或辅助节点可以小一点。这样读者一眼就能看出主次。5.3 第三步选择工具并搭建骨架根据第3节的选型建议流程型图我通常用代码生成类工具。先把节点和连线写出来不调样式只看结构对不对。用户 -- 订单服务 订单服务 -- 库存服务 库存服务 -- 订单服务: 库存充足 订单服务 -- 支付服务 支付服务 -- 订单服务: 支付成功 订单服务 -- 通知服务 通知服务 -- 用户: 推送通知跑一下渲染看看布局是否合理。如果发现某条线绕了很远或者某个节点被挤到角落先调整节点的声明顺序通常能改善布局。5.4 第四步加样式但一次只加一种样式包括颜色、线型、形状、字体。我的建议是一次只加一种样式加完看效果确认没问题再加下一种。同时加多种样式出了问题你都不知道是哪个导致的。顺序建议先加形状区分矩形/圆角矩形/圆柱体再加线型区分实线/虚线最后加颜色。颜色放最后是因为它最容易干扰判断而且灰度打印时颜色会丢失所以不能作为唯一的区分手段。5.5 第五步找一个人试读图做完之后找一个不了解这个系统的人来看。不要给他任何解释让他直接看图然后问他你觉得这个系统是怎么工作的如果他说的和你想表达的一致说明图成功了。如果他卡在某个地方或者理解错了某个关系那就是图的问题不是他的问题。根据他的反馈回去改。这一步听起来麻烦但能帮你发现90%的歧义。我自己的经验是自己看自己的图永远觉得很清楚因为你知道背后的逻辑。只有完全不知情的人才能检验出图的真实表达力。6. 那些年我踩过的图表设计坑6.1 坑一图太大一页放不下早期我画架构图总想把所有东西塞进一张图。结果图大到需要A3纸打印在屏幕上要不断缩放才能看清。读者看图的体验极差。后来我学乖了如果一张图需要缩放超过两次才能看清细节就该拆图了。拆图的方式有两种一种是按层级拆一张总览图若干张局部详图另一种是按视角拆一张静态结构图一张动态流程图。拆图之后总览图上用带编号的方框标注详见附图X读者需要深入时再去看详图。这样既保证了总览的清晰又不丢失细节。6.2 坑二箭头方向混乱箭头方向混乱通常是因为混用了不同的语义。比如有的箭头表示数据流向有的表示调用关系有的表示依赖方向。读者看到箭头不知道该怎么理解。解决办法是在图例里明确箭头的语义并且全图统一。如果确实需要表达多种关系用不同的线型或颜色区分并在图例里说明。比如实线箭头同步调用虚线箭头异步消息空心三角箭头继承/实现关系6.3 坑三版本管理失控图一旦多了版本管理就是噩梦。我经历过最糟糕的情况是文档里引用了一张图但那张图已经更新了三版文档里的还是最老的版本导致新人和老人看到的架构不一致。后来我的做法是图的内容和文档放在同一个版本库里。如果图是代码生成的直接把源码文件放在文档同级目录如果是手动拖拽的导出为矢量格式如SVG后也放进版本库。每次更新文档时强制检查引用的图是否是最新版。一个小技巧在图的角落加一个不起眼的版本号和日期比如v2.3 2025-01。这样即使图被单独分享出去也能追溯来源。6.4 坑四忽略色盲用户大约8%的男性有某种程度的色盲最常见的是红绿色盲。如果你的图里用红色表示错误、绿色表示正常这部分读者可能完全分不清。解决办法是颜色形状双重编码。比如正常节点用蓝色圆角矩形错误节点用红色直角矩形。这样即使看不出颜色差异也能通过形状区分。或者直接在节点上加图标或文字标签。6.5 坑五导出格式选错导出格式决定了图的清晰度和可编辑性。我的经验规则要放进在线文档导出PNG2倍图或SVG要放进印刷品导出PDF或高分辨率PNG300dpi以上要给别人继续编辑导出源文件格式不要导出图片要在聊天工具里快速分享导出PNG但注意压缩率不要太高SVG是最保险的格式因为它矢量、可缩放、文件小而且大多数文档工具都支持。但有些老旧的系统不支持SVG那就退而求其次用高分辨率PNG。7. 让图表设计效率翻倍的几个习惯7.1 建立自己的图库和模板不要每次画图都从零开始。把你常用的图形比如服务、数据库、消息队列、外部系统做成模板下次直接复用。代码生成类工具通常支持自定义样式类手动工具可以保存为模板文件。我自己的做法是维护一个图表片段库里面存了常见的架构模式图比如网关微服务数据库、生产者-队列-消费者、主从复制需要时复制过来改改就行。这样画一张新图的起步时间从半小时缩短到五分钟。7.2 先画草图再画正图在纸上或白板上先画一版草图确认逻辑没问题之后再用工具画正式版。这个习惯能帮你避免画到一半发现逻辑不对全部推倒重来的情况。草图不需要好看圆圈加箭头就行。重点是验证信息流是否完整、是否有遗漏的分支、是否有循环依赖。这些问题在草图阶段发现修改成本几乎为零。7.3 给图写一段图注图注不是图的重复描述而是补充图里放不下的信息。比如图注本图展示订单创建的主流程。库存服务和支付服务为同步调用超时时间均为3秒。通知服务为异步消息不阻塞主流程。异常分支库存不足、支付失败未在图中展示详见附图B。这段图注告诉读者图里有什么、没有什么、关键参数是什么、去哪里找更多信息。读者看完图注对图的边界就清楚了。7.4 定期回顾和清理旧图图是会过期的。系统改了图没改图就从资产变成了负债。我的做法是每个季度花半小时把版本库里的图过一遍标记出已过期的图要么更新要么删除。判断图是否过期的标准很简单如果这张图描述的系统已经变了而图没变它就是过期的。不要舍不得删过期的图比没有图更危险因为它会误导人。8. 关于图表设计这件事我最后想说的画图这件事入门很容易画好很难。难的不是工具操作而是想清楚。想清楚读者是谁、想清楚要表达什么、想清楚哪些信息可以舍弃。这些想清楚了用什么工具画都是次要的。我自己的体会是每次画图之前花五分钟在纸上写写画画比直接打开工具省时间得多。因为工具会诱惑你去调样式而样式是最不重要的东西。内容对了样式朴素一点没关系内容错了样式再漂亮也是白搭。另外不要追求一次画到完美。图是改出来的第一版能表达清楚主干逻辑就行细节可以后续迭代。我见过太多人因为追求完美一张图拖了一周还没发出去最后不了了之。先完成再完美这个原则在图表设计上同样适用。如果你只能记住一件事那就记住这个图是给读者看的不是给自己看的。每次画完找个不知情的人试读一下比你自己检查十遍都管用。