1. 从"diagram-design"这个标题里能读出什么第一次看到"diagram-design"这个标题，我脑子里蹦出来的第一个判断是：这大概率不是一个单纯的"画图工具推荐"，而是一套关于图表设计方法论的沉淀。为什么这么说？因为如果只是推荐工具，标题通常会带上具体产品名，比如"用XX画架构图"；而"diagram-design"这种偏抽象的命名方式，往往意味着作者想聊的是"怎么设计一张好图"这件事本身，工具只是载体。图表设计这件事，看起来门槛很低——谁还不会拖几个框、连几条线呢？但真正做过技术方案评审、写过设计文档、给非技术同学讲过架构的人都知道，一张图能不能把事说清楚，差距是巨大的。我见过太多"信息全对但没人看得懂"的架构图，也见过那种一眼就能抓住重点、让人忍不住截图收藏的图。这中间的差距，就是图表设计的核心价值所在。这篇文章我想聊的不是某个具体软件的按钮在哪，而是把"diagram-design"这件事拆开揉碎：一张图从需求到落地的完整链路是什么、不同类型的图各自的设计逻辑有什么不同、有哪些反复被验证有效的实操技巧、以及那些只有踩过坑才知道的细节。不管你是刚入行要画第一张流程图的新人，还是已经画了几百张图但总觉得"差点意思"的老手，应该都能从里面找到能直接用的东西。需要先说明一点：下面涉及的具体工具、参数、配色值，都是基于我自己的实践和行业里比较通用的做法总结的，不是某个官方文档的搬运。你可以把它当成一个从业者的经验笔记来看，而不是标准答案。2. 图表设计的第一性问题：这张图到底为谁而画2.1 先定受众，再定一切很多人画图的第一步是打开工具，这是最大的误区。我的习惯是，动手之前先问自己三个问题：这张图给谁看、在什么场景下看、看完之后我希望对方做什么。这三个问题的答案，直接决定了后面所有的设计决策。举个具体的例子。同样是描述一个系统的数据流，给研发同事看的版本和给业务方看的版本，应该是两张完全不同的图。给研发看的，可以出现消息队列、缓存层、分库分表这些细节，连线可以密集，因为对方有能力在脑子里做信息过滤；给业务方看的，就得把技术组件抽象成"订单服务""支付服务"这种业务语言，连线要少，重点突出数据从哪来到哪去。如果你拿研发版去给业务方讲，对方大概率会在第三分钟就走神。场景也很关键。是放在PPT里投屏讲，还是放在文档里让人自己看？投屏讲的图，字号要大、信息要少，因为观众只有几秒钟扫一眼；文档里的图可以信息密度高一些，因为读者可以放大、可以反复看。我吃过这个亏——有一次把一张信息很密的架构图直接塞进汇报PPT，投影出来之后后排同事根本看不清框里的字，整个讲解效果打了对折。2.2 一张图只讲一件事这是我最想强调的原则，也是最难做到的。人的短期记忆容量有限，一张图如果同时想表达"系统架构""部署拓扑""调用时序"三件事，结果往往是三件事都没讲清楚。正确的做法是拆图。一张总览图负责建立全局认知，然后用若干张分图分别深入某个维度。总览图上只放最核心的模块和它们之间的关系，细节全部下沉到分图。这样读者可以先看总览建立框架，再按需深入。我现在的习惯是，任何一个稍微复杂点的系统，至少准备三张图：一张业务视角的、一张技术架构的、一张关键流程的。提示：如果你发现一张图上的连线开始交叉打结、框里的文字需要缩小到8号字才能塞下，这就是该拆图的信号了，别硬撑。2.3 信息层级比美观更重要新手容易陷入"把图做好看"的执念，花大量时间调颜色、找图标，但忽略了信息层级。实际上，一张图好不好用，80%取决于信息层级是否清晰，20%才是视觉美观。信息层级怎么建立？靠的是视觉权重的差异化。重要的模块用更大的框、更深的颜色、更粗的边框；次要的模块用浅色、细边框、小字号。读者扫一眼，视线自然会被引导到重点上。如果所有框都一样大、一样颜色，读者就得自己判断哪个重要，认知负担一下就上来了。我常用的一个简单规则是"三档制"：核心模块、支撑模块、外部依赖，各用一套视觉样式。这样即使图上有二十个框，读者也能瞬间分出主次。3. 不同图种的底层设计逻辑差异3.1 流程图：重点在"分支"和"异常"流程图是最常见的图种，但很多人画流程图只画了"正常路径"，把异常分支全省略了。这样的流程图看着清爽，实际价值有限，因为真正需要看图的人，往往就是想搞清楚"出错了怎么办"。我的做法是，主流程用一条清晰的主线走下来，异常分支用虚线或者不同颜色标出来，并且在分支上标注触发条件。比如一个订单流程，正常路径是"下单→支付→发货→完成"，那支付超时怎么办、库存不足怎么办、用户取消怎么办，这些分支都得有。分支多的时候，可以用"子流程"的方式折叠，主图上只画一个"异常处理"的框，细节放到另一张图。另一个细节是判断节点的表达。菱形框里写条件，出来的线要标注"是/否"或者具体条件值，不要让人去猜。我见过太多流程图，菱形框出来两条线，什么标注都没有，读者只能靠上下文猜哪条是哪个分支。3.2 架构图：分层是永恒的主题架构图的核心是分层。不管是经典的三层架构，还是现在流行的各种分层模式，本质都是把系统按职责切成若干层，层与层之间定义清晰的依赖关系。画架构图时，我建议遵循"从上到下、从外到内"的阅读顺序。最上面是用户/接入层，往下是业务逻辑层，再往下是数据层，最下面是基础设施。每一层内部的模块横向排列，层与层之间的调用关系用箭头表示。这样读者从上往下看，就能理解一个请求是怎么穿过整个系统的。有个容易忽略的点：箭头的方向要统一。要么统一表示"调用"，要么统一表示"数据流向"，不要混用。我见过一张图，有的箭头表示调用、有的表示数据流、有的表示依赖，读者根本没法建立统一的认知模型。如果确实需要表达多种关系，就用不同样式的箭头（实线、虚线、不同颜色）并加图例说明。3.3 时序图：时间轴是灵魂时序图（也叫序列图）的特点是有一条明确的时间轴，从上往下表示时间推进。它的价值在于表达"谁在什么时候对谁做了什么"。画时序图时，参与者（也就是图顶部那些竖条）的排列顺序有讲究。一般把发起方放在最左边，然后按调用顺序往右排。这样连线从左往右展开，符合阅读习惯。如果参与者很多，可以把不重要的合并成一个"其他"。时序图最容易画错的地方是激活条（就是竖条上那些细长的矩形）。激活条表示对象在这段时间内是活跃的，很多新手会忘记画或者画错位置。我的经验是，激活条从收到消息开始，到发出返回消息结束，这样能清晰看出每个对象的生命周期。3.4 状态图：别漏了"终态"状态图描述的是一个对象在生命周期内经历的各种状态以及状态之间的转换。它和流程图的区别在于，流程图关注"做什么"，状态图关注"处于什么状态"。画状态图时，两个细节特别重要：一是初始状态和终止状态必须明确标出，初始状态用实心圆，终止状态用带圈的实心圆；二是状态转换的触发条件要写清楚，是某个事件触发了转换，还是满足了某个条件。我见过不少状态图，状态框画得挺全，但转换线上什么都没写，读者完全不知道什么情况下会从A状态变到B状态。4. 让图"能看"的视觉设计实操4.1 配色：少即是多配色是图表设计里最容易翻车的地方。新手常见的错误是用太多颜色，一张图上七八种颜色，看着热闹，实际干扰阅读。我的配色原则是：主色不超过三种，其余用中性色。主色用来区分不同类别或者强调重点，中性色（灰、白、浅灰）用来填充背景和次要元素。具体来说，可以选一个主色（比如蓝色系）作为核心模块，一个辅助色（比如橙色系）作为强调，然后灰色系处理其余部分。如果确实需要区分多个类别，用同一个色系的不同深浅，比用完全不同的颜色更协调。比如五个模块，用同一个蓝色的五档深浅，既区分了彼此，又保持了整体感。注意：如果你的图要打印成黑白，一定要提前测试。很多在屏幕上靠颜色区分的图，打印出来全变成灰色，区分度就没了。这种情况要靠形状、边框样式、填充纹理来区分。4.2 字体与字号：可读性优先字号的选择标准只有一个：在最终展示环境下能看清。如果是投屏，正文至少18号；如果是文档，正文至少10号；如果是手机上看，那得更大了。字体方面，中文用黑体系（比如思源黑体、苹方），英文用无衬线体（比如Helvetica、Arial），这类字体在屏幕上清晰度高。避免用宋体这类衬线体做图内文字，小字号下容易糊。还有一个细节：同一张图里的字号层级不要超过三档。比如标题16号、正文12号、注释10号，三档就够了。字号层级太多，读者反而分不清主次。4.3 对齐与间距：细节决定专业度对齐这件事，说起来简单，做起来难。一张图里如果有十几个框，手动对齐很容易出现几个像素的偏差，整体看起来就是"不整齐"。我的做法是，画图时打开网格和对齐辅助线，让工具帮你对齐。如果工具支持"分布"功能，把多个框等距分布，视觉上会舒服很多。间距方面，同类元素之间的间距要一致，不同类元素之间的间距要明显大于同类间距，这样分组关系一目了然。4.4 连线：能直不弯，能少不多连线是图表里最容易乱的部分。我的原则是：能画直线就不画曲线，能少画一条就少画一条。曲线虽然有时候能避开障碍，但多了之后整张图会显得杂乱。如果连线必须交叉，用"跳线"（就是交叉处画个小弧）表示不相连，比直接交叉清晰。如果两个模块之间连线太多，考虑把它们合并或者用一条粗线表示"多条关系"。另外，连线上的文字标注要尽量短，能用一个词就不用一句话。标注位置要靠近连线，不要飘在半空中让人猜是哪条线的标注。5. 工具选型：不同场景用不同的家伙5.1 快速草图：纸笔和轻量工具如果只是自己理思路，别打开复杂工具，纸笔最快。我很多架构的雏形都是在纸上画出来的，画错了划掉重画，比在软件里拖来拖去快得多。数字化的话，一些轻量的白板类工具也很适合，随手画、随手改，不追求精美。这个阶段的目标是"想清楚"，不是"画好看"。所以别纠结配色和字体，把逻辑理顺就行。5.2 正式文档：结构化绘图工具要放进设计文档、需要长期维护的图，就得用结构化的绘图工具。这类工具的特点是元素有语义（这个框是"服务"、那个框是"数据库"），支持自动布局，改起来方便。选这类工具时，我关注几个点：是否支持版本管理（图会随系统演进，得能追溯）、是否支持导出多种格式（文档里用PNG，汇报用矢量图）、是否支持协作（多人编辑同一张图）。这几个点直接决定了长期使用的效率。5.3 汇报展示：美观度优先给领导或客户汇报用的图，美观度权重会高一些。这类场景可以考虑用设计感更强的工具，或者干脆用PPT/Keynote手绘。关键是要控制信息量，一张图只讲一个核心观点，配合讲解逐步展开。我个人的习惯是，汇报用的图会单独做一版"精简版"，把文档版里的细节全部砍掉，只留最核心的三五个模块。讲解时用动画逐步显示，效果比一次性全展示好很多。5.4 工具选型对照场景核心诉求选型方向注意事项个人理思路快纸笔、轻量白板不追求美观，逻辑优先设计文档可维护结构化绘图工具关注版本管理和导出汇报展示美观设计型工具或PPT信息量要砍到最少多人协作实时同步支持协作的工具注意权限和冲突处理6. 那些只有踩过坑才知道的细节6.1 图会过期，维护比创建更重要这是最容易被忽略的一点。系统在演进，图如果不同步更新，很快就会变成"误导性文档"。我见过太多项目，文档里的架构图还是半年前的版本，新来的同事照着图理解系统，结果完全对不上。我的做法是，把图源文件纳入版本管理，和代码一起提交。每次架构有变更，强制要求更新对应的图。如果团队用文档平台，可以在图旁边标注"最后更新日期"和"对应版本"，让人一眼知道这张图是不是最新的。6.2 图例不是可选项只要图里用了不同颜色、不同线型、不同形状来表达不同含义，就必须有图例。我见过太多图，用了三种颜色但没说明分别代表什么，读者只能猜。图例的位置一般在图的角落，不遮挡主要内容。6.3 给图起个好名字图的名字和文件名都很重要。名字要能说明这张图讲的是什么，比如"订单系统-支付流程-异常分支"，而不是"流程图1"。文件名同理，用有意义的命名，方便日后检索。我习惯用"模块-图种-版本"的格式，比如"order-arch-v2"。6.4 留白是设计的一部分新手总想把图填满，觉得空白是浪费。实际上，留白能让图"呼吸"，让读者的眼睛有休息的地方。模块之间、图与边界之间，都要留出足够的空白。一张挤得满满当当的图，即使内容全对，阅读体验也很差。6.5 找人试读图做完之后，找个没参与这个项目的同事看一眼，问他"你能看懂这张图在讲什么吗"。如果对方看了半天说不清楚，说明图有问题。这个"试读"环节能发现很多自己看不见的问题，因为画图的人对内容太熟悉了，会自动脑补缺失的信息。7. 从需求到成图的完整工作流把上面这些串起来，我自己画一张图的完整流程大概是这样：第一步，明确受众和场景，想清楚这张图要回答什么问题。第二步，在纸上或者白板上快速画出逻辑草图，把模块和关系理清楚，这一步不碰任何美化。第三步，把草图搬到绘图工具里，先搭结构，用最朴素的样式把框和线摆好。第四步，建立信息层级，用大小、颜色、粗细区分主次。第五步，调整视觉细节，对齐、间距、配色、字体。第六步，加图例和标注，确保没有歧义。第七步，找人试读，根据反馈修改。第八步，导出并归档，标注版本和日期。这个流程里，前两步花的时间往往比后面所有步骤加起来还多，但这是值得的。逻辑没理顺就急着美化，最后大概率要推倒重来。8. 关于图表设计这件事，我的一点个人体会画了这么多年图，我最大的体会是：图表设计本质上是一种翻译工作。你把脑子里的系统结构、流程逻辑，翻译成别人能看懂的视觉语言。翻译得好不好，不取决于你用了多高级的工具、多漂亮的配色，而取决于你有没有真正站在读者的角度想问题。我早期画图也走过弯路，追求"看起来专业"，用了很多花哨的效果，结果读者反馈"看不懂"。后来慢慢明白，好的图表是"隐形"的——读者看的时候不会注意到设计本身，只会顺着图把内容理解了。当你听到有人说"这张图讲得真清楚"而不是"这张图真好看"的时候，说明设计到位了。另外一个体会是，图表设计能力是可以刻意练习的。我的方法是，看到好的图就存下来，分析它为什么清楚——是分层做得好，还是配色克制，还是信息量控制得当。积累多了，自己画的时候自然就有感觉了。反过来，看到看不懂的图也分析一下问题出在哪，避免自己犯同样的错。最后分享一个我一直在用的小技巧：画完图之后，把图缩小到50%看一眼。如果缩小之后还能看出主要结构和重点，说明信息层级是清晰的；如果缩小之后变成一团糊，说明细节太多、层级没拉开。这个"缩略图测试"简单但有效，推荐你也试试。
1. 从"diagram-design"这个标题里能读出什么第一次看到"diagram-design"这个标题，我脑子里蹦出来的第一个判断是：这大概率不是一个单纯的"画图工具推荐"，而是一套关于图表设计方法论的沉淀。为什么这么说？因为如果只是推荐工具，标题通常会带上具体产品名，比如"用XX画架构图"；而"diagram-design"这种偏抽象的命名方式，往往意味着作者想聊的是"怎么设计一张好图"这件事本身，工具只是载体。图表设计这件事，看起来门槛很低——谁还不会拖几个框、连几条线呢？但真正做过技术方案评审、写过设计文档、给非技术同学讲过架构的人都知道，一张图能不能把事说清楚，差距是巨大的。我见过太多"信息全对但没人看得懂"的架构图，也见过那种一眼就能抓住重点、让人忍不住截图收藏的图。这中间的差距，就是图表设计的核心价值所在。这篇文章我想聊的不是某个具体软件的按钮在哪，而是把"diagram-design"这件事拆开揉碎：一张图从需求到落地的完整链路是什么、不同类型的图各自的设计逻辑有什么不同、有哪些反复被验证有效的实操技巧、以及那些只有踩过坑才知道的细节。不管你是刚入行要画第一张流程图的新人，还是已经画了几百张图但总觉得"差点意思"的老手，应该都能从里面找到能直接用的东西。需要先说明一点：下面涉及的具体工具、参数、配色值，都是基于我自己的实践和行业里比较通用的做法总结的，不是某个官方文档的搬运。你可以把它当成一个从业者的经验笔记来看，而不是标准答案。2. 图表设计的第一性问题：这张图到底为谁而画2.1 先定受众，再定一切很多人画图的第一步是打开工具，这是最大的误区。我的习惯是，动手之前先问自己三个问题：这张图给谁看、在什么场景下看、看完之后我希望对方做什么。这三个问题的答案，直接决定了后面所有的设计决策。举个具体的例子。同样是描述一个系统的数据流，给研发同事看的版本和给业务方看的版本，应该是两张完全不同的图。给研发看的，可以出现消息队列、缓存层、分库分表这些细节，连线可以密集，因为对方有能力在脑子里做信息过滤；给业务方看的，就得把技术组件抽象成"订单服务""支付服务"这种业务语言，连线要少，重点突出数据从哪来到哪去。如果你拿研发版去给业务方讲，对方大概率会在第三分钟就走神。场景也很关键。是放在PPT里投屏讲，还是放在文档里让人自己看？投屏讲的图，字号要大、信息要少，因为观众只有几秒钟扫一眼；文档里的图可以信息密度高一些，因为读者可以放大、可以反复看。我吃过这个亏——有一次把一张信息很密的架构图直接塞进汇报PPT，投影出来之后后排同事根本看不清框里的字，整个讲解效果打了对折。2.2 一张图只讲一件事这是我最想强调的原则，也是最难做到的。人的短期记忆容量有限，一张图如果同时想表达"系统架构""部署拓扑""调用时序"三件事，结果往往是三件事都没讲清楚。正确的做法是拆图。一张总览图负责建立全局认知，然后用若干张分图分别深入某个维度。总览图上只放最核心的模块和它们之间的关系，细节全部下沉到分图。这样读者可以先看总览建立框架，再按需深入。我现在的习惯是，任何一个稍微复杂点的系统，至少准备三张图：一张业务视角的、一张技术架构的、一张关键流程的。提示：如果你发现一张图上的连线开始交叉打结、框里的文字需要缩小到8号字才能塞下，这就是该拆图的信号了，别硬撑。2.3 信息层级比美观更重要新手容易陷入"把图做好看"的执念，花大量时间调颜色、找图标，但忽略了信息层级。实际上，一张图好不好用，80%取决于信息层级是否清晰，20%才是视觉美观。信息层级怎么建立？靠的是视觉权重的差异化。重要的模块用更大的框、更深的颜色、更粗的边框；次要的模块用浅色、细边框、小字号。读者扫一眼，视线自然会被引导到重点上。如果所有框都一样大、一样颜色，读者就得自己判断哪个重要，认知负担一下就上来了。我常用的一个简单规则是"三档制"：核心模块、支撑模块、外部依赖，各用一套视觉样式。这样即使图上有二十个框，读者也能瞬间分出主次。3. 不同图种的底层设计逻辑差异3.1 流程图：重点在"分支"和"异常"流程图是最常见的图种，但很多人画流程图只画了"正常路径"，把异常分支全省略了。这样的流程图看着清爽，实际价值有限，因为真正需要看图的人，往往就是想搞清楚"出错了怎么办"。我的做法是，主流程用一条清晰的主线走下来，异常分支用虚线或者不同颜色标出来，并且在分支上标注触发条件。比如一个订单流程，正常路径是"下单→支付→发货→完成"，那支付超时怎么办、库存不足怎么办、用户取消怎么办，这些分支都得有。分支多的时候，可以用"子流程"的方式折叠，主图上只画一个"异常处理"的框，细节放到另一张图。另一个细节是判断节点的表达。菱形框里写条件，出来的线要标注"是/否"或者具体条件值，不要让人去猜。我见过太多流程图，菱形框出来两条线，什么标注都没有，读者只能靠上下文猜哪条是哪个分支。3.2 架构图：分层是永恒的主题架构图的核心是分层。不管是经典的三层架构，还是现在流行的各种分层模式，本质都是把系统按职责切成若干层，层与层之间定义清晰的依赖关系。画架构图时，我建议遵循"从上到下、从外到内"的阅读顺序。最上面是用户/接入层，往下是业务逻辑层，再往下是数据层，最下面是基础设施。每一层内部的模块横向排列，层与层之间的调用关系用箭头表示。这样读者从上往下看，就能理解一个请求是怎么穿过整个系统的。有个容易忽略的点：箭头的方向要统一。要么统一表示"调用"，要么统一表示"数据流向"，不要混用。我见过一张图，有的箭头表示调用、有的表示数据流、有的表示依赖，读者根本没法建立统一的认知模型。如果确实需要表达多种关系，就用不同样式的箭头（实线、虚线、不同颜色）并加图例说明。3.3 时序图：时间轴是灵魂时序图（也叫序列图）的特点是有一条明确的时间轴，从上往下表示时间推进。它的价值在于表达"谁在什么时候对谁做了什么"。画时序图时，参与者（也就是图顶部那些竖条）的排列顺序有讲究。一般把发起方放在最左边，然后按调用顺序往右排。这样连线从左往右展开，符合阅读习惯。如果参与者很多，可以把不重要的合并成一个"其他"。时序图最容易画错的地方是激活条（就是竖条上那些细长的矩形）。激活条表示对象在这段时间内是活跃的，很多新手会忘记画或者画错位置。我的经验是，激活条从收到消息开始，到发出返回消息结束，这样能清晰看出每个对象的生命周期。3.4 状态图：别漏了"终态"状态图描述的是一个对象在生命周期内经历的各种状态以及状态之间的转换。它和流程图的区别在于，流程图关注"做什么"，状态图关注"处于什么状态"。画状态图时，两个细节特别重要：一是初始状态和终止状态必须明确标出，初始状态用实心圆，终止状态用带圈的实心圆；二是状态转换的触发条件要写清楚，是某个事件触发了转换，还是满足了某个条件。我见过不少状态图，状态框画得挺全，但转换线上什么都没写，读者完全不知道什么情况下会从A状态变到B状态。4. 让图"能看"的视觉设计实操4.1 配色：少即是多配色是图表设计里最容易翻车的地方。新手常见的错误是用太多颜色，一张图上七八种颜色，看着热闹，实际干扰阅读。我的配色原则是：主色不超过三种，其余用中性色。主色用来区分不同类别或者强调重点，中性色（灰、白、浅灰）用来填充背景和次要元素。具体来说，可以选一个主色（比如蓝色系）作为核心模块，一个辅助色（比如橙色系）作为强调，然后灰色系处理其余部分。如果确实需要区分多个类别，用同一个色系的不同深浅，比用完全不同的颜色更协调。比如五个模块，用同一个蓝色的五档深浅，既区分了彼此，又保持了整体感。注意：如果你的图要打印成黑白，一定要提前测试。很多在屏幕上靠颜色区分的图，打印出来全变成灰色，区分度就没了。这种情况要靠形状、边框样式、填充纹理来区分。4.2 字体与字号：可读性优先字号的选择标准只有一个：在最终展示环境下能看清。如果是投屏，正文至少18号；如果是文档，正文至少10号；如果是手机上看，那得更大了。字体方面，中文用黑体系（比如思源黑体、苹方），英文用无衬线体（比如Helvetica、Arial），这类字体在屏幕上清晰度高。避免用宋体这类衬线体做图内文字，小字号下容易糊。还有一个细节：同一张图里的字号层级不要超过三档。比如标题16号、正文12号、注释10号，三档就够了。字号层级太多，读者反而分不清主次。4.3 对齐与间距：细节决定专业度对齐这件事，说起来简单，做起来难。一张图里如果有十几个框，手动对齐很容易出现几个像素的偏差，整体看起来就是"不整齐"。我的做法是，画图时打开网格和对齐辅助线，让工具帮你对齐。如果工具支持"分布"功能，把多个框等距分布，视觉上会舒服很多。间距方面，同类元素之间的间距要一致，不同类元素之间的间距要明显大于同类间距，这样分组关系一目了然。4.4 连线：能直不弯，能少不多连线是图表里最容易乱的部分。我的原则是：能画直线就不画曲线，能少画一条就少画一条。曲线虽然有时候能避开障碍，但多了之后整张图会显得杂乱。如果连线必须交叉，用"跳线"（就是交叉处画个小弧）表示不相连，比直接交叉清晰。如果两个模块之间连线太多，考虑把它们合并或者用一条粗线表示"多条关系"。另外，连线上的文字标注要尽量短，能用一个词就不用一句话。标注位置要靠近连线，不要飘在半空中让人猜是哪条线的标注。5. 工具选型：不同场景用不同的家伙5.1 快速草图：纸笔和轻量工具如果只是自己理思路，别打开复杂工具，纸笔最快。我很多架构的雏形都是在纸上画出来的，画错了划掉重画，比在软件里拖来拖去快得多。数字化的话，一些轻量的白板类工具也很适合，随手画、随手改，不追求精美。这个阶段的目标是"想清楚"，不是"画好看"。所以别纠结配色和字体，把逻辑理顺就行。5.2 正式文档：结构化绘图工具要放进设计文档、需要长期维护的图，就得用结构化的绘图工具。这类工具的特点是元素有语义（这个框是"服务"、那个框是"数据库"），支持自动布局，改起来方便。选这类工具时，我关注几个点：是否支持版本管理（图会随系统演进，得能追溯）、是否支持导出多种格式（文档里用PNG，汇报用矢量图）、是否支持协作（多人编辑同一张图）。这几个点直接决定了长期使用的效率。5.3 汇报展示：美观度优先给领导或客户汇报用的图，美观度权重会高一些。这类场景可以考虑用设计感更强的工具，或者干脆用PPT/Keynote手绘。关键是要控制信息量，一张图只讲一个核心观点，配合讲解逐步展开。我个人的习惯是，汇报用的图会单独做一版"精简版"，把文档版里的细节全部砍掉，只留最核心的三五个模块。讲解时用动画逐步显示，效果比一次性全展示好很多。5.4 工具选型对照场景核心诉求选型方向注意事项个人理思路快纸笔、轻量白板不追求美观，逻辑优先设计文档可维护结构化绘图工具关注版本管理和导出汇报展示美观设计型工具或PPT信息量要砍到最少多人协作实时同步支持协作的工具注意权限和冲突处理6. 那些只有踩过坑才知道的细节6.1 图会过期，维护比创建更重要这是最容易被忽略的一点。系统在演进，图如果不同步更新，很快就会变成"误导性文档"。我见过太多项目，文档里的架构图还是半年前的版本，新来的同事照着图理解系统，结果完全对不上。我的做法是，把图源文件纳入版本管理，和代码一起提交。每次架构有变更，强制要求更新对应的图。如果团队用文档平台，可以在图旁边标注"最后更新日期"和"对应版本"，让人一眼知道这张图是不是最新的。6.2 图例不是可选项只要图里用了不同颜色、不同线型、不同形状来表达不同含义，就必须有图例。我见过太多图，用了三种颜色但没说明分别代表什么，读者只能猜。图例的位置一般在图的角落，不遮挡主要内容。6.3 给图起个好名字图的名字和文件名都很重要。名字要能说明这张图讲的是什么，比如"订单系统-支付流程-异常分支"，而不是"流程图1"。文件名同理，用有意义的命名，方便日后检索。我习惯用"模块-图种-版本"的格式，比如"order-arch-v2"。6.4 留白是设计的一部分新手总想把图填满，觉得空白是浪费。实际上，留白能让图"呼吸"，让读者的眼睛有休息的地方。模块之间、图与边界之间，都要留出足够的空白。一张挤得满满当当的图，即使内容全对，阅读体验也很差。6.5 找人试读图做完之后，找个没参与这个项目的同事看一眼，问他"你能看懂这张图在讲什么吗"。如果对方看了半天说不清楚，说明图有问题。这个"试读"环节能发现很多自己看不见的问题，因为画图的人对内容太熟悉了，会自动脑补缺失的信息。7. 从需求到成图的完整工作流把上面这些串起来，我自己画一张图的完整流程大概是这样：第一步，明确受众和场景，想清楚这张图要回答什么问题。第二步，在纸上或者白板上快速画出逻辑草图，把模块和关系理清楚，这一步不碰任何美化。第三步，把草图搬到绘图工具里，先搭结构，用最朴素的样式把框和线摆好。第四步，建立信息层级，用大小、颜色、粗细区分主次。第五步，调整视觉细节，对齐、间距、配色、字体。第六步，加图例和标注，确保没有歧义。第七步，找人试读，根据反馈修改。第八步，导出并归档，标注版本和日期。这个流程里，前两步花的时间往往比后面所有步骤加起来还多，但这是值得的。逻辑没理顺就急着美化，最后大概率要推倒重来。8. 关于图表设计这件事，我的一点个人体会画了这么多年图，我最大的体会是：图表设计本质上是一种翻译工作。你把脑子里的系统结构、流程逻辑，翻译成别人能看懂的视觉语言。翻译得好不好，不取决于你用了多高级的工具、多漂亮的配色，而取决于你有没有真正站在读者的角度想问题。我早期画图也走过弯路，追求"看起来专业"，用了很多花哨的效果，结果读者反馈"看不懂"。后来慢慢明白，好的图表是"隐形"的——读者看的时候不会注意到设计本身，只会顺着图把内容理解了。当你听到有人说"这张图讲得真清楚"而不是"这张图真好看"的时候，说明设计到位了。另外一个体会是，图表设计能力是可以刻意练习的。我的方法是，看到好的图就存下来，分析它为什么清楚——是分层做得好，还是配色克制，还是信息量控制得当。积累多了，自己画的时候自然就有感觉了。反过来，看到看不懂的图也分析一下问题出在哪，避免自己犯同样的错。最后分享一个我一直在用的小技巧：画完图之后，把图缩小到50%看一眼。如果缩小之后还能看出主要结构和重点，说明信息层级是清晰的；如果缩小之后变成一团糊，说明细节太多、层级没拉开。这个"缩略图测试"简单但有效，推荐你也试试。