技术图解全攻略：从场景判断到视觉表达，让图表真正传达信息

入行这么多年我发现自己最花时间的事情不是写代码也不是开会而是时不时就被某张画得乱七八糟的图堵住嘴。上周评审同事贴了一张全系统架构图硬是讲了二十分钟大家还是没搞清楚核心链路长什么样线绕来绕去颜色不分主次二十多个模块摊在一个页面里。散会后他自己也承认这图从设计之初就没想清楚要给谁看、要表达什么。这就是我一直想专门聊聊 diagram-design 的原因。很多人以为画图嘛打开 draw.io 拖几个框连几条线就完事。但真正走进 diagram 设计这个领域之后你会发现一张好图和一张废图之间差的是场景判断、工具选型、信息架构和视觉表达这一整条方法论。而且这套方法论往大了说能支撑方案评审、技术文档、系统设计往小了说也能让你在做 PPT、写博客、做产品原型时直接受益。这篇文章我会从实际工程项目的视角把我这些年从能画出图到能设计出图的全过程拆给你看。不管你是程序员、架构师、产品经理还是技术写作者只要你的日常离不开画图表达这篇文章都适合你。下面我按自己现在的工作习惯把 diagram 设计的整个链路从头到尾过一遍。1. 落笔之前先想清楚这张图到底要放在哪个场合这是我踩过最大的一次坑也是我现在带新人时一定会问的第一个问题。很多人打开画图工具的第一反应是我该用什么图但正确的问题其实是这张图会被谁、在什么场景下看到。同样的内容画给评审会投屏用、画给方案文档做存档、画给前端开发当对接依据这三种场景对信息密度的要求完全是三个物种。1.1 评审会投屏图字要大关系要少评审现场的图是给人扫一眼的不是给人读一遍的。我记得有个老架构师跟我说过一句话特别有道理投屏图要让坐在最后一排的人不用眯眼就能看到核心模块的名字。所以这类图的信息密度必须极度克制。一个系统如果你有八个核心模块投屏图上只需要放最关键的三个到四个剩下的可以折叠成一行其他依赖。字体方面我的经验是锚点节点的字号不要低于 14pt最好 16pt 起。连线上如果想写字字号也不能小于 12pt否则投出来就是一团糊。至于节点数量一个屏幕里最佳信息量控制在五到七个可以记忆的元素之间再多人的工作记忆就装不下了你讲得再卖力台下的反馈也只能是点头装作听懂。1.2 方案文档存档图信息完整优先于页面美观文档里的图就不一样了它可以容纳更多细节。因为读者有足够的时间慢慢看看不懂还能往前翻上下文。我自己在写技术方案时架构图、时序图、部署图都需要完整表达包括模块之间的接口名、端口号、协议类型、依赖关系这些都要画进去。但文档图也有它的坑最常见的毛病是一张图想把什么都说完。我见过有同事画了一张巨型架构图把微服务、数据库、消息队列、定时任务、配置中心、监控系统全部塞进去还试图用颜色区分十几个团队的项目归属结果放到文档里字号被缩到 9pt打印出来什么都看不清。正确的做法是文档图同样要拆分一张总览图负责交代系统边界和核心组件另外单独画依赖细节图和服务清单图。1.3 给开发当对接依据的图精确到命名而不是形状画给研发团队做为开发依据的图强调的不是看起来好看而是歧义为零。以我个人管理项目接口的经验调用关系里的每一个箭头都要能对应到真实的 API 或者消息topic消息名、方法名、参数类型尽量直接标在线上不要让人猜。这类图文字信息密度最高节点之间的连线必须编码清晰什么时候用实线、什么时候用虚线都要提前定义好图例。这类图通常是开发团队的宪法我建议它直接进代码仓库用 draw.io 的 xml 格式或者 Mermaid 代码来维护。这样改动可以被 Git 记录出了问题能回溯到具体某次提交后面我会专门用一节来讲这个事。2. 按表达诉求选图型别按图谱名字生搬硬套很多人一想到画图脑子里冒出来的就是流程图、架构图、时序图。但真正做设计时我会先把我要表达的内容拆成结构关系、时间顺序、状态迁移、资源拓扑这四大类再看哪类图能跟我的诉求对上。名字只是约定俗成的标签关键在于你的内容是空间维度的还是时间维度的。2.1 用意图倒推图型四种核心表达诉求我先给一个我常用的决策表你在画图之前可以对着它找方向你的表达诉求核心维度推荐图型典型场景想表达有什么、彼此什么关系空间/结构架构图、ER图、模块关系图系统总览、数据库设计想表达先做什么、后做什么时间/逻辑流程图、活动图业务流程、算法逻辑想表达多角色之间如何交互时间/顺序时序图接口调用链、支付流程想表达某种对象的状态怎么变状态/事件状态机图订单状态、任务生命周期这套表看起来简单但特别实用。我见过最典型的误用就是把多服务之间调用顺序画成了一整张流程图箭头乱飞根本看不出先后顺序。换成时序图之后参与者竖着排消息横着发谁先请求谁、谁返回什么一目了然。2.2 一张图只讲一件事这是 diagram 设计里我最想强调的一条铁律一张图只表达一个中心思想。如果你发现自己画着画着需要右上角加一块说明一下缓存策略、左下角加一块顺便展示一下容灾备案那恭喜你你已经成功地把这张图变成了什么都说了什么都说不清的典型代表。比如你要设计一个电商系统逻辑架构图管模块划分和依赖方向时序图管下单主链路的消息顺序部署拓扑图管网关、应用、缓存、数据库落在哪些环境里。三张图各司其职合在一起才是一个完整的系统设计。强行合成一张图最终效果一定是既不能指导开发也不能应付评审。2.3 跨层连线的处理图里最脏的地方选对图型之后还有一个高频致命伤就是跨层连线。不少人在一张架构图里让底部的数据库直接用箭头连上了顶部的网关因为这个接口确实直接调了库。从代码事实来说没错但从设计表达来说这会让层级关系瞬间作废。看到这种线读者心里第一反应不是哦这个接口直连了而是这张图的边界到底画在哪里。我的经验是如果跨层调用是真实存在且绕不开的那恰恰说明你的架构缺少一层抽象你该做的是在中间补一个服务层或数据访问层节点而不是用一根长线硬跨三层。长线跨层是图里的视觉噪音也是架构设计里嗅觉敏感的人一眼就能闻到的问题。3. 工具用顺手了设计效率直接翻倍工欲善其事必先利其器。 diagram-design 这件事工具占比至少有四成。我这两年用得最多的组合其实很稳定draw.iodiagrams.net负责给人读的图Mermaid 负责进代码仓库的图偶尔用 Excalidraw 做非常早期的头脑风暴手稿。下面我把每类工具的实际使用边界和踩坑经验展开讲一讲。3.1 三类工具的适用边界市面上的画图工具看起来多到选不过来但本质上是三种路线的产物。第一种是拖拽型图形工具代表是 draw.io、Visio、ProcessOn你手动摆放每个节点的位置和连线优点是完全可控缺点是大图调整布局很费手。第二种是代码化制图工具代表是 Mermaid、PlantUML、Graphviz你写代码描述结构工具自动排布优点是文本可维护、能进 Git缺点是复杂结构下自动布局经常歪歪扭扭控制力弱。第三种是在线白板类工具像 FigJam、Miro特别适合多人头脑风暴阶段但不适合产出正式交付物。我见过不少团队从头到尾只抱着一个工具不放。只拖图形工具的结果是文档里的图三天两头失联版本管理基本靠存档_最终版_v3_最终版2.xml这种文件名只用代码化工具的结果是稍微复杂一点的架构图就会画出一种凌乱的拓扑而且想精确控制节点位置时非常绝望。我的建议是不要把工具当成立场按交付场景选工具这才叫设计。3.2 draw.io 里的几个关键设置如果你打算用 draw.io 做正式图交付有几个设置我建议画图之前就先调好第一设置画布为网格裁剪框。网格对齐听着基础实际上是让节点边缘自动吸附在网格上图面立刻规整。第二统一默认字体和字号。draw.io 支持样式模板我习惯先画一个节点设置好字体中文建议思源黑体英文建议 Inter和配色然后右键设为默认样式这样后面拖出来的新节点不会五颜六色、字体大小混乱。第三用好图层功能。复杂的图可以把背景水印、核心链路、外围依赖放到不同图层里需要演示时一键切换导出文档时也能按需隐藏。还有一个很多人不知道的小技巧draw.io 文件默认以 xml 格式保存这个文件其实可以直接放进代码仓库做 diff。比如这次评审后你改了某个模块的颜色在 GitLab 合并请求里能清楚看到哪几个字段变了对多人协作特别实用。我后面章节会专门讲文件管理。3.3 Mermaid 的代码化实践Mermaid 这种代码化制图最大的优势就是图跟着文档走。我在写技术方案 Markdown 时时序图和流程图直接用 Mermaid 代码块嵌进去评审时预览即所得文档发布后图也跟着更新。再也不用画一张图、导出一张 PNG、再插进文档三步走了。但 Mermaid 有个明显短板就是布局。graph TD从上到下或者 graph LR从左到右往往会因为文本长度不同导致节点大小不一、线绕来绕去。我的实践经验是Mermaid 适合画依赖关系不超过十几条的中小型图如果节点和连线数量巨大还是老老实实用 draw.io 手排。还有一个细节subgraph 子图命名别用中文很多 Mermaid 渲染器对中文子图名的排版支持很一般会出现奇怪的换行。3.4 工具选型对比表我整理了一张表适合供你参考主力工具怎么搭配工具适用场景文件格式版本管理友好度上手成本draw.io架构图、部署图、给人精读的正式图xml/svg/png高xml 可 diff低Mermaid文档内嵌流程、时序、状态图文本块高纯文本低PlantUML复杂时序图、活动图文本块高纯文本中Excalidraw手绘风草稿、创意发散文本/scene中极低FigJam/Miro团队共创、贴便利贴阶段云文档低低4. 信息架构别一上来就摆方框先给图画个大纲我观察到一个规律画图水平一直上不去的人通常是一上来就拖一个方框出来打字然后满画布找位置放第二个框。这不是设计这是记录琐事。专业做法是像写文章一样先给图写大纲确定这张图的分区、层级、焦点然后才动手落形。4.1 图的大纲怎么写一张结构清晰的图本质上是一篇用图形写成的短文。标题对应图的主题分区对应章节群组对应段落节点对应句子。所以我不是直接画而是在草稿纸上或者直接在画布里先画一个隐性骨架这个图分几个区、每个区放哪些元素、区与区之间什么关系、哪里是读者第一眼要看到的主路径。举个例子画系统部署图之前我脑子里的分区是这样的顶部是用户入口和负载均衡中间是应用服务层底部是数据层左侧划一个边界叫外网 DMZ 区右侧划边界叫内网核心区。每个区域之间的箭头方向都想好了才开始真正拖框画起来基本不会返工。4.2 视觉分组的三种手段分区想清楚之后怎么让读者一眼就看到这些是一组视觉设计里有三个基础手段按优先级排是邻近性、相似性、连接线。距离最近的两块内容人脑天然会认为有关系所以组内元素间距要小、组间间距要大这是最便宜也最有效的手法。其次是用相同的底色或边框把同一类模块统一起来让读者在扫图的瞬间就能按颜色完成归类。连接线反而是最不该一上来就乱拉的。不少新手会把有关系的节点全部连上线结果满屏都是交叉和缠绕。正确原则是能用位置和颜色表示的归属关系就不要用线线只表达不可替代的强语义比如调用、依赖、流转。4.3 冗余与瘦身让图学会做减法Diagram 设计里最难的不是加东西而是不加东西。我给自己定的经验法则是超过二十个节点的图必须拆分成多个子图或者用图例和容器把细节收纳起来。人一眼能处理的元素数量非常有限二十个节点同时铺开在认知上已经接近灾难了。实际操作时我常用三个瘦身手法。第一是归纳重复结构图里出现的多个微服务如果模式雷同抽取一个代表节点加×N标注细节放进附表。第二是图例化一些通用说明、协议颜色、箭头含义放到图例区统一说明不要在每个节点旁边各写一遍。第三是延迟展开核心链路图只画主干分支和异常处理用页码标注跳到附录的图。设计本来就是有舍有得展示范围本身就是一种表达。5. 视觉表达颜色、字体、线条的一次完整规范信息架构解决的是图该有什么视觉表达解决的是读者怎么看的时候最不费劲。我见过很多人花大把时间调颜色渐变、阴影、圆角却把最基本的信息对比度搞砸了。视觉设计不是为了好看而是为了降低认知成本。5.1 颜色语义化五种颜色封顶我对颜色使用的原则只有一条先默认灰阶再逐级点亮彩色。主结构用黑白灰表达需要强调的焦点、主路径、危险项才用彩色。彩色数量绝对不要超过五种而且每种颜色必须承担固定语义整张图内不得改嫁。我自己的习惯语义是蓝色代表核心服务和主流程绿色代表状态健康的依赖或者外部成功路径黄色代表警告、需要关注的设计点红色代表错误、不可达或删除项紫色代表第三方外部系统。这个语义在整套文档里保持一致读者第一次看图可能还要扫一眼图例第二张图开始就能直接按颜色定位了。颜色一旦太多图从远处看就是一块花布完全失去聚焦能力。5.2 字体的等级系统Diagram 里的文字不是随便写的它有明确的等级。一级文字是图标题最大的字号告诉读者这是什么二级文字是核心节点名和关键连线标签二阶中号加粗三级文字是注释、图例、边角说明最小但要保持可读。一套图里不应该出现三种以上的字号否则整个画面会显得处处想强调、处处没重点。中文字体环境要特别注意宋体在屏幕上小字号渲染发虚我一般推荐中文内容使用开源黑体族例如思源黑体、阿里巴巴普惠体。英文可以使用 Inter 或者 Helvetica。字体的统一比选什么字体更重要乱七八糟的字体混排会让一张图立刻暴露业余。5.3 连线与箭头格式即语义线条是 diagram 设计里信息语义最强的一环也是最容易被随手乱画的一环。我的规范是这样的边框用 1.5px表达容器和模块的形状边界主流程连线用 2px 实线承载核心链路弱依赖或异步消息用 1px 虚线数据流和调用流用带箭头的实线。同一根连线上如果又想表达数据流向又想表达调用时序那基本可以断定又要画脏了回到第 2 节重新选图型。形状也有语义矩形代表处理单元圆角矩形代表用户界面或交互入口菱形只出现在流程图里代表判断圆柱体代表存储。这些形状语义是行业通用语言不要自创符号然后指望别人看得懂。真的有必要自创时一定要在图中明显位置放一个图例把符号的解释写清楚。5.4 网格、对齐与留白最后一个小但致命的地方是排版。我评审图时最先看的不是内容而是节点边缘是否对齐、同类元素的间距是否一致。如果节点都是垂直居中对齐、间距相等即使配色朴素画面也会有一种专业感反之哪怕颜色很漂亮只要节点歪七扭八观感瞬间垮塌。这个细节不用多说检查方法就是一个在 draw.io 里全选然后看对齐工具箱里的垂直居中、水平均匀分布是否被击中。留白同样值钱。节点之间不要挤成一团下图和下图之间留有呼吸空间读者扫图时才不会产生窒息感。尤其是投屏演示的图适当的留白比塞满内容重要得多。6. 存档、版本管理与协作让图在团队里活起来很多团队的技术文档里图是最容易腐化的资产。架构改了三个月架构图还停留在三个月前新同事入职想通过图了解系统看到的却是明显过时的内容。diagram-design 不只是画的那一下还包括后续的维护方式。6.1 图文件的管理边界我现在已经不接受某某架构图最终版.png这种文件了。正式交付的图必须保留源文件而且源文件能放进代码仓库最好。draw.io 的 xml 格式很适合这么做你可以建一个 diagrams 目录文件名对应图的内容提交时写清楚变更信息形成和代码同步演进的历史记录。Mermaid 就更不用说了本身就是文本可以直接嵌入 Markdown 文档作为一等公民。如果团队暂时没有代码仓库管理图的习惯至少也要约定一个命名规范。我见过最乱的目录是同一个文件七八个版本复制粘贴散落各处真正的崩溃在于根本分不清哪个最新。最低限度命名里带上日期和修改人例如order-pipeline_20250115_lisi.drawio.xml一旦版本冲突还有追溯余地。6.2 多人协作时的绘图约定当多个人同时维护一套图的时候没有约定的协作一定走向混乱。我建议团队内部定三件小事第一公共图库目录结构统一比如 resources/diagrams 下分 arch、flow、deploy 子目录第二图层归属说明如果图里有谁负责维护的区域在这个区域里写一段注释文字标上 owner 的名字第三Review 机制图的变更像代码一样需要评审在合并请求里说明改了什么结构、为什么调整。你可能觉得画个图还要走评审流程是不是过度工程了。但从我的实际经验看图的错误传播速度比代码更快——代码报错编译过不了图错了可是能误导一群人一年。所以维护图的质量本质上是在维护团队对系统的理解模型。6.3 评审意见如何驱动图迭代评审会上关于图的反馈通常分两类。一类是内容缺失型这里是不是少了一条链路这个模块的 owner 是谁这类反馈表明你的图覆盖面不够先别着急调样式回到第 4 节的信息架构把缺失的模块补上。另一类是信息过载型太复杂了看不懂能不能把 XXX 单独画一张这说明图试图承载的话题太大了切分图或者折叠细节到附录。我自己画图向来有个心态准备图是改出来的不是一次画出来的。收到意见时别把改图当成挫败而是把每次评审当成对表达的一次打磨。通常一张核心架构图经过两三轮评审迭代才会真正达到新同事也能一眼看懂的状态。7. 把图嵌入更大的生产链路从画图到工程化设计完一张图不是终点让图变成研发流程的一部分才算活的资产。我最近这一年的实践重心已经偏向图即代码、图随文档走这个方向。7.1 文档里的图源文件直接可编辑在写技术方案时我强烈建议不要让最后的图变成一张不可编辑的图片。在 Markdown 技术方案里嵌入 Mermaid 代码块或者使用 draw.io 的嵌入模式读者点击图片就能打开源文件继续改这种体验比贴一张死图片好太多。对团队知识库来说这直接决定了文档维护意愿如果能点开即改大家就愿意顺手更新如果每次都要到某个共享盘里找源文件绝大多数人选择了默默不改。7.2 用脚本和图谱自动生成图的实践进阶一点的做法是数据驱动生成图。比如你在 Kubernetes 集群里有大量服务时手动画微服务拓扑图一定会过时。可以写一段脚本读取服务注册信息然后输出 Graphviz 或 Mermaid 的声明文件自动生成一版服务依赖图。我尝试过之后发现这种自动生成的图有一个共同问题布局通常不太好看节点位置由算法决定常常与人的直觉不一致大型图依然没法直接用。所以我目前的取舍是自动生成图适合做巡检视角的辅助图用来快速发现服务之间的异常依赖手动设计的图适合做交付物视角的架构表达仍然需要人工精心布局。两者互补不要互相替代。7.3 导出与发布时的格式细节最后补充一个容易被忽略的细节。如果你画好的图要投放到不同介质导出格式要把握好。投屏用 PNG 或者 PDF 都能胜任但要注意分辨率draw.io 导出时把缩放比例设到 200%保证在大屏上不糊。要放在网页或者文档里的SVG 是更好的选择缩放无损、体积小。不要直接把 draw.io 的田字格背景导出去发给人看那些网格是编辑痕迹正式交付前记得关掉网格和背景。另外一个我常用的发布技巧是给图纸底部留一行说明写上模块边界、版本号、维护人、最后更新日期。这张图一旦进入公共领域遇到内容过时的反馈可以直接找维护人而不是满群问这图谁画的。跟你说句实在话我见过太多优秀的系统被糟糕的图表拖累了表达。画图这件事用到后面拼的真的不是工具熟练度而是设计思维能不能为读者降低认知负担能不能让复杂逻辑变得一目了然。你在画下一张架构图之前可以先从给图写一个小图例、删掉两条没必要的连线、统一一次字体做起。自己看着舒服别人读起来才会舒服。