1. 从“diagram-design”这个标题说起：它到底在解决什么问题
第一次看到“diagram-design”这个标题，很多人会下意识觉得它是个画图工具，或者某个设计软件的插件。但如果你真正做过技术方案评审、系统架构梳理、或者给非技术同事讲清楚一个复杂流程，你就会明白：画图这件事，难点从来不在“画”，而在“设计”。一张好的图，能让五个人开半小时会就对齐认知；一张烂的图，能让同一个问题反复讨论三周还在原地打转。
“diagram-design”这个标题背后，指向的是一类非常具体的需求：如何用结构化的方法，把脑子里混乱的信息变成一张别人能看懂、能复用、能直接拿去汇报的图。它不是一个具体的软件名称，而是一套关于图表设计的方法论和实践集合。关键词虽然为空，但从标题本身可以拆出三个核心维度：信息分层、视觉编码、场景适配。这三个维度决定了你画出来的图是“自嗨型”还是“沟通型”。
这篇文章适合谁看？如果你是技术开发者，需要画架构图、流程图、时序图来对齐方案；如果你是产品经理，需要画业务流程图、状态机图来跟开发和设计沟通；如果你是咨询顾问或项目管理者，需要画组织图、路线图、矩阵图来汇报进展——那这篇内容就是为你准备的。我会从最底层的“为什么图会画废”开始讲，一直讲到具体场景下的参数设置和避坑技巧，中间会穿插大量我在实际项目中踩过的坑和总结出来的土办法。
先给一个反直觉的结论：大多数人画图慢、画图丑、画完没人看，根本原因不是审美不行，也不是工具不熟，而是动手之前没有做“信息分层”。你打开工具就开始拖方框、拉箭头，结果画到一半发现逻辑不对，删了重来；或者画完了别人问你“这个模块为什么在这里”，你自己都说不清楚。这就是典型的“用战术上的勤奋掩盖战略上的懒惰”。
2. 信息分层：为什么你的图总是“看起来乱”
2.1 一张图只能有一个“主角”
我见过太多人画图，恨不得把系统里所有模块、所有接口、所有数据流都塞进一张图里。结果就是：图比屏幕还大，字号小到要放大三倍才能看清，箭头交叉得像一团乱麻。这种图唯一的用途就是“证明我画过”，没有任何沟通价值。
正确的做法是：在动手之前，先问自己一个问题——这张图是给谁看的，他看完之后需要做什么决策？如果是给技术负责人看架构评审图，那主角就是“模块边界和依赖关系”，数据库表结构、字段类型这些细节统统不要出现；如果是给业务方看流程优化图，那主角就是“角色和动作的流转”，技术实现细节一个字都不要提。
我习惯在画图之前先写一句话：“这张图要说明的是______。”如果这句话超过20个字还说不清楚，说明你还没想明白，别急着打开工具。这句话就是你这张图的“主角”，所有元素都要围绕它来取舍。跟主角无关的，再重要也砍掉，或者放到另一张图里。
2.2 分层不是画三层框，而是分三次画
很多人理解的信息分层，就是在图上画三个横向的框，上面写“表现层”“逻辑层”“数据层”。这只是视觉上的分层，不是认知上的分层。真正的分层是分三次画图：
第一次，只画“实体”。把系统里所有关键角色、模块、外部系统列出来，用最简单的方框表示，不要连线，不要颜色，不要图标。这一步的目的是确认“有哪些东西”。
第二次，只画“关系”。在实体之间连线，标注关系类型（调用、依赖、数据流向、继承等）。这一步不要考虑布局好不好看，先把逻辑关系理清楚。我经常在这一步发现，原本以为两个模块是调用关系，仔细一想其实是事件通知关系，箭头方向完全反了。
第三次，才做“视觉编码”。给不同层级的实体分配不同的颜色、形状、大小，给不同关系分配不同的线型和箭头样式。这一步才是大多数人一上来就做的事，但如果没有前两步，你做的视觉编码就是无根之木。
提示：如果你用的是支持图层的工具（比如Figma、Draw.io、Excalidraw），把这三步分别放在三个图层里。第一步的图层叫“实体”，第二步叫“关系”，第三步叫“样式”。这样后期修改的时候，你可以单独隐藏某一层，快速检查逻辑是否有遗漏。
2.3 信息密度的“三秒法则”
一张图的信息密度是否合适，有一个很简单的检验方法：把图缩小到手机屏幕大小，三秒内能不能看出这张图在讲什么。如果三秒内只能看到一团模糊的色块和线条，说明信息密度太高了；如果三秒内只能看到两三个孤零零的方框，说明信息密度太低了。
我自己的经验值是：一张A4纸大小的图，核心实体不超过9个，核心关系不超过15条。超过这个数，要么拆图，要么做“总-分”结构——一张总览图加若干张细节图。总览图上每个实体只写名称，细节图里再展开具体内容。这样别人可以先看总览建立全局认知，再按需深入细节。
3. 视觉编码：颜色、形状、线条到底怎么选
3.1 颜色不是用来“好看”的，是用来“分类”的
新手画图最容易犯的错误，就是给每个模块分配一个不同的颜色，觉得这样“色彩丰富、好看”。结果就是彩虹图，看的人根本记不住哪个颜色代表什么。颜色的第一原则是：同一类事物用同一种颜色，不同类事物用不同色系。
具体怎么操作？我通常把颜色分成三个层级：
- 主色：用于最核心的实体，通常是你要强调的那个模块或角色。一张图里主色只能有一种，饱和度可以高一点，让人一眼就看到。
- 辅色：用于与主色直接交互的实体，可以用主色的邻近色，或者降低饱和度的同色系。辅色可以有2-3种，用来区分不同的功能组。
- 中性色：用于背景、边框、辅助说明文字。灰色系是 safest 的选择，不会抢视觉焦点。
如果你实在不知道怎么配色，记住一个万能公式：深蓝（主）+ 浅蓝/灰蓝（辅）+ 浅灰（背景）+ 橙色（强调）。深蓝给人稳重专业的感觉，浅灰不抢戏，橙色用来标出需要特别注意的地方（比如风险点、待确认项）。这个组合在投影仪、打印稿、手机屏幕上都不容易出错。
3.2 形状承载语义，不要随便用
方框、圆角矩形、圆形、菱形、圆柱体——这些形状在长期的使用中已经形成了约定俗成的语义。你当然可以打破这些约定，但前提是你有足够强的理由，并且要在图例里说清楚。
| 形状 | 常见语义 | 适用场景 |
|---|---|---|
| 直角矩形 | 模块、组件、系统 | 架构图、部署图 |
| 圆角矩形 | 服务、接口、动作 | 流程图、时序图 |
| 圆形/椭圆 | 角色、参与者、状态 | 用例图、状态图 |
| 菱形 | 判断、分支 | 流程图、决策树 |
| 圆柱体 | 数据库、存储 | 架构图、数据流图 |
| 平行四边形 | 数据、输入输出 | 数据流图 |
| 虚线框 | 边界、分组、可选 | 任何需要分组的场景 |
我个人的习惯是：架构图里所有模块都用直角矩形，所有外部系统用虚线框，所有数据库用圆柱体。这样即使我不写图例，有经验的读者也能一眼看懂。流程图里所有动作都用圆角矩形，判断用菱形，开始和结束用胶囊形（两端半圆的矩形）。这套规则一旦定下来，团队里所有人画图都遵守，沟通成本会大幅降低。
3.3 线条的粗细和样式比颜色更重要
很多人花大量时间调颜色，却忽略了线条。实际上，在信息传达效率上，线条样式 > 线条粗细 > 线条颜色。实线表示强关系（直接调用、同步请求），虚线表示弱关系（异步通知、依赖但非直接调用），点线表示可选关系或未来规划。箭头方向表示数据流向或控制流向。
线条粗细也有讲究：主流程用粗线（2px以上），辅助流程用细线（1px）。这样即使两张图内容一样，主流程突出的那张看起来就更有重点。我见过一个架构图，所有线条都是1px黑色实线，结果看的人根本分不清哪个是核心链路，哪个是边缘依赖。
还有一个细节：尽量避免线条交叉。如果两条线必须交叉，在交叉处画一个小半圆“跳线”，表示两条线没有连接关系。这个技巧在画复杂网络拓扑时特别有用，能减少大量歧义。
4. 场景适配：不同图种的设计要点完全不同
4.1 架构图：边界比细节重要
架构图的核心任务是说清楚“什么在什么里面”和“什么依赖什么”。所以边界（Boundary）是第一位的。我通常用虚线框或浅色背景块来表示边界，比如“客户端边界”“服务端边界”“第三方边界”。边界内部放模块，边界之间用箭头表示调用关系。
架构图最容易犯的错误是“把部署图画成架构图”。部署图关心的是物理节点、IP、端口、容器，架构图关心的是逻辑模块、职责、依赖。如果你在架构图上写“192.168.1.10:8080”，那说明你画错了。架构图上的模块应该是“用户服务”“订单服务”“支付网关”这种逻辑概念，具体部署在几台机器上、用什么端口，那是部署图的事。
另一个经验：架构图上的箭头要标注协议或方式。比如“HTTP/JSON”“gRPC”“MQ”“WebSocket”。不标的话，看的人会默认是同步调用，但实际上可能是异步消息，这会导致对系统行为的误解。我习惯在箭头旁边用小号灰色字体标注，不抢眼但信息完整。
4.2 流程图：泳道和异常分支是灵魂
流程图的核心任务是说清楚“谁在什么条件下做了什么动作，产生了什么结果”。所以泳道（Swimlane）是必不可少的。没有泳道的流程图，就像没有标点符号的长句，读起来费劲还容易歧义。
泳道怎么分？按角色分是最常见的：用户、前端、后端、数据库、第三方。但有时候按系统分更合适：客户端、网关、业务服务、数据层。选择标准是：看这张图的人最关心哪个维度的分工。如果是给业务方看，按角色分；如果是给运维看，按系统分。
流程图的另一个关键是异常分支。很多人画流程图只画“成功路径”，结果开发实现的时候发现各种边界情况没考虑。我习惯在画完主流程后，强制自己问三个问题：如果这一步失败了怎么办？如果这一步超时了怎么办？如果用户在这一步取消了怎么办？把这三个问题的答案画成异常分支，用红色或橙色线条标出。这样一张流程图才算是完整的。
注意：异常分支不要画得太深。如果异常处理本身很复杂，单独画一张“异常处理流程图”，在主流程图上只标注“见异常处理图X”。否则主流程会被异常分支淹没，失去可读性。
4.3 时序图：消息编号和激活条是专业度的分水岭
时序图（Sequence Diagram）是技术评审中最常用的图种之一，但也是最容易画得不专业的图种。不专业的时序图长这样：几条竖线，几个箭头，箭头上的文字挤在一起看不清。专业的时序图长这样：消息有编号，激活条（Activation Bar）清晰，返回消息用虚线，自调用消息用折线。
消息编号非常重要。当评审时有人说“第三步和第五步之间是不是漏了一个校验”，你可以直接说“没有漏，第三步的返回消息里包含了校验结果，你看编号3.1”。没有编号的话，大家只能靠“那个箭头”“上面那个”来指代，效率极低。
激活条表示对象在某个时间段内是活跃的。很多人忽略这个细节，结果看的人不知道某个服务是在处理请求还是已经返回了。我的习惯是：同步调用画实心激活条，异步处理画空心激活条。这样一眼就能看出哪些环节是阻塞的，哪些是并行的。
4.4 状态图：状态命名和迁移条件是关键
状态图（State Diagram）在业务系统里用得很多，比如订单状态、工单状态、审批状态。状态图最容易犯的错误是状态命名太随意。比如“待处理”“处理中”“已处理”——这三个状态看起来没问题，但仔细一想，“待处理”和“处理中”的边界是什么？谁来决定从“待处理”变成“处理中”？如果没有明确的迁移条件，开发实现的时候就会各写各的，最后状态机乱成一团。
我的经验是：状态名用“形容词+名词”或“过去分词”，比如“待审核”“审核中”“审核通过”“审核拒绝”。迁移条件用“事件+守卫条件”表示，比如“用户提交（事件）+ 金额小于1000（守卫条件）”。这样每个状态和每条迁移线都有明确的语义，开发照着实现就不会有歧义。
5. 工具选型：别在工具上纠结超过十分钟
5.1 三类工具，三种场景
市面上的画图工具大致分三类，各有各的适用场景：
第一类：代码化绘图工具（如PlantUML、Mermaid、Graphviz）。特点是图用代码描述，版本可控，适合放在代码仓库里跟代码一起维护。缺点是样式调整不灵活，复杂布局很难精确控制。我通常用这类工具画时序图和简单的流程图，因为这两类图对布局要求不高，代码化反而效率更高。
第二类：拖拽式绘图工具（如Draw.io、Excalidraw、Figma）。特点是所见即所得，样式自由度高，适合画架构图和需要精细排版的图。缺点是版本管理麻烦，多人协作容易冲突。我通常用这类工具画需要放进PPT或文档里的最终版图。
第三类：专业建模工具（如Enterprise Architect、Visual Paradigm）。特点是支持UML全规范，能生成代码和文档。缺点是学习曲线陡峭，启动慢。除非项目强制要求，否则我一般不用这类工具，因为大部分场景下Draw.io已经够用了。
5.2 我的实际工作流
经过多年折腾，我固定下来一套工作流：草稿阶段用Excalidraw，定稿阶段用Draw.io，需要版本管理的用PlantUML。
Excalidraw的手绘风格在草稿阶段特别好用，因为它“看起来就不像最终版”，所以评审的时候大家更愿意提意见，不会觉得“你都画这么漂亮了我还挑毛病是不是不太好”。等意见收集得差不多了，再用Draw.io画一版规整的，放进正式文档。
如果是需要长期维护的图（比如系统架构图），我会用PlantUML写一份，放在代码仓库的docs/目录下。每次架构变更，改代码的同时改图，保证图和代码同步。虽然PlantUML的样式不如Draw.io好看，但“同步更新”这个优点远远盖过了“不好看”这个缺点。
提示：不管你用什么工具，导出格式首选SVG。SVG是矢量图，放大不模糊，而且可以用文本编辑器打开，方便做批量替换（比如把所有“测试环境”改成“生产环境”）。PNG只适合发聊天消息，不适合放进文档。
5.3 团队协作的“图例规范”
如果你在团队里推动画图规范，第一件事不是教大家怎么画，而是定一份图例规范。这份规范不用很长，一页纸就够，但必须包含：形状语义、颜色语义、线条语义、字体大小、命名规则。
我见过一个团队，图例规范只有三条：蓝色方框是前端，绿色方框是后端，灰色方框是外部系统。就这三条，团队里所有人画的架构图风格统一，新人进来一看就懂。反而是一些定了二十页规范但没人看的团队，画出来的图五花八门。
图例规范定好之后，在团队共享的绘图工具里建一个模板文件。所有人画图都从这个模板开始，颜色、字体、形状都是预设好的，想跑偏都难。这个动作一次性投入半小时，后面能省几百小时的沟通成本。
6. 避坑实录：那些年我画废过的图
6.1 坑一：在图上写代码
刚工作那会儿，我画架构图喜欢在方框里写类名和方法名，觉得这样“信息量大、显得专业”。结果评审的时候，技术负责人看了一眼说：“你这是架构图还是代码注释？我要看的是模块职责，不是你的类设计。”后来我明白了：架构图的读者关心的是“这个模块负责什么”，而不是“这个模块怎么实现”。类名、方法名、参数类型，这些是详细设计文档的内容，不应该出现在架构图上。
正确的做法是：方框里只写模块名称和一句话职责描述。比如“订单服务：负责订单创建、查询、状态流转”。如果某个模块的职责特别复杂，用注释或附件说明，不要塞进方框里。
6.2 坑二：箭头方向画反
这个坑我踩过不止一次。特别是在画数据流图的时候，到底是“用户请求流向服务”还是“服务响应流向用户”，箭头方向经常搞混。后来我定了一个规矩：箭头永远指向“被调用方”或“数据接收方”。用户发起请求，箭头从用户指向服务；服务返回响应，箭头从服务指向用户。这样虽然图上会有双向箭头，但语义清晰，不会歧义。
还有一个更隐蔽的坑：异步消息的箭头方向。比如服务A发消息到消息队列，服务B从消息队列消费。正确的画法是：A → 消息队列 → B。但很多人画成A → B，把消息队列省略了。这在简单场景下没问题，但如果消息队列有重试、死信、顺序保证等特性，省略它就会导致理解偏差。
6.3 坑三：忽略图例和标题
我见过太多图，画得挺不错，但就是没有标题和图例。看的人第一反应是“这图讲什么的”，第二反应是“这个蓝色方块代表什么”。这两个问题消耗的认知资源，比图本身的内容还多。
标题要写“什么系统的什么图”，比如“订单系统-创建订单流程图”。不要只写“流程图”，更不要不写。图例要解释所有非通用的视觉元素，比如“橙色虚线表示异步调用”“灰色背景表示第三方边界”。如果图里用了缩写，图例里要给出全称。
6.4 坑四：一张图改到天荒地老
这是心理层面的坑。很多人画完图之后，反复调整布局、对齐、颜色，花了两小时画图，三小时调格式。我的建议是：设置一个“够用就好”的时间盒。草稿图15分钟，正式图45分钟。时间一到，不管满不满意，先发出去收集反馈。因为你自己觉得“不够完美”的地方，别人可能根本注意不到；而别人真正在意的问题，你可能压根没画出来。
我现在的习惯是：画完第一版之后，强制自己站起来走一圈，回来再看一眼。如果第一眼能看到核心信息，就发出去。如果第一眼觉得“有点乱”，就只调最乱的那一处，不整体重排。这样效率高很多，图的质量反而更好，因为你的精力花在了信息本身，而不是像素级对齐。
7. 从“画图”到“设计图”的思维转变
7.1 图是沟通工具，不是艺术品
这个认知转变花了我最长时间。刚入行的时候，我总觉得图要画得“漂亮”才算好。后来发现，一张“丑但清晰”的图，价值远远大于一张“美但费解”的图。因为图的本质是沟通工具，沟通的第一目标是“准确传递信息”，第二目标才是“让人愿意看”。
所以我现在画图，优先保证三件事：信息准确、层级清晰、重点突出。至于颜色搭配、图标精美、阴影渐变，这些都是锦上添花，有时间就做，没时间就不做。我甚至专门做过实验：同一份内容，一版用精心设计的配色和图标，一版只用黑白灰和基本形状。结果在评审中，黑白灰那版获得的有效反馈更多，因为大家把注意力放在了内容上，而不是“这个渐变色真好看”。
7.2 先写文字大纲，再画图
这是我强烈推荐的一个习惯：在打开任何绘图工具之前，先用纯文本写一份大纲。大纲的格式很简单：
图标题：______ 核心信息：______ 实体列表： - 实体A（类型：模块，职责：______） - 实体B（类型：外部系统，职责：______） 关系列表： - A → B（类型：同步调用，协议：HTTP） - B → A（类型：异步通知，协议：MQ）这份大纲写完之后，你自己读一遍，如果逻辑通顺，再开始画图。如果大纲里就有说不通的地方，画成图只会更乱。这个习惯让我画图的一次通过率提高了至少一倍，因为大部分逻辑问题在文字阶段就暴露了。
7.3 图的“可维护性”比“一次性效果”重要
如果你画的图需要长期使用（比如系统架构图、业务流程图），那可维护性就是第一优先级。什么叫可维护性？就是当系统变更时，你能在五分钟内更新图，而不是重新画一遍。
提高可维护性的技巧包括：用图层分离实体和样式、用组件复用相同模块、用变量管理颜色和字体、用注释记录变更历史。这些技巧在画单张图的时候可能显得麻烦，但当你有二十张图需要同步更新时，就能体会到好处了。
我自己的做法是：所有长期维护的图都用PlantUML或Mermaid写，放在Git仓库里。每次系统变更，改代码的同时改图，提交信息里写清楚“更新架构图：新增支付网关模块”。这样图的变更历史和代码的变更历史是对齐的，回溯问题的时候特别方便。
8. 几个能立刻用上的实操技巧
8.1 对齐和分布：手动调不如用工具
如果你还在手动拖拽方框来对齐，赶紧停下来。所有主流绘图工具都有对齐和分布功能。选中多个元素，按“水平居中对齐”或“垂直等距分布”，一秒钟搞定。这个技巧看起来简单，但我见过太多人不知道，硬是用方向键一个一个像素地调。
更高级一点的技巧是用网格和参考线。在Draw.io里按Ctrl+Shift+G打开网格，在Figma里按Ctrl+Shift+'打开布局网格。把元素吸附到网格上，整体会整齐很多。如果工具支持“智能参考线”（拖动时自动显示与其他元素的对齐关系），一定要打开。
8.2 字体：一个图里不要超过两种字号
字体大小是很多人忽略的细节。我见过一张图里用了五种字号，结果看的人不知道哪个是标题、哪个是正文、哪个是注释。一张图里最多两种字号：主字号（用于实体名称）和辅字号（用于注释和标注）。主字号比辅字号大2-4px就够了，不需要差太多。
字体家族也尽量统一。如果图要放进文档，用文档的正文字体；如果图要单独展示，用无衬线字体（如Arial、Helvetica、思源黑体）。不要用衬线字体画架构图，因为衬线字体在小字号下容易糊，投影的时候尤其明显。
8.3 导出：根据用途选格式和分辨率
| 用途 | 推荐格式 | 分辨率/设置 |
|---|---|---|
| 放进Word/PDF文档 | SVG或EMF | 矢量，无限缩放 |
| 放进PPT | PNG或SVG | PNG用2倍分辨率，SVG直接插入 |
| 发聊天消息 | PNG | 宽度1920px，文件小于2MB |
| 打印 | PDF或SVG | 矢量，A4或A3尺寸 |
| 网页展示 | SVG | 矢量，文件尽量小 |
注意：导出PNG的时候，背景一定要选透明或白色。我见过有人导出透明背景的PNG，结果在深色模式的聊天软件里，黑色文字完全看不见。如果不确定对方用什么背景，导出白色背景最安全。
8.4 快捷键：画图效率翻倍
不管你用什么工具，花十分钟把常用快捷键记下来，效率至少翻倍。以Draw.io为例：Ctrl+D复制，Ctrl+G组合，Ctrl+Shift+G取消组合，Ctrl+Shift+H水平翻转，Ctrl+Shift+J垂直翻转，Alt+Shift+方向键微调位置。这些快捷键在菜单里都能找到，但用快捷键操作，手不用离开键盘，思路不会断。
还有一个通用技巧：按住Shift键画线，可以锁定水平、垂直或45度角。画架构图的时候，水平线和垂直线占90%以上，按住Shift画出来的线又直又整齐，比手动调省事多了。
9. 最后分享一个我用了五年的“图检查清单”
每次画完图，在发出去之前，我会花两分钟过一遍这个清单。这个习惯帮我避免了很多低级错误，也让我画的图在团队里逐渐有了“靠谱”的口碑。
第一遍，看信息：图标题写了吗？核心信息在三秒内能看出来吗？有没有多余的元素可以删掉？实体和关系的命名有没有歧义？
第二遍，看视觉：颜色有没有超过四种？字号有没有超过两种？线条粗细有没有区分主次？对齐和分布整齐吗？
第三遍，看逻辑：箭头方向对吗？异常分支画了吗？边界标了吗？图例和缩写解释了吗？
第四遍，看场景：这张图是给谁看的？他看完之后能做出我期望的决策吗？如果我是他，我会问什么问题？这些问题图上能回答吗？
这四遍过完，图基本就没大问题了。如果时间紧，至少过第一遍和第三遍，这两遍能拦住80%的致命问题。
画图这件事，说到底是个“想清楚”的功夫。工具再熟、技巧再多，如果脑子里是一团浆糊，画出来的图也一定是浆糊。反过来，如果你能把信息分层、视觉编码、场景适配这三件事想明白，哪怕用记事本画ASCII图，别人也能看懂。我在实际项目中越来越觉得，画图的时间应该三七开：七分想，三分画。想明白了，画就是几分钟的事；没想明白，画三小时也是白画。
