你有没有这种经历打开一个项目的文档目录里面躺着几十张图——架构图、流程图、数据流图、时序图东一张西一张。风格大概是“每个人都有自己的想法”有人用黑色线框有人用蓝绿渐变有人把字号调到 18px 把细节塞到 3px。更麻烦的是过两个月回去看连自己都看不懂当初想表达什么。这个标题 diagram-design 看着像个代码项目名其实它是在提醒我一件事图表设计不能靠“顺手画一下”它需要当成一个正经的设计环节来对待。我最早做图也属于“能用就行”派直到某次评审被问到一个箭头指向的含义我盯着图看了半天才想起来那是“异步回调”——那一刻我就知道必须有意识地建立一套规范和方法论。这篇文章就是把我在 diagram-design 这条路上踩过的坑、试过的方案和沉淀下来的做法完整梳理一遍分享给需要画架构图、流程图、方案图、数据图的人。1. 图表设计一件小事里的系统工程1.1 图的本质是信息传递不是装饰先说一个我反复强调的观点图表的第一属性是信息传递不是审美展示。一张好的图读者扫一眼就应该能抓住“谁在跟谁交互、流程往哪里走、系统有哪几个组成部分”。但绝大多数图画不好不是工具不行而是画图的人没有想清楚“这张图要回答什么问题”。我拆解图表需求的时候一定会先问三个问题这张图的读者是谁是研发团队、业务方还是决策层读者需要在 10 秒内得到的信息是什么这张图会被用来讨论、交接还是存档答案不同图的设计思路就完全不同。给研发看组件调用关系重点在接口和端口给业务方看订单流程重点在状态节点和分支条件给决策层看系统容量重点在数据指标和瓶颈位置。很多人一上来就开画布从头到尾把所有细节铺满结果就是“信息很全但等于没说”。图表设计的本质是取舍。你要把最重要的信息放在视觉中心把次要信息放到边界或者干脆折叠成子图。这在信息设计里叫“层级”听起来玄乎做起来也简单先确认主题节点再确认直接相关节点最后才是周边环境。谁跟主题关系越近谁就应该离得越近、画得越清楚。1.2 三条技术路线的选型考量diagram-design 从一开始就绕不开一个问题用什么画我的经验是不存在“最好”的工具只有“适合当前场景”的路线。整体上分三类路线优点缺点适合场景手动绘制桌面绘图软件/在线白板布局自由、上手快、能精确微调维护成本高、风格一致性靠自觉复杂架构图、方案设计、评审草图代码驱动脚本/文本转图可版本化、可复用、易批量生成复杂布局调整费劲、学习成本高自动化报表、数据可视化、流水线图混合路线兼顾两者优点按图类型选择需要维护两套流程实际项目中最推荐我现在的做法是混合路线。网络拓扑图、系统架构图这种需要精心设计布局的用手动绘制工具做数据集市、定时任务依赖这一类结构固定、变化频繁的用代码驱动生成。这样既保证关键图表的质感又不会在维护性上失控。选型的时候还有一个容易忽略的点导出格式。如果你的图要进技术文档、PPT、Wiki务必确认工具支持 SVG 矢量导出并且能自定义画布尺寸。位图导出虽然方便但跨页放大的时候很容易糊。后面实操章节我会展开讲导出细节。1.3 图型选择先定骨架再画细节很多图不好看是因为“骨架”选错了。把架构图画成流程图把流程图画成思维导图信息自然拧巴。我在选图型时遵循一套很朴素的判断逻辑如果内容有清晰的层级关系用树形结构或分层架构图如果内容是状态流转或者决策分支用流程图如果内容是多个系统之间的调用关系用依赖图或数据流图如果内容强调时间顺序用时序图或甘特图如果内容要展示比例、趋势、分布再用柱状图、饼图、折线图这些统计图表。这里特别想提醒一句饼图真的被滥用了。超过五个分项就不要用饼图人的眼睛很难比较相近角度的扇形面积。这种时候用条形图排序信息传达效率高得多。图型选择直接决定了图的基本骨架。骨架对了剩下的填色、连线、加框才不会白费功夫。2. 核心规范拆解这些细节决定了图的专业度2.1 画布、网格与间距让所有元素都有“位置感”我见过太多图显得“散”不是因为内容不对而是元素摆放没有规律。所有元素想放哪放哪就会显得杂乱。解决这个问题我靠的是网格系统。网格听上去是平面设计领域的概念但画架构图、流程图同样适用。我现在统一用 8px 作为基准网格节点之间的距离、元素的内边距、分组的留白都是 8 的整数倍。间距最小 8px亲密元素用 8px相关元素组内用 16px组之间用 24px 到 32px。这样整个画布上的元素会有一种内在的节奏感。具体操作时我在新建画布会先设置网格对齐选项开启“对齐到网格”然后手动把网格尺寸调成 8px。很多人忽略这一步直接靠鼠标拖动对齐结果两个框之间差了 2px、5px、7px看着就觉得“别扭”却又说不出哪里不对。网格对齐之后这种感觉会立刻消失。画布尺寸也是要注意的点。不要无限扩展画布画的图越大越难聚焦。我常用的规则是单张图的画布控制在 1600px 宽度以内如果用在线画布物理尺寸控制在 A3 横版以内超过这个范围就考虑拆分。一张图如果信息量大到一屏装不下读者就会迷失方向不如拆成“总览图子模块图”的结构。2.2 配色方案少即是多颜色都有语义配色是图表设计里最容易失控的地方。明明用的是同一个绘图工具有人画出来清爽有人画出来像霓虹灯差别就在于是否控制了颜色数量。我给自己定的规矩是“一主二辅三中性外加语义色”。具体来说主色1 个用于核心主题、主要容器边框、主流程线我常用深蓝色系辅助色2 个用于次要模块和高亮标注通常选相邻色系或对比色系各一个中性色3 个黑白灰用于背景、普通文本、次要边框语义色固定含义红色代表异常橙色代表警告绿色代表成功蓝色代表进行中。这条规则的底层逻辑是颜色只有在被赋予稳定含义时才有价值。如果同一张图里蓝色一会儿表示“主流程”一会儿表示“外部系统”读者就得反复对照图例认知负担直线上升。关于对比度我强烈建议重视。颜色是用来区分信息的不是用来考验视力的。正文文字和背景之间的对比度至少达到无障碍标准的 AA 级对比度不小于 4.5:1浅灰字配白底这种组合我基本不用截图上墙之后根本看不清。这里分享一个我在调色板上反复验证过的经验用颜色表达状态时不要只靠色相区分还要配合形状或文案。比如异常节点除了红框再加一个叹号图标主流程线除了用主色加粗还可以在线上加箭头。因为色弱人群对红绿区分可能有障碍多一层编码信息就多一层保障。2.3 字体与文字层级让文字跑不过视觉引导很多图表工具默认字体是 Arial 或者 Helvetica但在中文场景下字体匹配往往被忽视。系统会默认渲染但跨平台打开时经常出现替换导致字号、字距全部走样。我在 diagram-design 规范里明确规定标题用非衬线中文字体如系统默认无衬线体代码、类名、接口名等标识符用等宽字体注释和脚注用更小一号的文字。字体数量不超过 2 个否则版面会显得杂乱。字号层级我也做了固定层级用途参考字号画布 100% 缩放图标题整张图的名字放画布左上角或顶部居中18px加粗节点标题模块名、系统名容器内部顶部14px加粗正文标签属性、接口名、状态名12px注释/图例说明文字、来源标注10px灰色这个层级不一定死板但比例关系要保持。很多图的问题是层级拉不开所有文字都是一个大小看起来就像“一张大饼上撒满了芝麻”。层级拉开之后读者会自然先看图标题再看节点标题需要时再看注释这个顺序才是健康的阅读流。2.4 线型与箭头每一条线都要有“含义”线比框更容易被忽略但也更容易让人困惑。我拆解过别人画的烂图问题往往不是框画错了而是线表达不清实线虚线混用没有规律箭头形状随机线宽忽粗忽细。我的线型规范是边框线1.5px用于容器和节点边界表达“这是一个独立个体”关系线1px用于连接节点表达“两者有联系”强调线2px用于主路径、核心链路表达“这是最关键的走向”虚线表达非确定性关系如异步通知、可选分支、未来规划。箭头形状也要有语义。实心三角箭头表示“方向”适合流程和调用。空心箭头表示“继承/泛化”在类图里常见。圆点箭头表示“聚合”关系在数据模型里用得多。很多工具默认的箭头样式只有一种我习惯把常用的两三种提前存进组件库用的时候按语义选而不是随手画。关于线的走向我还有一个很实用的原则“线要尽量直走水平或垂直方向拐弯不要超过两次。”斜线虽然看着活泼但会在视觉上干扰信息流。尤其是多条线交叉的时候要么调整布局让交叉减少要么在交叉点加跳线圆弧否则读者的视线很容易被“打断”。2.5 组件与图层命名看不到的地方也需要秩序diagram-design 的规范里命名和图层管理是我后来补上的但却是收益最大的部分。一张图如果组件多了不命名、不分层后续修改时找元素要花大量时间。我引导自己用的命名规则包含三部分类型前缀、含义、序号。例如box-main-auth-service主域认证服务容器arrow-call-payment-timeout调用支付超时的连线text-note-01第一处注释。这样的命名在工具图层面板里一目了然谁是什么、属于哪一层不需要点进去猜。同时我习惯把图层分成固定五层从底到顶依次是背景层、容器层、内容层、关系线层、标注层。所有框和容器放背景层和容器层文字图标放内容层连线放关系线层图例和说明放标注层。这个分层习惯在调整颜色、隐藏背景、导出不同版本时特别好用。比如我导出“纯黑白打印版”时直接在标注层加一个统一说明再把颜色全部改为中性色3 分钟搞定。没有分层的话这种需求能让人改到怀疑人生。3. 实操流程从需求到一张合格图表3.1 需求拆解从“一句话”到图结构正常情况下需求方不会给你一份清晰的结构化说明书他只会说“把系统架构画出来”“把下单流程画出来”。这时候最重要的一步不是开画布而是先在脑子里或者草稿纸上把图的结构拆出来。我拆解的方式很简单先提取名词再提取动词最后归类关联。举个例子某个鉴权模块的需求是“用户登录后认证服务校验凭证通过后调用用户服务加载资料同时记录审计日志”。我从这句话里提取到的元素包括用户外部角色、认证服务、用户服务、审计日志模块、校验凭证动作、调用用户服务依赖、记录日志副流程。接下来就是归类用户画在最左侧或最顶端作为触发方认证服务是核心放中间用户服务和审计日志是被调用方放右侧或下方。这样一归类图的结构雏形就出来了。接下来画框、连线、加箭头只是把它们可视化的过程。我把这个步骤叫作“先列元素再画关系”。很多人直接跳到连线边画边想结果画到一半发现漏了一个关键模块又要挪位置整个版面被打乱。提前拆结构能省一多半返工时间。3.2 先布局再连线一次到位的摆放方法布局是决定图是否好读的关键。我在图里摆放元素遵循的主线是“读图方向”。中文环境下我的读图顺序默认是“从左到右从上到下”。主流程放在中间横向主线分支放下方或右侧辅助内容放左下角或右上角注释放底部。具体步骤大概是这样确定中心节点或起点节点放在画布水平中线左侧三分之一的位置按照主流程顺序依次向右排列核心节点保持纵向居中分支节点沿主流程节点的上下两侧展开展开方向统一要么向下要么向右所有节点先不做连线先用矩形占位调整对齐和间距确认布局顺眼后再添加关系线。先布局再连线的好处是你可以专注于“元素之间的相对位置”避免被箭头牵着走。连线阶段发现交叉过多怎么办我的经验是调整一侧节点的垂直位置而不是硬塞。如果交叉实在无法避免可以用一条横向的“桥”线跨越另一条线同时在线交叉处保留足够间距。还有一个小细节在对齐元素时不要用肉眼靠“差不多对齐”一定要用分布对齐功能。把所有节点的左边缘对齐到同一条垂直线或者把中心点水平居中。工具里的对齐功能通常快捷键就能触发用熟之后效率提升很明显。3.3 标注与上下文让图可以“独立阅读”一张合格的图应该能脱离讲解独立阅读。评审会上最尴尬的场景就是“这个框是啥意思”“哦我忘了标这是消息队列的消费端。”——信息缺失就是图的不合格。我在每张图里都会固定加这几样东西图标题位于画布左上角写明图的主题和类型图例位于右下角说明主要颜色、线型、箭头的含义版本信息和日期位于左下角标注 V1.2、2025-01-15 这类信息关键假设或边界如果图里省略了某些细节用一行灰色小字注明“本图仅涵盖核心链路未包含异常分支”。这些标注看起来琐碎但它们决定了图能不能成为团队协作里的“长期资产”。有日期和版本别人改图时才知道基于哪个版本改有图例新人才能快速理解画风有边界说明才不会有人追问“为什么没有 XX 模块”。3.4 建立自己的模板库把重复劳动降到最低一旦规范定下来我强烈建议把它沉淀成模板。我现在的做法是在绘图工具里建立一套名为“diagram-design-base”的模板文件里面包含常用的组件、样式和图层结构。模板包含的内容大致有基础组件默认矩形框、圆角框、容器、泳道、图标占位符箭头样式实心方向箭头、继承箭头、聚合圆点箭头、虚线箭头预设配色主色、辅助色、语义色直接应用样式文字样式标题、节点标题、标签、注释每种字号和颜色都配好常用图型模板架构图模板、时序图模板、部署图模板、流程图模板。有了模板之后画一张新图的时间可以压缩到原来的三分之一。更重要的是团队协作时大家都从同一套模板开始风格一致性就有了保障不用靠“互相模仿”。这一点对于多人维护同一套文档的场景尤其重要。3.5 导出与交付细节决定专业感图是画完了但交付出去才算真正完成。我在这里栽过不少跟头重点说说导出环节。技术文档里的图优先导出 SVG 矢量格式。SVG 放多大都不糊还能在网页里被检索到文本内容。其次考虑 PDF 矢量格式适合打印或放进离线文档。如果只能用位图那就导出 PNG并且选择 2 倍分辨率比如实际展示宽度 800px导出 1600px这样即使是放到幻灯片的宽屏页面里也不会出现锯齿。字体问题在导出时也容易踩坑。很多工具导出 SVG 时会把文字转成路径或者引用本机字体。前者安全但会导致后期无法编辑文字后者在别人电脑上打开时字体可能缺失导致自动替换、错位。我的做法是在最终交付前用查看器打开导出的 SVG 检查一遍特别是中文文本是否正常显示。还有一个容易被忽略的点画布留白。导出时四周要留出统一的白边不要贴着元素边缘裁切。否则在文档排版时标题和正文会紧贴着图视觉上非常拥挤。通常我会在画布四周留出 40px 到 60px 的白边再导出。4. 常见问题与排查经验4.1 图一放大就糊原因多半是导出格式不对“这个图怎么放大就糊了”是出现频率最高的抱怨。排查思路很简单先看原始文件是矢量还是位图。如果是位图PNG/JPG放大必然糊这是物理规律只能重新用矢量格式导出。如果是 SVG 导出后糊问题可能出在两个地方。一是查看器不支持 SVG 里的某些属性自动降级成了位图渲染二是 SVG 里嵌入了特殊字体查看器字体缺失后重新排版导致变形。这种时候我会把字体转为轮廓再导出或者直接改在工具里把字体统一为最常见的无衬线体。4.2 配色花得像霓虹灯回到“一主二辅”规则有一次我帮某位同学改图这里就叫 A 同学吧打开他的画布满屏红橙黄绿青蓝紫每个节点颜色都不一样。他告诉我他是“为了让每个模块都突出”。实际上所有模块都突出就等于没有重点。解决思路就是强行降色。保留最深最饱和的主色给核心模块辅助色给相邻层其余全部改成中性灰。改完以后A 同学自己都愣了“没想到图还能这么干净。”重点从来不是画得多鲜艳而是视线落在哪里。4.3 信息过载图密得看不清图一旦信息过密就失去了“快速理解”的功能。我排查这类问题的思路是检查节点数量。一张图超过 15 个主要节点就考虑拆分检查交叉线数量。关系线交叉超过 5 处重新布局检查文字密度。一个节点内超过 3 行描述把细节放到备注里。拆分是主要手段。我会把“系统总览图”拆成“上层总览子模块详图”在主图上用容器框标出子模块位置然后在子图里展开细节。这样每张图的负担都小很多读者也能按需“下钻”。4.4 团队协作风格撕裂统一模板和组件库团队协作的图最怕的就是五个人五种画风。一个人喜欢圆角一个人喜欢直角一个人箭头用实线一个人用虚线。最终放在同一篇文档里观感非常割裂。要根治这个问题靠口头约定是不够的必须从组件库和模板层面统一。基本做法是确定一套样式文件其中包含颜色变量、字号、线宽、箭头样式、间距规则所有人在作图时只能从这套样式里取用。如果需要的工具不支持样式链接那就用“导入模板”的方式新建文件时统一从 DIAGRAM-BASE 模板开始。我在实际协作中还发现命名约定的统一同样重要。组件不命名改起来找不到对象文件不命名整理时根本分不清哪个是最新版。我给文件定的命名规则是项目名-图类型-主题-V版本号-日期例如user-center-architecture-core-domain-v1.2-20250401。4.5 返工频繁需求变化后怎么改图才不崩溃需求一改图就重画这是很多人对画图这件事的阴影来源。说句实话需求变化不可避免但我们可以让图的“抗变能力”更强。我的做法是在画图时保持结构清晰而不是把一切元素钉死。具体技巧用容器框组而不是零散节点来组织模块这样模块内调整不用挪动全局多用样式模板而不是手动调格式改一处样式全组同步连接线尽量从容器边缘连而不是从某个文字标签连这样移动容器时线会跟着走每次交付前保存一个“基线版本”下一次改图前先对比差异避免改坏后无从回滚。4.6 问题排查速查表问题现象可能原因推荐处理放大模糊位图导出改用 SVG 或 2x PNG颜色刺眼颜色数量失控收敛到一主两辅中性灰图太密看不清节点/连线过多拆分总览子图团队画风不统一缺乏规范模板统一组件库和命名规则中文乱码字体缺失导入时嵌入字体或转轮廓改图崩溃结构不清晰用容器组织基线版本管理5. 一些容易忽略的细节和小经验5.1 深色背景图的适配如果你的图要放到 PPT 的深色模板里不要直接丢一张白底图上去会非常刺眼。两个选择要么导出透明背景 PNG要么画一个深色画布版本。我通常不做两版而是画一个“同一份结构、两套配色变量”的模板深色和浅色各一套。这样切换成本很低也方便后续复用。5.2 截图时的像素密度图完成后很多时候要用截图软件截取局部放到群里讨论。电脑屏幕分辨率是 100% 时截图还行但如果外接显示器缩放比例是 150%截出来的图会比实际大一圈。为了方便对方查看我会在截图前临时把缩放调到 100%截完再调回来。这个细节很多人忽略但真的很影响阅读体验。5.3 比例尺别让“示意图”误导理解架构图、流程图这类图本质上是示意性的不是真实比例。但有些人在画部署拓扑时习惯把某个节点的框画得特别大另一些节点的框画得特别小。这种“无意义的大小对比”会误导读者让人误以为某些模块更重要或更庞大。我的建议是在示意图里所有同级节点的尺寸尽量一致如果确实有“大模块包含小模块”的层级用容器表达包含关系不要用大小暗示。5.4 定期复盘自己的旧图最后分享一个我坚持了很久的习惯每隔一两个月翻出自己两三个月前画的图用现在的规范重新审视。几乎每一次我都能发现至少一处不合理的地方——要么颜色违反语义要么箭头含义不明要么布局可以更清晰。这个过程有点“打脸”但确实是我 diagram-design 水平提升最快的途径。旧图就是我最好的老师。图表设计这件事靠的从来不是天赋而是把每个细节都定成规则、把每个规则都落地成模板、把每个模板都复用到下一张图里的耐心。等这一整套跑顺了你会发现画图不再是苦差事反而变成了一种很快的表达工具。
