刚开始接触技术架构梳理的时候，我也以为画图就是把几个方框连几条线。后来在一次内部方案评审上，我花了一晚上整理的系统结构图，被一位同事指着中间那条交叉线问：“这条虚线到底表示调用，还是表示数据回流？”那一刻我才意识到，diagram-design 不是排版问题，而是信息如何在二维平面上被正确解码的问题。也是从那次之后，我开始把“图”当作产品来打磨，而不是当成文档的附属品。
这篇文章想聊的就是 diagram-design 这件事：从图形语言的基本规则，到一次完整的设计实操，再到我踩过的一些坑。不管你是画架构图、流程图、ER 图，还是给业务方画一张时序图，里面讲的思路和细节基本都通用。
1. 图解的本质：你画的不是图形，是沟通合约
很多人把图画出来，只是为了“有一张图”，但图真正的价值是压缩信息密度。一页 PPT 里塞不下五万字的需求文档，却能塞下一张系统架构图。而这张图能不能在三秒钟内被人读懂，完全取决于你在落笔之前有没有想清楚“这张图到底在沟通什么”。
1.1 为什么我们需要认真设计一张“图”
人脑处理视觉信息的速度远快于处理文字。一张清晰的图能在几秒内把一组的关系和流向交代清楚，这是任何列表和文档都比不上的。但这也恰恰是问题所在：既然图的信息传递效率这么高，那么出了错，误导的效率也特别高。
我在项目里见过太多反例：有人把六个系统画在同一水平线上，然后用箭头串起来，告诉别人这是“微服务调用关系”。可当被问到“是同步还是异步”“有没有缓存”“失败怎么处理”时，他说“我也没细想”。这说明那张图不是沟通工具，而是一张“看上去很高级”的装饰画。
真正值得投入心思的 diagram-design，是把隐性的逻辑显性化。你在画每条线之前，都需要问自己：这条线代表依赖，还是代表数据流，还是代表部署关系？如果代表依赖，那方向的箭头应该指向被依赖方；如果代表数据流，那么箭头传递的应该是数据包的移动。这个语义一旦混乱，整张图就废了。
所以我说，图是沟通合约。你和读者之间约定：方框代表什么、箭头代表什么、虚线代表什么、颜色代表什么。只有在这种约定清晰的前提下，读者才能从图中读出你脑子里的结构，而不是靠猜。
1.2 优秀图解的五条铁律
这些年我陆陆续续整理出几条基本原则，谈不上原创，都是实践中被反复验证的经验。
第一，单一图只表达单一主题。一张图又想表达系统部署拓扑，又想表达调用链路的超时时间，又想表达数据存储的冷热分层，结果就是哪个都没说清。如果你发现一张图里塞了太多件事，就拆图。
第二，方向感是默认契约。在没有明确标注的情况下，读者默认流程图是从上到下、从左到右。你随意把整个链路反过来排，又不给任何视觉提示，会让读者不断停下来重新建立方向感。
第三，分组要显性。不管是微服务按业务域分组，还是流程按阶段分组，都需要用边界框、背景色或者间距表现出来。视觉上的相近性会自动形成分组感，如果你把毫不相干的节点排在一起，读者就会认为它们有关联。
第四，元素数量要克制。一屏能看懂的节点数，我个人建议不超过九个。超过九个，注意力就开始分散。如果必须呈现二十个节点，那就分层：先呈现核心链路，再用展开的方式呈现细节。
第五，颜色不是装饰，是编码。颜色要么用于标记状态（正常、异常、待处理），要么用于标记类型（存储、计算、消息队列）。当你发现颜色用得太随意，读者只会觉得花哨，而读不出任何信息。
2. 核心组成部件的设计逻辑
一张图无论多复杂，拆开来看就是几类元素：节点、连线、标注、布局和样式层级。每一类都有一套设计逻辑，下面分开说。
2.1 节点：让你的块面会说话
节点是图上的“名词”。它代表一个系统、一个步骤、一个对象或一种状态。节点的视觉设计决定了读者如何快速分类信息。
首先是形状。矩形通常用于处理流程中的步骤，圆形或圆角矩形用于表示状态的起止，菱形用于判断分支，圆柱体用于存储。这条规则不是强制标准，但当读者看到菱形时，他下意识就会寻找“是/否”两个出口。如果你拿菱形画一个普通操作，读者会困惑。所以我建议在团队约定一致的图形语义，然后把约定写进标准里。
其次是尺寸和间距。同一个层级里的节点，尺寸必须一致。我在实际绘制中经常见到“重要的就画大一点”的任性做法，这会给读者错误的权重暗示。节点之间至少保留一个节点宽度的间距，否则画面会显得拥挤，线也拉不开。
还有一个被很多人忽略的细节：节点内的文字。文字离边框太近，显得局促；文字太多，同样会挤压图形。一般我建议文字和边框保留至少 8 到 12 像素的 padding（如果是画在屏幕上的话）。文字要尽量精简，优先使用名词短语，而不是长句。比如“用户身份认证模块”可以简写成“认证”，如果担心语义不清，再加一个注释，而不是把整段话塞进框里。
再补充一点关于分组边界。当你要表达“这几个节点属于同一个子系统”时，可以使用一个大圆角矩形把一组节点包起来，并在左上角标注组名。这种容器元素能有效减少节点之间的连线。比如三个服务共享同一个数据库，你便不需要把数据库分别连到三个服务上，而是把三个服务放同一个边界框里，在框外放置数据库节点，再用一条线连接边界框和数据库即可。
2.2 连线：方向、形状和层级关系
连线是图的“动词”，它描述节点之间的关系。连线设计最核心的不是“线画不画得直”，而是“语义是否清晰”。
箭头方向是第一个大坑。很多人在画依赖图的时候，习惯用箭头指向被调用的服务，例如 A 调用 B，于是画 A → B。这个方向没问题。但如果画的是继承关系，箭头应该指向父级；画的是数据流，箭头应该指向数据的流向；画的是消息订阅，箭头可以表示消息的发布与通知。需要特别注意的是，在混合了多种关系的复合图中，一条线的方向可能同时承担两种含义，这时候一定要在图例里写清楚。
虚线、粗线、双线、斜线，它们各自可以承担额外语义。常用的协议是：实线表示同步调用，虚线表示异步或事件通知，粗线表示核心链路，细线表示非关键路径。颜色也可以叠加在线上，比如红色线表示错误或告警路径。但切记不可同时堆叠太多编码维度，否则读者计算负荷会爆炸。
这里分享一个我自己会用的连线原则：线尽量走正交直线，清楚短小。一条线如果需要在图上绕一个大弯才能连接两个节点，通常意味着布局有问题，而不是这条线就该这么画。你需要重新调整节点的位置或使用分组容器，让连接变得自然。另外，交叉线要尽量避免，如果实在无法避免，可以让一条线从另一条线下方绕过，或者使用“桥接线”的视觉标记，不过最好的解法还是布局重排。
2.3 标注与排版：少即是多的信息压缩
标注承担的是“注释”功能，但很多图恰恰是被注释毁掉的。每个节点旁边飘着一大段解释文字，最后图成了一篇带边框的文档。
正确的做法是，把“图中需要读者了解但不能成为主体信息”的内容放进标注。比如某个服务的 QPS 峰值、某个流程的平均耗时、某条链路的超时阈值。这类定量信息放在节点或者连线旁，能有效提供约束感。但要注意，同一张图里不要混入三种以上的重要指标，否则读者根本分不清哪个是重点。
排版层面，对齐是最廉价但最有效的优化手段。节点与节点之间左对齐、右对齐、中心对齐，任何一条边都不要出现肉眼可见的偏差。我见过很多图采用“自由拖拽布局”，结果每个方块都微妙地错开，细节处特别难受。真正高质量的图，哪怕节点很多，整体结构也一定是对齐的。这种对齐不是靠感觉，而是靠网格吸附和分布工具去实现。
留白也是一部分信息。节点周围留出空白，视觉上才显得透气。拥挤不堪的图会让读者产生慌乱感，进而造成误读。我给自己定的标准是：每两个节点之间至少空出能容纳一个箭头符号长度的距离，这样线不会贴在一起，箭头也清晰可辨。
3. 一次完整的图表设计实操
光讲概念容易飘，我以一次实际的系统流程图设计为例，带大家走一遍完整过程。这张图要表达的核心诉求是：订单从创建到支付完成的异步处理链路，以及异常情况下的退款回退流程。目标读者是后端开发同事和运维同事。
3.1 从口述到结构化：先列信息清单
画图之前我先不打开任何工具，而是在文档里列出两条清单：一条是“这张图必须体现的实体”，另一条是“实体之间的关系”。
实体列表大概是这样的：
- 客户端
- 订单服务
- 支付网关
- 消息队列
- 订单状态机
- 退款服务
- 数据库
- 超时定时器
关系列表：
- 客户端调用订单服务创建订单
- 订单服务写入数据库并发送支付确认事件到消息队列
- 消息队列触发支付网关进行扣款
- 支付网关回调订单服务更新状态
- 如果超时未支付，超时定时器启动订单关闭
- 用户主动取消或退款时，退款服务介入并回写状态
这一步不画图，但却是最重要的一步。只有把实体和关系都列出来，你才知道这张图需要多少个节点、多少条线。很多人画到一半发现节点多了，就是因为没做信息清单。
3.2 草图过程：灰度优先，线条先行
拿着清单，我开始画草图。草图阶段我会刻意屏蔽颜色，只用黑色和灰色。为什么？
因为颜色会骗人。太早使用颜色，你会把注意力放在“好看”上，而忽略结构本身是否正确。而我只需要让每个节点的位置落在合理的布局网格上。先把订单服务放在图的中心，因为它是核心；客户端放左边，支付和超时相关放右边，数据库放下方，消息队列放在订单服务和支付之间。
连线的过程我会反复看是否交叉。如果交叉了，我并不急着加桥接线，而是调整节点位置。比如消息队列一开始放在订单服务上方，导致它连到支付网关时和另一条线交叉，后来把消息队列挪到订单服务右侧，交叉消失了，图也顿时清爽。
草图画完后，我会暂停十分钟，只做一件事：盯着图看，不解释，看自己能否在十秒内讲清楚“谁 → 谁 → 谁”。如果十秒内讲不清，说明图纸结构还不够直接。然后我重新调整一个分组：把订单服务、订单状态机、数据库放到同一容器，标记为“订单域”；把支付网关、消息队列标记为“支付域”。这样读者看到的第一层是两个域的交互，而不是一堆节点之间的乱线。
3.3 工具选型与复现步骤
关于工具，我现在一般会根据场景从三类里选：在线白板类（适合快速协作、自由拖拽）、桌面图形编辑器（适合专业输出、精确布局）、代码生成图表类（适合版本管理、随代码仓库走）。每一类都有各自的优势，比如：
- 在线白板类：页面无限大，多人协作方便，但默认网格不太严格，需要自己开启对齐吸附。
- 桌面图形编辑器：精确控制和导出，但协作体验稍弱，需要共享源文件。
- 代码生成图表类：用文本描述节点和连线，图的源文件是一个文本，方便走 Git 合并请求评审，可以把“图”纳入代码审查流程。
我个人最近经常用第三种方式，因为它能有效解决图表版本管理的问题。当你用文本描述图的时候，每一次变动都能被 diff 出来，比如增加了一个节点，改动了几条线，非常清楚。缺点是学习曲线稍微陡峭一点，但一旦熟悉了，画图效率会很高。
无论用哪种工具，复现步骤都类似：
- 新建画布，设置好页面大小和网格，建议网格间距取偶数，比如 8 或 10 像素。
- 先画容器分组，再在分组内放节点。
- 所有节点先使用默认样式，全部摆放完后再统一调整大小和对齐。
- 连线时先画主干链路，再画分支链路，避免出现交叉。
- 最后添加箭头的语义化：同步调用、异步通知、回退等情况分别用实线、虚线和颜色区分。
- 导出前再做一次“极简检查”：去掉所有装饰性元素，看剩下的结构是否依然清晰。
我用这个流程画过一张包含几十个节点的架构图，最终交付时只保留了少数几种样式，但每个读者都能在三十秒内说出它的核心链路。这就是 diagram-design 的目的。
4. 常见问题与排查技巧实录
画图踩坑几乎不可避免，下面整理的这些问题都是我亲身撞过的，也总结了一套排查路径。
4.1 拥挤混乱：布局密度是头号杀手
最常见的低质量图都死于拥挤。节点太多、间距太近、线上还挂着文字，整个画面像蜘蛛网。读者第一眼就丧失信心，更谈不上理解。
遇到这种情况，我的第一步永远是“拆图”，而不是“缩小字体”。拆图的意思是把一张大图按边界拆成多张小图，然后在每张小图之间用“索引”连接起来。比如最上层的架构图只放系统名和域名边界，第二层才展开某个域内部的组件关系。
- 操作建议：强制自己把每张图限制在 9 个节点以内，如果超出，就寻找分组或抽象层级。
- 小技巧：把画布尺寸缩小后再看一遍，模拟远处阅读的感受。如果缩小后看不清，说明信息密度过高；如果缩小后还是一团乱糟糟，说明布局根本没有逻辑层级。
4.2 箭头语义混乱：一张图多种读法
箭头的含义没有全局统一，是比拥挤更隐蔽的问题。比如我在一张图里用实线箭头表示主调用，又在另一个地方用同样的箭头表示数据返回，而两者混在同一张图里，读者会无所适从。
排查方法也很简单：对每一条线问三个问题。
- 它连接的两个节点是什么关系？
- 箭头方向是否指向信息的流向？
- 这条线和图上其他线的线型是否有语义冲突？
如果发现一个样式承担了两种以上含义，我需要马上新增一种样式，或者拆图。特别是当我在线评审时，我会直接把图投屏，逐条线指着问：“这条线的含义，你能读出来吗？”听的人如果回答含糊，说明图上存在模糊歧义。
还有一个容易犯的错：线太多但都没有标签。当连线承载了具体的信息时，比如“支付结果回调”，我会直接在线上写简短的标签，而不是让读者去翻代码文档。同样的，标签字体要小于节点文字，且不要遮挡任何一条线。
4.3 颜色过载：图表变画报
颜色过载是我早期特别爱犯的毛病。想用蓝色代表服务、绿色代表数据库、橙色代表外部系统、紫色代表中间件、灰色代表辅助工具……结果一张图像彩虹，读者的眼睛不知道该停在哪里。
后来我给自己定了颜色纪律：
- 最多使用三种主色，外加一种中性色用于背景和边框。
- 主色只用于强调分类，不用于装饰。
- 同一类元素在所有图中保持一致颜色。
- 用灰度线稿先定义形状和布局，最后才上色。
如果一张图上已经超过五种颜色，我基本可以断定它的分类体系是混乱的。我会重新问：这些颜色到底在标记什么信息？如果没有明确信息，那就删掉颜色，全部换成黑白。黑白图永远比配色混乱的彩色图专业。
4.4 图表变更维护：版本管理是隐藏成本
很多人画完图，过两个星期需求变了，就重新截图一次，覆盖保存。这样带来的问题是，你再也查不到旧方案是什么样，大家也没法围绕某一次改动进行讨论。
我的建议是把图当作代码一样管理。如果你用的是代码生成类的图表，直接把源文件放进版本控制仓库，提交记录里写清楚“更新支付超时流程，增加重试节点”。如果你用的是可视化工具，则至少要把源文件导出并保存在共享文档目录里，同时在文件的命名和元信息中记录更新时间、版本号和修改人。
我见过一个团队因为一两张关键架构图没有版本管理，在季度复盘时找不到最初的设计方案，最后只能靠记忆还原，白白浪费了好几个小时。这教训很深刻：diagram-design 不光是画图那一瞬间的事，维护和演进才是后续真正的重头戏。
最后再分享一个我个人的小习惯：每次给图做优化时，我会先在旧的图上用笔画出我要改的节点和连线，再动手编辑。因为当你直接在弹出的编辑面板里拖来拖去时，很容易迷失原来的整体结构。先用文本记录“下一步”，再操作，能让每一次改动都带着清晰意图。
好的 diagram-design 不会给自己加戏，它的目标是让读者忘记“图”本身，直接看到背后的系统逻辑。如果你也想让图纸变得更清晰，不妨从下次画图前多列一张“实体和关系清单”开始。那一个小动作，可能会省掉你后面一整天的解释成本。
