1. 从diagram-design这个标题能读出什么第一次看到diagram-design这个标题我脑子里蹦出来的第一个念头是这大概率不是一个单纯的画图工具推荐而是一套关于图表设计方法论的沉淀。为什么这么说因为如果只是推荐工具标题通常会带上具体产品名比如用XX画架构图而diagram-design这种偏抽象的命名方式往往意味着作者想聊的是设计这件事本身——怎么把一团乱麻的信息变成一张让人一眼看懂的图。图表设计这个领域表面上看是审美问题实际上核心是信息架构问题。我见过太多人画架构图把十几个服务、二十几条调用关系全塞进一张图里线条交叉得像蜘蛛网最后自己都说不清哪个箭头指向哪个。这不是画图工具的问题是设计思路的问题。所以这篇内容我想聊的不是某个具体软件怎么用而是从信息梳理到视觉呈现的完整链路——包括为什么要这样分层、为什么箭头方向有讲究、为什么颜色不能超过几种、为什么有些图注定要拆成三张。适合谁看如果你是后端开发、产品经理、技术文档写作者或者任何需要把复杂系统讲清楚的人这篇内容应该能帮到你。哪怕你平时只用最基础的绘图工具只要思路对了画出来的图也不会差。反过来工具再高级思路混乱图还是废的。我自己的经验是图表设计能力是被严重低估的一项职场技能。一份好的架构图能让评审会少开半小时一张清晰的流程图能让新同事上手快一周。但很少有人系统性地去练这个大家都是能画出来就行。这篇文章想改变的就是这种差不多就行的状态。2. 图表设计的第一性问题你到底想让谁看懂2.1 受众决定了图的颗粒度在动手画任何一张图之前我都会先问自己一个问题这张图是给谁看的这个问题听起来很废话但它直接决定了图的颗粒度、术语密度和视觉复杂度。给同组工程师看的图可以出现具体的类名、方法名、中间件版本号因为大家有共同的上下文不需要解释什么是消息队列。但给管理层或跨部门同事看的图就得把技术细节抽象掉用订单服务库存服务这种业务语言箭头代表的是业务流转而不是RPC调用。我踩过的最典型的坑就是拿一张给组内看的详细架构图去给非技术背景的领导汇报结果对方盯着满屏的英文服务名问这个方框是干嘛的场面一度很尴尬。所以我的做法是同一套系统准备至少两个版本的图。一个技术版保留完整细节用于内部评审和文档一个业务版只保留核心模块和数据流向用于对外沟通。两个版本不是简单删减而是重新组织——业务版可能把三个微服务合并成一个订单域因为对受众来说这三个服务的区分没有意义。2.2 一张图只讲一件事新手最容易犯的第二个错误是想用一张图讲完整个系统。结果就是图越来越大信息越来越密最后谁也看不懂。我的原则是一张图只回答一个问题。比如系统的整体分层是怎样的是一张图下单请求经过了哪些服务是另一张图数据是怎么存储和同步的又是第三张图。这三张图各自独立但组合起来能完整描述系统。这就像写文章分段落你不能把所有内容塞进一个自然段里。具体操作上我会先列一个问题清单这张图要回答什么问题读者看完应该能说出哪句话如果这个问题能用一句话概括那这张图的目标就清晰了。比如读者看完能说出请求先经过网关再分发到三个业务服务最后写入主库和缓存——这就是一个合格的图目标。2.3 信息层级比美观更重要很多人一上来就纠结配色、字体、圆角但图表设计的核心其实是信息层级。什么是信息层级就是读者看这张图时眼睛应该先看哪里、再看哪里、最后看哪里。好的图表设计读者的视线路径是被设计过的。通常来说核心模块应该最大、最醒目辅助模块次之边缘细节最小最淡。颜色、大小、位置、线条粗细都是用来建立层级的工具。我见过一些图每个方框都一样大、一样粗的边框、一样深的颜色读者根本不知道重点在哪只能从头到尾逐个读效率极低。我的经验是先定层级再定样式。具体做法是把图里的元素分成三层——核心层必须一眼看到、支撑层需要时能找到、背景层知道存在即可。核心层用深色、大字号、粗边框支撑层用中等灰度背景层用浅灰或虚线。这样即使不加任何装饰图的可读性也已经及格了。3. 从信息到图形的转换我常用的四种图表类型3.1 分层架构图讲清楚谁在上面谁在下面分层架构图是最常见的类型适合描述系统的纵向结构。它的核心是层次划分和层间关系。画分层图时我习惯从上到下按用户接触顺序排列最上面是用户入口Web、App、API然后是网关层再是业务服务层接着是数据层最下面是基础设施层。这个顺序符合大多数人的认知习惯读者从上往下看就像跟着一个请求走了一遍。每一层内部我会用横向排列的方框表示并列的模块。这里有个细节同一层内的模块左右顺序最好有逻辑。比如业务服务层里如果按调用顺序排列订单服务在左库存服务在右因为下单要先扣库存读者理解起来会更快。如果随便排读者就得自己找关系。层与层之间的箭头我一般只画主要的调用方向不画双向箭头。双向箭头会让图变得混乱而且大多数情况下调用是有主次的。如果确实存在双向依赖我会用两条平行的单向箭头或者用不同颜色区分。3.2 时序流程图讲清楚先发生什么后发生什么时序图适合描述一个具体业务流程比如用户下单或支付回调。它的核心是时间顺序和参与者。画时序图时我习惯把参与者按从左到右的交互顺序排列。比如用户在最左然后是前端、网关、订单服务、库存服务、数据库。这样箭头从左往右走符合阅读习惯。如果参与者太多超过六个我会考虑拆成两张图或者把一些次要参与者合并。时序图最容易出的问题是箭头太多太乱。我的处理原则是只画关键路径上的调用异常分支和补偿逻辑用注释说明不画进主图。比如下单流程主图只画创建订单→扣库存→返回成功至于库存不足时的回滚逻辑可以在图下方用文字补充。这样主图清爽细节也不丢失。3.3 数据流图讲清楚数据从哪来到哪去数据流图适合描述数据的流转和转换比如ETL流程、事件驱动架构。它的核心是数据源、处理节点、数据终点。画数据流图时我会用不同形状区分数据存储和处理过程。通常用圆柱体表示数据库或存储用圆角矩形表示处理逻辑用箭头表示数据流向。箭头上会标注数据格式或关键字段比如订单事件JSON。数据流图的一个常见误区是把控制流和数据流混在一起。控制流是谁触发谁数据流是数据从哪到哪。这两者混画会让图变得难以理解。我的做法是如果一张图里两者都有用实线画数据流虚线画控制流并在图例里说明。3.4 状态机图讲清楚一个东西有哪些状态状态机图适合描述有明确状态流转的实体比如订单状态、工单状态。它的核心是状态集合和转移条件。画状态机图时我会先列出所有可能的状态然后用箭头连接有转移关系的状态箭头上标注触发条件。这里的关键是穷举状态不能遗漏。我见过一些状态机图只画了正常流程的状态异常状态如已取消已退款没画结果开发时才发现漏了。状态机图的布局也有讲究。我习惯把初始状态放在最左或最上终止状态放在最右或最下中间状态按流转顺序排列。如果状态之间有循环比如待支付→已支付→已发货→已完成但已支付可以退款回到已退款循环的箭头要画得明显避免读者误以为只能单向流动。4. 视觉规范那些让图看起来专业的细节4.1 配色三种颜色足够五种是上限配色是图表设计里最容易过度发挥的地方。我见过有人用彩虹色画架构图每个模块一个颜色结果图看起来像儿童画。我的配色原则是主色一种辅助色一到两种中性色若干。主色用于核心模块辅助色用于次要模块或强调中性色灰、白用于背景和边框。这样整张图的色彩是克制的读者的注意力会集中在信息本身而不是颜色上。具体选色时我会避免高饱和度的纯色比如纯红、纯蓝因为太刺眼。稍微降低饱和度、提高明度看起来会更舒服。如果一定要用红色表示警告或错误那红色只用在真正需要警示的地方不能到处都是。还有一个细节同一张图里相同含义的元素用相同颜色。比如所有数据库都用同一种蓝色所有外部系统都用同一种灰色。这样读者不用看图例就能猜到元素类型。4.2 字体与字号可读性优先字体选择上我倾向于无衬线字体因为屏幕阅读更清晰。字号方面正文不小于12px标题不小于16px。如果是打印或投屏字号还要再大一些。字号的层级也要设计。通常我会设三档图标题最大模块名称次之注释文字最小。三档之间差距要明显比如20px、14px、11px这样层级一眼可见。如果字号差距太小比如14px和13px读者根本分不出来。还有一个容易被忽略的点文字不要压在线上。箭头穿过文字会让文字难以阅读。如果空间紧张宁可把文字放在箭头旁边或者用引线标注。4.3 线条与箭头方向比粗细重要线条的粗细可以用来表示关系的强弱或数据量的大小但大多数情况下统一粗细就够了。我见过有人用不同粗细的线表示调用频率结果读者根本分不清哪根更粗反而增加了理解成本。箭头方向比粗细重要得多。箭头必须明确指向调用方向或数据流向不能有歧义。如果两个模块互相调用用两条单向箭头不要用一条双向箭头。双向箭头在视觉上容易让人困惑到底是同时双向还是交替双向线条的样式也可以承载信息。实线表示同步调用虚线表示异步消息点线表示可选依赖——这些约定如果在图例里说明能大大提升图的信息密度。4.4 留白让图呼吸新手画图往往把空间填得满满的觉得留白是浪费。但实际上留白是图表设计的重要工具。适当的留白能让图看起来更清晰模块之间的关系更明确。我的经验是模块之间的间距至少是模块内部文字高度的1.5倍。层与层之间的间距至少是层内模块间距的2倍。这样层次感自然就出来了。如果图太密宁可拆成两张也不要硬塞。一张拥挤的图读者看两眼就放弃了两张清爽的图读者愿意看完。5. 工具选型不同场景用什么画5.1 快速草图纸笔或白板工具如果是头脑风暴阶段我强烈建议先用纸笔或白板工具画草图。这个阶段不需要考虑美观只需要把想法快速可视化。纸笔的好处是零门槛、零延迟想到什么画什么。白板工具如各类在线白板的好处是可以多人协作适合团队讨论。这个阶段画出来的图大概率不会出现在最终文档里但它是后续所有工作的基础。我见过有人跳过草图阶段直接打开专业工具开始画结果画到一半发现思路不对全部推翻重来。先用草图验证思路成本最低。5.2 正式文档结构化绘图工具如果是写进技术文档、需要长期维护的图我会用结构化绘图工具。这类工具的特点是图形元素有语义比如数据库和服务是不同的形状支持自动布局修改方便。结构化工具的好处是当你增删模块时布局会自动调整不需要手动拖拽。而且导出的图风格统一适合放进文档。缺点是学习成本比自由绘图工具高一些但一旦掌握效率提升明显。5.3 演示汇报自由绘图工具如果是给领导汇报或对外演讲我会用自由绘图工具。这类工具的特点是想怎么画就怎么画不受模板限制视觉效果可以做得更精致。自由绘图工具的缺点是修改起来麻烦而且容易画得太花。所以用这类工具时我会更严格地遵守前面说的配色和层级原则避免过度设计。5.4 代码生成适合频繁变更的图如果图的内容会频繁变更比如系统架构经常调整我会考虑用代码生成图。这类工具用文本描述图形改起来方便而且可以纳入版本管理。代码生成图的缺点是布局控制不如手动灵活复杂图可能需要反复调整代码才能达到理想效果。但对于结构清晰、变更频繁的图这个投入是值得的。场景推荐工具类型核心优势注意事项头脑风暴纸笔/白板零门槛、快速不追求美观技术文档结构化绘图语义清晰、易维护学习成本略高演示汇报自由绘图视觉精致、灵活避免过度设计频繁变更代码生成版本管理、易修改布局控制较弱6. 实操中踩过的坑与应对经验6.1 图太大拆图比缩放更有效我做过一张全系统架构图试图把所有模块都放进去。结果图大到需要A3纸才能打印投屏时字小得看不清。后来我把它拆成了四张图整体分层图、核心业务流程图、数据存储图、部署拓扑图。每张图只讲一个方面组合起来反而更完整。拆图的原则是按问题拆不按模块拆。比如订单系统和库存系统是两个模块但如果它们之间的交互是重点那应该有一张图专门讲下单时的库存扣减流程而不是把两个模块各画一张图。6.2 箭头混乱减少交叉的布局技巧箭头交叉是图表设计里最头疼的问题。我的应对技巧有几个第一调整模块顺序。如果A调用C、B调用D那按A-B-C-D排列箭头就不会交叉如果按A-C-B-D排列箭头就会交叉。所以画图前先理清调用关系按关系排列模块。第二分层布局。把调用关系多的模块放在同一层减少跨层箭头。比如三个服务互相调用就放在同一层横向排列不要一个放上层一个放下层。第三用颜色区分。如果实在无法避免交叉用不同颜色的箭头区分不同的调用链读者可以顺着颜色追踪。6.3 图例缺失读者不是你我早期画图经常忘记加图例觉得这么明显还需要解释吗。但读者不是你他不知道你的约定。比如你用虚线表示异步读者可能以为是可选你用蓝色表示数据库读者可能以为是外部系统。所以每张图都应该有图例哪怕只有两三个元素。图例不需要复杂简单说明形状、颜色、线条样式的含义即可。这个习惯能省掉很多沟通成本。6.4 版本混乱命名和归档要规范图表和代码一样会有多个版本。如果没有规范的命名和归档很快就会乱套。我的做法是文件名包含日期和版本号比如系统架构图-v2.1-20240115。同时在文档里引用图时注明版本避免读者看到旧版本。如果图是代码生成的那就更简单了直接纳入版本管理每次变更都有记录。7. 图表设计的进阶思路从能看懂到好记忆7.1 用视觉隐喻降低理解成本好的图表设计能让读者秒懂。做到这一点的关键是用视觉隐喻。比如把网关画成一道门把消息队列画成一个管道把缓存画成一个抽屉。这些隐喻不需要文字解释读者一看就明白。当然隐喻不能滥用。如果每个模块都画成具象图形图会变得很花反而分散注意力。我的做法是核心模块可以用隐喻辅助模块保持抽象。比如网关用门的形状但数据库还是用标准圆柱体。7.2 用分组和边框建立视觉容器当图里有多个相关模块时用分组边框把它们框起来能大大提升可读性。比如三个服务都属于订单域就用一个虚线框把它们框在一起标注订单域。这样读者一眼就能看出这三个服务是一组的。分组边框的样式也有讲究。我通常用浅色虚线避免边框太抢眼。分组名称放在边框的左上角或顶部居中字号比模块名称小一档。7.3 用注释补充图外信息图能表达的信息是有限的。有些背景、约束、假设无法用图形表达但读者需要知道。这时候就用注释。注释的位置通常在图的空白处用引线指向相关模块。注释文字要简短一句话说清楚。如果注释太长说明这个信息可能更适合放在正文里而不是图上。7.4 用一致性建立系列感如果一组图是同一个系统的不同视角它们应该有一致的视觉风格相同的配色、相同的字体、相同的图例约定。这样读者在看第二张图时不需要重新学习视觉语言理解成本大大降低。一致性还体现在命名上。比如第一张图叫整体架构图第二张叫订单流程时序图第三张叫数据存储架构图——命名风格统一读者一看就知道这是一套图。8. 我个人的几条硬核经验最后分享几条我这些年画图总结出来的硬核经验都是踩过坑之后才明白的。第一条先写文字再画图。如果你不能用一段文字把要画的内容说清楚那图也画不清楚。我现在的习惯是先用文字列出图的要点确认逻辑通顺了再动手画。第二条找个人讲一遍。图画出初稿后找一个不了解这个系统的同事让他看图说一遍他理解的内容。如果他说错了说明图有问题。这个方法比自我检查有效得多。第三条图是给人看的不是给机器看的。不要追求完整要追求清晰。一张图漏掉一些细节没关系只要核心信息传达到了就是好图。反过来信息再全读者看不懂也是废图。第四条定期回顾旧图。系统在演进图也要更新。我每季度会花半天时间把核心架构图过一遍看看有没有过时的地方。这个习惯能避免图与系统不符的尴尬。第五条不要迷信工具。工具只是工具思路才是核心。我见过用最基础工具画出极清晰架构图的人也见过用最贵工具画出垃圾的人。把精力花在信息梳理和层级设计上比花在工具学习上回报高得多。图表设计这件事说到底是一种信息表达能力。它和写文档、做汇报一样核心都是把复杂的事情讲简单。这个能力没有捷径就是多画、多看、多改。画得多了自然就有感觉了。 
长河君 · 2026/10/19 5:54:36 · 阅读 1.2k 图表设计方法论：从信息架构到视觉呈现的完整链路
1. 从diagram-design这个标题能读出什么第一次看到diagram-design这个标题我脑子里蹦出来的第一个念头是这大概率不是一个单纯的画图工具推荐而是一套关于图表设计方法论的沉淀。为什么这么说因为如果只是推荐工具标题通常会带上具体产品名比如用XX画架构图而diagram-design这种偏抽象的命名方式往往意味着作者想聊的是设计这件事本身——怎么把一团乱麻的信息变成一张让人一眼看懂的图。图表设计这个领域表面上看是审美问题实际上核心是信息架构问题。我见过太多人画架构图把十几个服务、二十几条调用关系全塞进一张图里线条交叉得像蜘蛛网最后自己都说不清哪个箭头指向哪个。这不是画图工具的问题是设计思路的问题。所以这篇内容我想聊的不是某个具体软件怎么用而是从信息梳理到视觉呈现的完整链路——包括为什么要这样分层、为什么箭头方向有讲究、为什么颜色不能超过几种、为什么有些图注定要拆成三张。适合谁看如果你是后端开发、产品经理、技术文档写作者或者任何需要把复杂系统讲清楚的人这篇内容应该能帮到你。哪怕你平时只用最基础的绘图工具只要思路对了画出来的图也不会差。反过来工具再高级思路混乱图还是废的。我自己的经验是图表设计能力是被严重低估的一项职场技能。一份好的架构图能让评审会少开半小时一张清晰的流程图能让新同事上手快一周。但很少有人系统性地去练这个大家都是能画出来就行。这篇文章想改变的就是这种差不多就行的状态。2. 图表设计的第一性问题你到底想让谁看懂2.1 受众决定了图的颗粒度在动手画任何一张图之前我都会先问自己一个问题这张图是给谁看的这个问题听起来很废话但它直接决定了图的颗粒度、术语密度和视觉复杂度。给同组工程师看的图可以出现具体的类名、方法名、中间件版本号因为大家有共同的上下文不需要解释什么是消息队列。但给管理层或跨部门同事看的图就得把技术细节抽象掉用订单服务库存服务这种业务语言箭头代表的是业务流转而不是RPC调用。我踩过的最典型的坑就是拿一张给组内看的详细架构图去给非技术背景的领导汇报结果对方盯着满屏的英文服务名问这个方框是干嘛的场面一度很尴尬。所以我的做法是同一套系统准备至少两个版本的图。一个技术版保留完整细节用于内部评审和文档一个业务版只保留核心模块和数据流向用于对外沟通。两个版本不是简单删减而是重新组织——业务版可能把三个微服务合并成一个订单域因为对受众来说这三个服务的区分没有意义。2.2 一张图只讲一件事新手最容易犯的第二个错误是想用一张图讲完整个系统。结果就是图越来越大信息越来越密最后谁也看不懂。我的原则是一张图只回答一个问题。比如系统的整体分层是怎样的是一张图下单请求经过了哪些服务是另一张图数据是怎么存储和同步的又是第三张图。这三张图各自独立但组合起来能完整描述系统。这就像写文章分段落你不能把所有内容塞进一个自然段里。具体操作上我会先列一个问题清单这张图要回答什么问题读者看完应该能说出哪句话如果这个问题能用一句话概括那这张图的目标就清晰了。比如读者看完能说出请求先经过网关再分发到三个业务服务最后写入主库和缓存——这就是一个合格的图目标。2.3 信息层级比美观更重要很多人一上来就纠结配色、字体、圆角但图表设计的核心其实是信息层级。什么是信息层级就是读者看这张图时眼睛应该先看哪里、再看哪里、最后看哪里。好的图表设计读者的视线路径是被设计过的。通常来说核心模块应该最大、最醒目辅助模块次之边缘细节最小最淡。颜色、大小、位置、线条粗细都是用来建立层级的工具。我见过一些图每个方框都一样大、一样粗的边框、一样深的颜色读者根本不知道重点在哪只能从头到尾逐个读效率极低。我的经验是先定层级再定样式。具体做法是把图里的元素分成三层——核心层必须一眼看到、支撑层需要时能找到、背景层知道存在即可。核心层用深色、大字号、粗边框支撑层用中等灰度背景层用浅灰或虚线。这样即使不加任何装饰图的可读性也已经及格了。3. 从信息到图形的转换我常用的四种图表类型3.1 分层架构图讲清楚谁在上面谁在下面分层架构图是最常见的类型适合描述系统的纵向结构。它的核心是层次划分和层间关系。画分层图时我习惯从上到下按用户接触顺序排列最上面是用户入口Web、App、API然后是网关层再是业务服务层接着是数据层最下面是基础设施层。这个顺序符合大多数人的认知习惯读者从上往下看就像跟着一个请求走了一遍。每一层内部我会用横向排列的方框表示并列的模块。这里有个细节同一层内的模块左右顺序最好有逻辑。比如业务服务层里如果按调用顺序排列订单服务在左库存服务在右因为下单要先扣库存读者理解起来会更快。如果随便排读者就得自己找关系。层与层之间的箭头我一般只画主要的调用方向不画双向箭头。双向箭头会让图变得混乱而且大多数情况下调用是有主次的。如果确实存在双向依赖我会用两条平行的单向箭头或者用不同颜色区分。3.2 时序流程图讲清楚先发生什么后发生什么时序图适合描述一个具体业务流程比如用户下单或支付回调。它的核心是时间顺序和参与者。画时序图时我习惯把参与者按从左到右的交互顺序排列。比如用户在最左然后是前端、网关、订单服务、库存服务、数据库。这样箭头从左往右走符合阅读习惯。如果参与者太多超过六个我会考虑拆成两张图或者把一些次要参与者合并。时序图最容易出的问题是箭头太多太乱。我的处理原则是只画关键路径上的调用异常分支和补偿逻辑用注释说明不画进主图。比如下单流程主图只画创建订单→扣库存→返回成功至于库存不足时的回滚逻辑可以在图下方用文字补充。这样主图清爽细节也不丢失。3.3 数据流图讲清楚数据从哪来到哪去数据流图适合描述数据的流转和转换比如ETL流程、事件驱动架构。它的核心是数据源、处理节点、数据终点。画数据流图时我会用不同形状区分数据存储和处理过程。通常用圆柱体表示数据库或存储用圆角矩形表示处理逻辑用箭头表示数据流向。箭头上会标注数据格式或关键字段比如订单事件JSON。数据流图的一个常见误区是把控制流和数据流混在一起。控制流是谁触发谁数据流是数据从哪到哪。这两者混画会让图变得难以理解。我的做法是如果一张图里两者都有用实线画数据流虚线画控制流并在图例里说明。3.4 状态机图讲清楚一个东西有哪些状态状态机图适合描述有明确状态流转的实体比如订单状态、工单状态。它的核心是状态集合和转移条件。画状态机图时我会先列出所有可能的状态然后用箭头连接有转移关系的状态箭头上标注触发条件。这里的关键是穷举状态不能遗漏。我见过一些状态机图只画了正常流程的状态异常状态如已取消已退款没画结果开发时才发现漏了。状态机图的布局也有讲究。我习惯把初始状态放在最左或最上终止状态放在最右或最下中间状态按流转顺序排列。如果状态之间有循环比如待支付→已支付→已发货→已完成但已支付可以退款回到已退款循环的箭头要画得明显避免读者误以为只能单向流动。4. 视觉规范那些让图看起来专业的细节4.1 配色三种颜色足够五种是上限配色是图表设计里最容易过度发挥的地方。我见过有人用彩虹色画架构图每个模块一个颜色结果图看起来像儿童画。我的配色原则是主色一种辅助色一到两种中性色若干。主色用于核心模块辅助色用于次要模块或强调中性色灰、白用于背景和边框。这样整张图的色彩是克制的读者的注意力会集中在信息本身而不是颜色上。具体选色时我会避免高饱和度的纯色比如纯红、纯蓝因为太刺眼。稍微降低饱和度、提高明度看起来会更舒服。如果一定要用红色表示警告或错误那红色只用在真正需要警示的地方不能到处都是。还有一个细节同一张图里相同含义的元素用相同颜色。比如所有数据库都用同一种蓝色所有外部系统都用同一种灰色。这样读者不用看图例就能猜到元素类型。4.2 字体与字号可读性优先字体选择上我倾向于无衬线字体因为屏幕阅读更清晰。字号方面正文不小于12px标题不小于16px。如果是打印或投屏字号还要再大一些。字号的层级也要设计。通常我会设三档图标题最大模块名称次之注释文字最小。三档之间差距要明显比如20px、14px、11px这样层级一眼可见。如果字号差距太小比如14px和13px读者根本分不出来。还有一个容易被忽略的点文字不要压在线上。箭头穿过文字会让文字难以阅读。如果空间紧张宁可把文字放在箭头旁边或者用引线标注。4.3 线条与箭头方向比粗细重要线条的粗细可以用来表示关系的强弱或数据量的大小但大多数情况下统一粗细就够了。我见过有人用不同粗细的线表示调用频率结果读者根本分不清哪根更粗反而增加了理解成本。箭头方向比粗细重要得多。箭头必须明确指向调用方向或数据流向不能有歧义。如果两个模块互相调用用两条单向箭头不要用一条双向箭头。双向箭头在视觉上容易让人困惑到底是同时双向还是交替双向线条的样式也可以承载信息。实线表示同步调用虚线表示异步消息点线表示可选依赖——这些约定如果在图例里说明能大大提升图的信息密度。4.4 留白让图呼吸新手画图往往把空间填得满满的觉得留白是浪费。但实际上留白是图表设计的重要工具。适当的留白能让图看起来更清晰模块之间的关系更明确。我的经验是模块之间的间距至少是模块内部文字高度的1.5倍。层与层之间的间距至少是层内模块间距的2倍。这样层次感自然就出来了。如果图太密宁可拆成两张也不要硬塞。一张拥挤的图读者看两眼就放弃了两张清爽的图读者愿意看完。5. 工具选型不同场景用什么画5.1 快速草图纸笔或白板工具如果是头脑风暴阶段我强烈建议先用纸笔或白板工具画草图。这个阶段不需要考虑美观只需要把想法快速可视化。纸笔的好处是零门槛、零延迟想到什么画什么。白板工具如各类在线白板的好处是可以多人协作适合团队讨论。这个阶段画出来的图大概率不会出现在最终文档里但它是后续所有工作的基础。我见过有人跳过草图阶段直接打开专业工具开始画结果画到一半发现思路不对全部推翻重来。先用草图验证思路成本最低。5.2 正式文档结构化绘图工具如果是写进技术文档、需要长期维护的图我会用结构化绘图工具。这类工具的特点是图形元素有语义比如数据库和服务是不同的形状支持自动布局修改方便。结构化工具的好处是当你增删模块时布局会自动调整不需要手动拖拽。而且导出的图风格统一适合放进文档。缺点是学习成本比自由绘图工具高一些但一旦掌握效率提升明显。5.3 演示汇报自由绘图工具如果是给领导汇报或对外演讲我会用自由绘图工具。这类工具的特点是想怎么画就怎么画不受模板限制视觉效果可以做得更精致。自由绘图工具的缺点是修改起来麻烦而且容易画得太花。所以用这类工具时我会更严格地遵守前面说的配色和层级原则避免过度设计。5.4 代码生成适合频繁变更的图如果图的内容会频繁变更比如系统架构经常调整我会考虑用代码生成图。这类工具用文本描述图形改起来方便而且可以纳入版本管理。代码生成图的缺点是布局控制不如手动灵活复杂图可能需要反复调整代码才能达到理想效果。但对于结构清晰、变更频繁的图这个投入是值得的。场景推荐工具类型核心优势注意事项头脑风暴纸笔/白板零门槛、快速不追求美观技术文档结构化绘图语义清晰、易维护学习成本略高演示汇报自由绘图视觉精致、灵活避免过度设计频繁变更代码生成版本管理、易修改布局控制较弱6. 实操中踩过的坑与应对经验6.1 图太大拆图比缩放更有效我做过一张全系统架构图试图把所有模块都放进去。结果图大到需要A3纸才能打印投屏时字小得看不清。后来我把它拆成了四张图整体分层图、核心业务流程图、数据存储图、部署拓扑图。每张图只讲一个方面组合起来反而更完整。拆图的原则是按问题拆不按模块拆。比如订单系统和库存系统是两个模块但如果它们之间的交互是重点那应该有一张图专门讲下单时的库存扣减流程而不是把两个模块各画一张图。6.2 箭头混乱减少交叉的布局技巧箭头交叉是图表设计里最头疼的问题。我的应对技巧有几个第一调整模块顺序。如果A调用C、B调用D那按A-B-C-D排列箭头就不会交叉如果按A-C-B-D排列箭头就会交叉。所以画图前先理清调用关系按关系排列模块。第二分层布局。把调用关系多的模块放在同一层减少跨层箭头。比如三个服务互相调用就放在同一层横向排列不要一个放上层一个放下层。第三用颜色区分。如果实在无法避免交叉用不同颜色的箭头区分不同的调用链读者可以顺着颜色追踪。6.3 图例缺失读者不是你我早期画图经常忘记加图例觉得这么明显还需要解释吗。但读者不是你他不知道你的约定。比如你用虚线表示异步读者可能以为是可选你用蓝色表示数据库读者可能以为是外部系统。所以每张图都应该有图例哪怕只有两三个元素。图例不需要复杂简单说明形状、颜色、线条样式的含义即可。这个习惯能省掉很多沟通成本。6.4 版本混乱命名和归档要规范图表和代码一样会有多个版本。如果没有规范的命名和归档很快就会乱套。我的做法是文件名包含日期和版本号比如系统架构图-v2.1-20240115。同时在文档里引用图时注明版本避免读者看到旧版本。如果图是代码生成的那就更简单了直接纳入版本管理每次变更都有记录。7. 图表设计的进阶思路从能看懂到好记忆7.1 用视觉隐喻降低理解成本好的图表设计能让读者秒懂。做到这一点的关键是用视觉隐喻。比如把网关画成一道门把消息队列画成一个管道把缓存画成一个抽屉。这些隐喻不需要文字解释读者一看就明白。当然隐喻不能滥用。如果每个模块都画成具象图形图会变得很花反而分散注意力。我的做法是核心模块可以用隐喻辅助模块保持抽象。比如网关用门的形状但数据库还是用标准圆柱体。7.2 用分组和边框建立视觉容器当图里有多个相关模块时用分组边框把它们框起来能大大提升可读性。比如三个服务都属于订单域就用一个虚线框把它们框在一起标注订单域。这样读者一眼就能看出这三个服务是一组的。分组边框的样式也有讲究。我通常用浅色虚线避免边框太抢眼。分组名称放在边框的左上角或顶部居中字号比模块名称小一档。7.3 用注释补充图外信息图能表达的信息是有限的。有些背景、约束、假设无法用图形表达但读者需要知道。这时候就用注释。注释的位置通常在图的空白处用引线指向相关模块。注释文字要简短一句话说清楚。如果注释太长说明这个信息可能更适合放在正文里而不是图上。7.4 用一致性建立系列感如果一组图是同一个系统的不同视角它们应该有一致的视觉风格相同的配色、相同的字体、相同的图例约定。这样读者在看第二张图时不需要重新学习视觉语言理解成本大大降低。一致性还体现在命名上。比如第一张图叫整体架构图第二张叫订单流程时序图第三张叫数据存储架构图——命名风格统一读者一看就知道这是一套图。8. 我个人的几条硬核经验最后分享几条我这些年画图总结出来的硬核经验都是踩过坑之后才明白的。第一条先写文字再画图。如果你不能用一段文字把要画的内容说清楚那图也画不清楚。我现在的习惯是先用文字列出图的要点确认逻辑通顺了再动手画。第二条找个人讲一遍。图画出初稿后找一个不了解这个系统的同事让他看图说一遍他理解的内容。如果他说错了说明图有问题。这个方法比自我检查有效得多。第三条图是给人看的不是给机器看的。不要追求完整要追求清晰。一张图漏掉一些细节没关系只要核心信息传达到了就是好图。反过来信息再全读者看不懂也是废图。第四条定期回顾旧图。系统在演进图也要更新。我每季度会花半天时间把核心架构图过一遍看看有没有过时的地方。这个习惯能避免图与系统不符的尴尬。第五条不要迷信工具。工具只是工具思路才是核心。我见过用最基础工具画出极清晰架构图的人也见过用最贵工具画出垃圾的人。把精力花在信息梳理和层级设计上比花在工具学习上回报高得多。图表设计这件事说到底是一种信息表达能力。它和写文档、做汇报一样核心都是把复杂的事情讲简单。这个能力没有捷径就是多画、多看、多改。画得多了自然就有感觉了。