diagram-design 这个词我研究了很久最终把它定义为一张图从最初的想法到最终可交付物的整个设计过程。技术圈里我们每天都要画各种图系统架构图、业务流程图、数据流转图、部署拓扑图……可真正能把图画得让人一眼看懂的人其实不多。我自己前期也画废过无数张图后来才摸到一套相对稳定的方法。这篇文章就是我这些年画图踩坑、总结、再实践的完整记录适合做技术方案、写文档、做汇报、带新人的同学参考哪怕你只负责整理周报里的流程图也能从中找到立即能用的细节。1. 为什么说 diagram-design 是技术表达里的硬通货看代码的时候最怕什么我最怕一上来就是三百行的if else嵌套没有注释没有文档。与之类似我拿到一份技术方案如果半小时之后还没看明白系统是怎么拼起来的那基本就是 diagram-design 出了问题。图不是装饰品它是技术表达的核心载体。你写的架构设计、实施方案、复盘报告别人第一眼看的不是文字而是图。1.1 一张图能解决什么问题比如你要解释一个订单支付后异步通知商家的流程。用文字写要写五六行中间还容易漏掉各种分支。用图一条泳道图拉下来用户、订单中心、支付网关、商家系统各自负责什么一清二楚。这背后的设计过程才是 diagram-design 的关键不是打开工具画个框加个箭头而是先搞清楚这个图给谁看、要回答什么问题、信息密度放到多大。我见过太多图问题根本不在工具而在设计。有人用 Word 画了一整天结果导出图片放大后全是毛边。有人把系统里所有组件全塞进一张图结果屏幕都装不下。还有人配色像迪厅红黄蓝绿全招呼。这些都不是工具问题是脑袋里缺了一套 diagram-design 的方法论。1.2 我见过的几种灾难级画图我把这些年看到的翻车现场总结成四类如果你发现自己中招那这篇内容正好可以继续看下去。第一类是俄罗斯套娃图。一个大方块套一堆中框中框里再塞小组件层层嵌套看的人根本分不清边界在哪。乍一看很厉害仔细一看全是容器套容器层次关系表达得一塌糊涂。第二类是贪吃蛇图。箭头绕来绕去从右下角绕到左上角横跨整个画面不画跳线根本走不通。这种图往往是因为一开始没规划布局想到哪画到哪最后只能靠长长的连线硬接。第三类是文字地狱图。每个框里都塞进三大段话字号还调到 6pt美其名曰信息完整实际没人看得清。一旦导出成图字、线、框糊成一团。第四类是五彩斑斓图。每个组件一种颜色背景再铺上渐变像幼儿园涂鸦。这种图第一眼很热闹第二眼就不知道该聚焦哪里。这些图都有一个共同点设计者把图当成了文字的压缩包把所有信息堆进去却不考虑读者如何读取信息。diagram-design 的前提是你得承认图是一件需要刻意设计的作品而不是草稿的截图。2. 动手之前先想清楚三件事很多人打开画图工具就动手画到一半又推翻重来就是因为跳过了设计前思考这一步。我现在的习惯是先花十分钟想清楚三件事再打开工具。这三件事直接决定这张图是清晰还是混乱。2.1 明确读者是谁同一个系统的架构给程序员看和给老板看完全是两张图。给程序员看可以聊服务粒度、协议类型、数据流向、故障边界给老板看重点应该是业务模块、用户价值、团队分工、项目节点。如果你不分对象把给老板看的那版画成了技术细节大合集那对方大概率只关心四件事系统稳定吗、用户量大吗、要花多少钱、什么时候上线。我做过一个典型的调整同样是一张权限中心示意图给研发组的版本里我画了 token 校验、缓存策略、DB 表关系给产品侧的版本里我只画了登录 → 鉴权 → 授权 → 审计四个模块每个模块配一句话职责说明。两张图画了不到一小时效果却天差地别。所以diagram-design 的第一步永远是明确这张图是给谁看的他需要从中获取什么。2.2 确定图的类型很多人把流程图、架构图、时序图混着画一会儿流程一会儿结构一会儿时序结果变成四不像。我建议拿到需求后先对号入座选一种主导图型图型表达核心适合场景典型布局架构图系统模块与关系系统设计、方案评审分层或拓扑式流程图步骤与分支业务流程、状态流转纵向泳道或线性时序图消息先后顺序接口交互、日志排查横向生命线组织关系图层级与归属团队结构、权限树自上而下树状思维导图发散与归类头脑风暴、需求梳理中心向外扩散每一种图型都有自己最适合的布局逻辑。有人画架构图非要用泳道有人画流程图非要搞成树状结构。这些不是说完全不行而是容易误导阅读者。读者对图表有天然的语义预期看到泳道就认为是职责划分看到箭头就认为是数据流或控制流。一旦你的表达不符合预期解读成本立刻上升。2.3 画一个明确的信息边界这是我最想强调的一点。很多人一张图想容纳所有信息恨不得把整个公司的系统都画进来。结果图越画越大信息越堆越多最后谁也没看懂。正确做法是给这张图划定一个严格的信息边界只展示与当前主题强相关的内容。打个比方你看地图 App 的时候它不会把全中国所有 POI 一次全显示而是根据你的缩放级别只展示当前屏幕上有价值的内容。diagram-design 也一样你要像缩放地图一样控制信息密度。比如画支付链路架构图那 Redis 缓存、消息队列、数据库就必须出现但如果你把客户关怀系统也塞进来那就不合理了除非它们真的在同一条链路上承担职责。我的经验是每次准备加一个框之前先问自己三个问题它跟当前核心主题有直接关系吗如果不画它读者会不会产生误解它占的位置要不要超过画面面积的 10%如果这三个问题都没通过就先不放。等图的主体结构清晰了再用附录或引用另一张图的方式补充。3. 核心细节拆解布局、连线、配色与图标把这些想清楚的事情做完之后才进入真正动笔的阶段。diagram-design 的核心细节我总结为四件事布局、连线、配色、文字图标。这四件事环环相扣任何一个做不好整张图都会别扭。3.1 布局确定主方向、层级和留白布局是一张图的骨架。我一般按主方向 → 层级 → 留白三步来搭。主方向优先。如果一个流程是从用户触发开始的我习惯从上到下布局因为阅读习惯是从左上角开始。如果是展示系统模块间的依赖关系我习惯从左到右布局主调用方在左被依赖方在右。架构分层图则反过来从上到下是接入层、应用层、数据层一层一层往下走。层级要清晰。同一层级的节点视觉上必须对齐。不同层级的节点要通过间距或分组明确区分。比如画一个三层的微服务架构网关层、业务层、数据层各自放在一个横向区域内区域之间留出明显的空白带。这样读者一眼就能感知到这是分层结构而不是一坨节点堆在一起。留白是被严重低估的设计元素。我见过太多图把节点挤得严严实实每个框之间只有几个像素的距离看起来像一块布料。好的做法是相邻节点之间至少留出等宽于 1/3 节点宽度的间距不同分组之间留出更大的空白。留白不是浪费它是在帮读者的眼睛做缓冲。3.2 连线的语义箭头不是随便画的箭头是 diagram-design 里最容易出错的地方。很多人从头到尾只用一种箭头语义完全混乱。实际上箭头至少有几种常见语义实线箭头数据流或控制流表示一个组件向另一个组件发起请求或传递数据。虚线箭头异步通知、回调、非强制依赖。无箭头直线静态关联、配置关系。双箭头双向依赖此时要警惕是否真的合理。我早期画图时不管什么关系都画一个实线三角箭头结果评审会上被架构师追问这个箭头到底是 HTTP 调用还是消息投递当场答不上来。后来我给自己定了一个规则每条连线都要能说清楚它代表什么并且同一张图里相同含义必须用相同的线型。还有一个细节是连线的走向。尽量让主线方向保持一致。如果主体流程是从左到右那就不要在中途突然出现一条从右到左的箭头除非它是明确的回环或异常分支。对于不可避免的交叉线我一般采取两种处理方式一是调整节点位置让交叉消失二是用跳线小圆弧表示交叉让读者知道这两条线没有实际连接。3.3 配色克制是第一原则配色是最容易看出一个图专不专业的地方。我在 diagram-design 里遵循一条铁律一张图里最多出现 3 个主色其余只能作为灰阶辅助。这 3 个主色通常承担不同职责比如一个主色用于核心组件一个主色用于辅助组件一个主色用于强调异常或重点。你可以用同色系的不同深浅来区分层级。例如整个架构图以蓝色为主色核心服务用深蓝填充接入层用浅蓝填充数据库层用中蓝再配一点橙色用来标出本次改造新增的节点。这样整张图既有统一感又有重点。我之前犯过一个典型错误所有组件都用一个颜色结果图是统一了但信息层级全没了。后来改为默认组件用白色底深灰边框核心组件用浅蓝底深蓝边框异常组件用浅红底红边框。这样读者扫一眼就能抓住重点。一个额外技巧是如果你要把图投到深色背景的会议室大屏不要直接用黑底白字导出而是调亮所有颜色否则后排根本看不清。3.4 图形元素与文字标注图形元素要少而精。我建议大家先建立一个图形词汇表矩形表示服务/模块圆角矩形表示外部系统菱形表示判断分支圆柱体表示存储人形图标表示用户角色。这个词汇表要全项目统一不要今天用矩形表示服务明天用圆形表示服务。文字标注我倾向于遵循三个原则。第一框内文字尽量不超过 8 个字能表达清楚职责即可。第二连接线上要加必要的关键词例如HTTP、异步回调、binlog 同步这些标签能极大降低阅读成本。第三字号要足够大我一般把最小字号设置在 9pt 以上如果字号小于 8pt 还放不下那就说明这个框承载了太多信息应该拆开。有一个常见的误区是总想用图标代替文字觉得画个数据库圆柱体就够了旁边不写任何标注。这种图看起来简洁但遇到英语不好的、业务背景不同的读者就会产生理解偏差。正确做法是图标为主、文字辅助图标表达形文字表达义。4. 实操过程从空白画布到可交付图理论讲完下面进入实操环节。我把自己画一张图的完整过程写出来从工具选型到最终交付每一步都拆开说方便直接照着做。4.1 工具选型没有万能工具只有合适工具先解决用什么画的问题。我这些年用过的工具不少各自定位差异很大工具优点缺点适用场景draw.iodiagrams.net免费、开箱即用、图库丰富界面略土通用架构图/流程图Figma协作实时、样式能力极强需要设计基础高质量方案配图Excalidraw手绘风格、上手极快不适合画严谨架构线上脑暴、快速记录Visio企业级、图形标准库全收费、协作弱传统企业交付Mermaid/Graphviz文本驱动、版本可控排版不够自由文档内嵌图、自动生成以我个人经验如果你只准备用一个工具首选 draw.io。理由很简单免费、不需要学设计、基本上什么图都能画而且它支持把源文件保存为 XML 文本可以直接放进 Git 仓库做版本管理。Figma 适合需要高度定制样式的场景比如给客户做售前材料、给高层做视觉汇报但它的学习曲线比 draw.io 长不少。至于 Visio除非你所在的公司有统一的交付规范否则我建议先用 draw.io 画内容最后再考虑是否要移植。4.2 动笔顺序先搭骨架再填细节很多人打开新画布就开始画第一个框然后一个接一个地连箭头这是完全错误的第一步。我的习惯是四步走。第一步先在画布边缘用文本框写下这张图的标题、版本号、创建日期。这不是为了形式而是防止后续修改时找不到对应版本。第二步画占位框架。把页面按布局规划分成几个大区域先用最淡的色块或辅助矩形把区域框出来。比如我画系统架构图时会先拉一个纵向的应用层区域再拉一个数据层区域然后在区域内放节点。这样做的优势是节点不至于画到画布之外。第三步按主流程把核心节点先用简单的矩形放上去只考虑位置不考虑样式。这个过程只关注逻辑关系是否完整。我经常在第一步和第三步之间反复调整顺序直到确认主链路顺畅。第四步才是调整样式、填充文字、设置配色。如果你跳过第二步直接画节点、连线大概率会出现画到一半发现画布不够放的问题。很多人这时候就会把整个图形拖来拖去越拖越乱。用占位框架至少能保证视觉上的整体感先存在。4.3 图层管理、对齐与间距当我画的图超过 20 个节点时图层管理就成了刚需。draw.io 里的分层功能虽然不够强但我有一个变通方案给不同分区的节点上不同的边框颜色并把同一个分区的节点用CtrlG放进同一个组。这样临时移动某个分区时组内相对位置不会变。对齐和间距我几乎全靠工具快捷键。在 draw.io 里选中多个节点使用排列功能里的水平均匀分布和垂直居中对齐可以一键把杂乱的节点变得整齐。别相信自己的鼠标手动目测对齐几乎总会差那么几个像素。间距方面我习惯设置统一的网格大小draw.io 默认网格吸附是打开的建议保持开启这样所有节点都会自动落到网格上导出后看起来特别整齐。分布式的图如果节点距离不统一视觉上会显得非常乱。我给自己的标准是同一层的节点间距尽量保持相等误差不超过 10 个像素。这个标准不用尺子量靠看着匀称基本就够了。4.4 导出与交付选对格式别让图毁在最后一步图设计得再好导出设置不对也会白费。我常用的导出格式有四种PNG最通用适合贴到文档、PPT 里。注意分辨率要设置到 2x 或 3x否则在 Retina 屏幕上会发虚。draw.io 导出时可以直接设置缩放比例我一般选 200% 或 300%。SVG矢量格式适合嵌入网页、再次编辑。缺点是部分在线文档系统不支持 SVG 上传需要预览确认。PDF适合打印、归档信息保真度高且可以被文字识别索引。XML源文件一定要保留这份它是你后续修改的底稿。很多同事向我抱怨上次那张图找不到了就是因为保存成了 PNG 后把源文件删了。我给自己定的交付规则是每一个交付出去的图必须同时给出 PNG 和源文件。如果是在线工具我会把源文件链接附在文档注释里。这样别人要修改的时候不需要对着 PNG 重画一遍。5. 常见问题与排查技巧实录画图这件事实操性很强很多问题不亲手踩一遍很难意识到。我把自己和周围同事最常遇到的 5 类问题整理出来附上排查思路遇到类似情况可以直接对号入座。5.1 图太空或太挤怎么调整图太空通常是因为信息量不足或者节点间距设得太大。我的建议是先检查是不是遗漏了关键层级。比如画架构图如果接入层只有 1 个节点应用层只有 1 个节点那这张图肯定不会饱满可以考虑把相关组件展开到二级细节。图太挤则相反往往是节点文字太多、信息层级不分明造成的。排查思路是把每个框里的核心词提取出来只保留不超过 8 个汉字把描述性文字移到连线标签或图例中。如果这样还是挤就考虑把一张图拆成两张一张总览图一张详细图。5.2 连线交叉太多怎么理顺交叉线是流程图和架构图的重灾区。我遇到交叉线时不会手动一根根去拖而是先重新审视布局方向。例如如果主体是从左到右的流程却被画成了既从上到下又从左到右的混合方向那大概率交叉在混合边界处。另一个实用技巧是重新给节点排座次。你可以在草稿纸上把节点名字按优先级列出来按照主线顺序重新排列节点而不是在画布上试图通过拉长连线来绕开交叉。主线节点放在同一行或同一列分支节点退到外层交叉率就会大幅下降。如果还有少量绕不开的交叉用跳线符号明确标注不要留两条线在视觉上交叠。5.3 颜色太多如何快速收敛配色失控几乎是所有新手必经的坑。我之前看某位同学的图一个模块用了 7 种颜色原因是每种颜色的边框代表一种协议。这里有一个快速收敛的方法把所有颜色先全部变成灰阶只保留一个强调色。具体操作是先选中所有图形把填充色设为白色、边框色设为深灰色然后对需要强调的核心节点涂上你选定的那个强调色比如深蓝。如果你觉得还要至少两种强调色那就控制在一个主强调色一个警示色以内。最后用图例说明每一种颜色的含义。这样做完整张图的色彩噪音立刻下降。5.4 导出图片模糊、字体丢失导出模糊基本都是分辨率设置问题。修订方案是优先导出 SVG如果必须要 PNG就设置缩放 200% 以上。字体丢失往往发生在跨平台打开时你的源文件里用了本机自带字体而对方电脑没有。最稳妥的办法是线条、形状尽量保持默认字体通常在 draw.io 里是 Helvetica 或 Arial除非万不得已不要用特殊字体。如果你发现导出后的图片里文字出现方框说明字体完全没嵌入到目标环境中。此时可以把所有文字转成路径draw.io 里没有一键转路径的功能但你可以选择导出为 PDF 再转成图片通常可以保留文字轮廓。最省心的方案还是统一用通用字体。5.5 后来者维护困难命名混乱这个问题很少被提起但实际影响非常大。一张图交付之后三个月后要改一个节点命名混乱的源文件会让维护人彻底崩溃。我自己的命名规范是每个节点必须用有意义的 ID而不是默认的默认节点名。比如order-service、payment-gateway、user-db。分组名也遵循group: engine-layer这样的格式。画布图层如果有分层名要体现逻辑比如背景、主流程、标注区而不是图层 1、图层 2。另外一个习惯是在源文件的第一页放一个图例说明小块写清楚这张图的适用读者、核心主题、改动历史和当前版本。这样后来者打开时能在 10 秒内知道这张图在讲什么而不是对着节点一个个猜。最后再分享一个小技巧这也是我踩过不少坑之后总结出来的每次画完图不要立刻交付先把它放到缩小到合适大小状态下看一眼。具体做法是把画布缩放到 50% 左右模拟读者在屏幕上或纸上的阅读状态。如果在这个缩放级别下文字还能看清、连线没有乱缠、重点颜色一眼能定位那这张图的 diagram-design 基本就过关了。如果是自己画了太久已经看不出问题那就发给一个完全不了解背景的同事让他花 30 秒描述这张图讲了什么。对方能说出来说明图真的会说话如果他说不出来问题通常不在于他的理解能力而在图本身——回去重新调整布局和信息层级比继续在原图上修补要省时间得多。