1. 先搞清楚图给谁看需求分层与阅读场景分析我最早画架构图的时候吃过一次大亏。当时花了两周时间把整个系统的调用关系、模块依赖、部署拓扑、数据流向全画进一张图里自认为精细无比。结果评审会上业务同事盯着密密麻麻的连线看了三分钟问了一句所以这朵云到底是你们的产品还是别人家的东西 那一刻我才意识到图不是信息越多越好而是读图的人需要的那个信息越突出越好。做 diagram-design 的第一步从来不是打开绘图工具而是回答三个问题这张图是给谁看的他拿这张图要做什么他会在什么状态下看图 这三个问题决定了图的粒度、组织方式甚至配色方案。1.1 汇报型图与协作型图的本质差异按阅读场景图可以粗暴分成两类。汇报型图的目标是建立认知。比如给非技术背景的决策者看系统蓝图给新入职的同事看业务骨架给跨部门伙伴看数据流向。这类图的读者大概率只看一次不会拿着放大镜逐格检查。所以汇报型图要大胆减负只保留一条主叙事线细节全部折叠成一个占位符。协作型图的目标是指导执行。比如研发团队要用架构图定位新的微服务应该接在哪一层运维要用拓扑图确认故障时该从哪个节点开始排查。这类图的读者会反复查阅、对照、标注所以信息和位置必须准确到可以当参照系使用。协作型图可以复杂但复杂必须有结构不能让所有元素处于同一视觉优先级。我见过很多团队用同一张图既做汇报又做协作结果两边都不满意。业务说看不懂开发说画太粗。正确做法是一张主图配多张子图主图负责总览子图承载细节。这个一图多级的思路在第四节会详细展开。1.2 从提问方式反推图的信息组织方式判断一张图好不好我习惯用一个实操办法拿图给目标读者看十秒然后让他回答几个问题。如果我画的是架构图就问核心数据存在哪个服务如果是流程图就问异常分支从哪一步开始触发回退。回答得越快越准说明图的信息组织越好。这个测试本质上是反推的过程。图里的信息组织顺序应该跟随读者最常问的问题来编排而不是跟随系统的物理结构来编排。比如系统按用户端、服务端、数据端划分是物理结构但如果读者最关心的是订单从下单到出库经过哪些环节那么流程视角就比模块视角更合适。一个具体做法是开工前先在草稿纸上写下目标读者的五个典型问题然后让每一根连线、每一个节点都对应其中至少一个问题的回答。答不出任何问题的装饰性元素直接删掉。1.3 信息密度的三层结构总览层、细节层、附录层成熟的信息架构会把内容放在三个层次。总览层是图的封面只放最高层级的组件和关系一般不超过7个主节点。人脑的工作记忆大约能同时处理7个左右的单元超过这个数字认知负担会急剧上升。所以总览层的节点数量是一个硬约束。细节层是总览层的展开每一块区域都可以单独拎出来变成一张子图。子图内部遵守同样的规则节点过多就继续往下拆直到每个节点都能被一句普通业务能理解的话说清楚为止。附录层是数据字典把图上的缩写、编号、颜色含义列成对照表。不要指望读者靠猜理解你的标记也不要让读图的人来回翻上下文。把图当代码来维护总览层类似模块入口细节层类似函数实现附录层类似注释文档。2. 图形选型别凭感觉各类图式的适用边界与选择逻辑画图工具里的模板五花八门流程图、时序图、状态图、架构图、拓扑图、思维导图、鱼骨图……但大部分人对图式的选择是哪个模板看着顺眼选哪个或者上一个人用什么我继续用什么。图式选错信息再准也白搭。图式的本质是约束读者的阅读方式流程图引导你按时间顺序读拓扑图引导你按空间关系读树状图引导你按层级归属读。选型就是选读者最舒服的阅读模式。2.1 流程类图流程图、时序图、活动图的取舍先说一个最常见的错误把业务流程图画成箭头大杂烩。每个节点伸出三四个箭头旁路分支比主路径还粗最后主流程反而找不着了。数据流类图的核心是谁在什么时候做了什么顺序和分支是主角。适合用泳道图把不同角色或系统分成横向泳道节点落在各自泳道里一眼就能看出职责边界和交接顺序。如果多个系统之间有时间上的先后依赖时序图更合适它的纵轴天然表达时间横轴表达参与者对研发群体尤其友好。活动图则适合表达复杂的并行和同步逻辑。比如一个订单处理流程同时触发库存锁定、优惠券核销、物流预估三个并行任务活动图里的分叉和汇合标记就能清楚地表达哪些事情可以同时做哪些必须等待所有并行任务完成。选择逻辑其实很简单主要看点是谁做了什么选泳道图主要看点是系统间消息的先后顺序选时序图主要看点是谁跟谁能并发、谁等待谁选活动图。2.2 结构类图架构图与拓扑图不能混为一谈这是很多人踩坑的重灾区。架构图回答的是系统由什么组成它们之间怎么协作强调的是逻辑分层和依赖关系。画架构图时图上的方块是逻辑模块连线是调用关系或数据流。物理上跑在哪台机器上并不重要所以数据库和服务可以画在一个水平层次的泳道内哪怕它们部署环境不同。拓扑图回答的是系统部署在哪里网络怎么到达强调的是物理节点和链路状态。画拓扑图时每个节点都对应一个真实的机器或设备连线对应实际的网络链路或通讯路径。我在评审时见过一张图把数据库、缓存、负载均衡、业务服务全画成一个个虚拟的云实例同时又在上面标注了内部调用和公网访问。这张图既不是架构图——因为没有表达分层和依赖也不是拓扑图——因为没有表达真实节点关系。受众想排查网络故障时找不到链路想理解模块耦合时又找不到逻辑边界。正确做法是同一套系统拆成两张图架构图给开发团队梳理代码模块拓扑图给运维团队排查网络链路。不要让一张图同时承担两种语义。2.3 关系类图思维导图、ER图、力导向图的定位思维导图适合从中心主题向外发散的初步梳理因为它不需要表达关系的性质只需要表达这些事物同属于一个主题。用思维导图做头脑风暴和需求收集很顺手但不要拿它当正式设计文档因为它不表达方向、强度、依赖。实体关系图ER图适合表达数据模型实体、属性、主外键关系非常固化研发和数据库设计人员看到它就知道怎么建表。但如果读者是业务人员ER图的信息密度会明显过高建议优先给业务人员画数据流图把ER图作为技术附录。力导向图适合表达非规则的多对多关系比如用户标签重叠、社交网络关系、服务依赖的网状调用。它的优点是直观表现聚簇和中心节点缺点是节点一多就变成毛线球。使用力导向图的前提是节点数量可控并且必须提供交互能力比如悬停高亮、点击过滤静态图片形式基本不适合承载这种图。选型的底层逻辑归根到底是一句话你想强调的信息恰好是这种图式用默认方式最容易突出的信息。 选错了读者就会一直被图式自带的暗示引向错误的方向。3. 从草稿到成图布局、连线与视觉层级的实操方法确认了图式和信息层级接下来才是真正的画图环节。很多人一上来就摆矩形框调颜色半天过去图成了配色欣赏信息结构还是一团浆糊。我自己的流程是先出灰度架构再上视觉。3.1 布局顺序先骨架后分支最后才是装饰任何一张图都有主路径。可能是架构图里的核心调用链也可能是流程图里的主业务流。我习惯先把主路径上的节点用最简单的方框和直线摆出来全部左对齐或居中对齐间距均匀。这个时候只看顺序对不对完全不考虑美观。主路径稳定之后再挂分支节点。分支节点尽量往主路径的同一侧放比如所有异常分支统一放在主路径下方所有辅助模块统一放在主路径上方。这样读者的视线始终被引导在主路径上需要看旁支时才向两侧延伸。最后一步才是布线。很多工具会默认用直角线但直角线拐弯太多的时候容易跟其他线交叉。我的习惯是跨层连接用曲线同层连接用直角线。曲线让长距离跳转不显得生硬直角线让短距离关系保持清晰。连线数量超过10根时尽量避免每一根线都画箭头可以在说明里加一条默认箭头指向数据流向只在关键反向或异常路径上画显眼箭头。3.2 网格对齐、留白与最小间距的三条底线这是我从平面设计里借鉴来的三条硬规则直接决定图的专业感。第一条所有节点必须对齐到网格对齐。绘图工具里开启网格吸附相等层级的节点保持相同的宽度和高度这会让图产生一种系统很稳定的视觉暗示。第二条相邻节点之间至少保留一个节点宽度20%的留白留白不足会让读者无意识觉得这些模块好像粘在一起。第三条连线之间、连线与节点之间的间距不小于5像素在缩放到100%时否则打印出来就是一坨黑线。间距之外还有一个经常被忽略的细节图层顺序。把连接线统一放在节点下层不要让线从节点上面跨过去。节点边缘附近不要有平行于节点边框的走线容易产生这条线连的是这个节点的错觉实际上它只是路过。3.3 颜色、线型、字体的信息层级规范颜色是很多图翻车的最大源头。五颜六色的图看着热闹但读图的人根本不知道该把注意力放在哪里。我的做法是整张图只保留一种强调色其他色相全部压到灰色系。具体来说信息层级用三层配色法背景和网格用极浅灰主要节点用白色或浅灰填充强调路径和当前焦点用唯一的强调色。如果必须表达多个并列的类别比如三个子系统的边界用同色系的不同明度弱化对比比如深灰、中灰、浅灰而不是红黄蓝三原色。线型的语义也要统一实线代表确定的关系虚线代表可选或间接的关系点线则尽量少用因为打印出来容易看不清。再加粗或加箭头只用于标注读者最需要关注的路径。字体方面图上少用纯文字多用名词短语。节点标题限制在6个字以内超过就拆成节点名附加说明两个元素。全图最多使用两种字号大号字标节点标题小号字标辅助注释。字号层级多了读者就会把注意力花在读文字上而不是理解关系上。4. 复杂信息怎么塞进一张图而不爆炸分层、聚合、锚点系统复杂是常态但图是用来降低复杂度的不是用来展览复杂度的。真正需要画大图的时候我会用三个策略控制爆炸感分层、聚合、锚点跳转。4.1 按读者注意力做分层而不是按系统模块做分区很多人在图上画一个大虚线框写支付域再画一个虚线框写用户域然后各自塞一堆服务。这种做法叫按模块分区它的问题在于模块内部的服务和模块之间的交互往往同样复杂虚线圈只是增加了一个归类层级并没有降低阅读负担。我倾向于按阅读顺序分层。把图从上到下分成入口层—业务层—能力层—数据层或者从左到右分成用户侧—服务侧—管理侧。每个横向带里的节点数量控制在最少节点在哪个带里就决定了读者在阅读路径上什么时候会遇到它。这样做的逻辑是复杂系统里读者也是按时间顺序认知的先看到请求入口再一步步深入到数据存储。按模块分区会让读者在各区域之间反复横跳而按阅读顺序分层则顺着人的自然认知推进。分层之后如果某个横向带里的节点仍然超过10个就在这一带里再细分出几个子区域并在区域标题上注明详见第X张子图。4.2 聚合与合并把多个节点抽象成单一语义单元聚合是降低复杂度的核心操作。三个服务如果总是同时出现、一起被调用、一起被部署那在总览图里它们就是一个节点。比如一个短信服务、邮件服务、站内信服务只要能统一对外提供通知能力总览图里就聚合为一个通知中心展开子图里再画具体实现细节。聚合节点要在视觉上给出提示可以在节点右下角加一个小折角图标注明可展开并在节点下方标注聚合数量比如3个服务。这样读者既不会误以为它只有一个实现也不会好奇里面到底有什么而失去焦点。合并同类项也是同样的逻辑。多个并列的功能模块用同一种图形样式统一命名格式比如所有查询服务都以统一的查询图标和同色边框呈现。读者不需要看内容光看样式就知道这是查询这一类功能。4.3 锚点跳转编号、索引与子图的联动设计大图不可能一张图承载所有细节子图不可避免。子图和总览图之间的联动靠的就是锚点系统规则很简单每个可展开的聚合节点或区域在右下角标记一个编号如 A1、B2。对应编号的子图名统一写成总览图编号子图主题比如A1-通知中心内部结构。子图左上角必须放一个返回总览图索引的跳转说明方便读者在纸张或PDF上快速定位。这个做法本质上是给图建立目录结构。没有锚点的多图是一堆分散的碎纸片有锚点的多图才是一个成体系的知识包。在文档里插多张图时记得每张图都保有独立的标题并在总览图下附一个编号索引表列清楚每个编号对应的子图标题和页码。5. 成图之后的十分钟自检与常见的五种图病画完不等于做完。我见过太多图在屏幕上显得完美打印出来细看却发现线压字、颜色对比度不足、边缘被截断。所以我每次定稿前都会强制自己走一遍十分钟自检流程已经固定成了肌肉记忆。5.1 十分钟自检清单缩放、打印、盲测先检查缩放。把图缩小到50%看整体结构再放大到150%看局部细节。50%时应该能看出大致的区域划分和主路径走向如果一团乱麻说明布局的层级还不够清晰。150%时每个节点的文字都不应被截断连线不应跟文字重叠。再检查打印。很多工具里的屏幕显示和打印输出有差异导出PDF后务必实际打印一张A4或A3看看效果。重点看灰度打印的颜色区分度如果两个类别在灰度下完全不可分辨就调整明度而不是依赖色相。最后是盲测。找一位没参与设计的同事只给图不解释请他描述一下这张图讲的是什么你觉得下一步该看哪儿。如果他的描述和你的设计意图偏离太大不要急着补解释请回到图上调整布局和信息层级。一张需要口头解释才能看懂的图本质上还没设计完。5.2 五种最常见的图病和对应的处方这五种图病我在评审里见了无数次写在这里当检查参照。第一种叫箭头恐惧症症状是图上箭头密密麻麻方向五花八门。处方非关键路径的连线全部改为极浅灰色细线关键路径用强调色加粗必要时可以省略部分反向线的箭头用文字标注方向即可。第二种叫方块展览会症状是大量同尺寸、同颜色的矩形排成一排没有任何视觉重心。处方给主要节点增加一个衬底色块或外发光让第一眼落在核心节点上而不是平均分配注意力。第三种叫文字迷宫症状是节点里塞了长段落图上文字密度堪比说明书。处方节点内只保留名词短语详细说明挪到图下方的注释区用编号一一对应图上无长句。第四种叫留白恐惧症症状是整张图把画布铺得满满的四边没有余地。处方强制给画布四周留出至少10%的空白区域并把最重要的说明文字放在右下角阅读视线最后一站而不是塞在最拥挤的中央。第五种叫版本混乱症状是一张图在邮件、文档、PPT里各有一份不同步的版本。处方给主图文件名加入日期和版本号内部用V2.3-20250315之类的格式标注子图引用锚点时把版本号同步列出。5.3 图是活文档迭代规则与变更记录最后补充一点经验图跟代码一样需要迭代维护。需求一变图就得跟着改否则图会从资产变成负债——一个过时的架构图比没有图更危险因为它会误导决策。我在项目里积累了一套简单规则每次变更时先把变更点标红而不是直接改新版本。标红的图发出去让大家在旧图上看到哪里变了等变更评审通过后再合并成新版本并更新版本号和修订说明。这样的好处是读图的人不必逐字对比新旧两张图省时省力。我自己还会在每张正式图的下方保存一行修订记录表格式是日期/修改人/变更内容摘要。这行表很小但回看三个月前的版本时能直接回答当时为什么这样设计的问题。别小看这个细节它能避免团队为了同一个改动反复争论。最后分享一个我常用的收尾技巧画的图多了以后你会发现真正重要的不是鼠标技巧而是克制。每次想往图里再塞一个信息的时候先问自己如果没有它读者能不能得出正确结论绝大多数情况下答案是能那就果断不塞。我在实际项目里还有一个小习惯成图之后把总览图设置成团队电脑桌面壁纸一周。一周里所有人都会反复瞄到这张图任何结构别扭、层级混乱的地方都会在无意间被感知到然后在周会上收到反馈。这个土办法看似随意但比任何评审机制都更能让一张图真正活进团队日常协作里。下次你头疼一张图怎么设计的时候不妨也试试先把草图画出来贴到所有人天天能看到的位置让真实的使用反馈告诉你怎么改。