1. 为什么图表需要设计——从"能看懂"到"一眼看懂"
diagram-design 这个话题，是我过去大半年反复折腾的东西。你可能觉得图表嘛，不就是画几个框、连几条线？一开始我也是这么想的，直到被一份根本看不懂的架构图坑了一整晚，我才认真研究起"设计"这两个字的分量。所谓 diagram-design，简单说就是一组关于图表怎么分类、怎么构图、怎么配色、怎么排布信息的方法论，最终目标是让复杂逻辑在最短时间内被别人读明白。这篇文章不聊花里胡哨的视觉效果，就讲我在实际项目里总结出来的选型逻辑、绘制步骤和排坑经验，适合写技术方案、做架构设计文档、写教学材料、给学生讲知识点的朋友参考。
我最初接触 diagram-design，是因为要给一个内部系统补设计文档。当时上一任留下的架构图是用画图类软件徒手画的，节点大小不一、颜色深浅一块一块的，箭头的指向还靠猜。我花了三个小时才勉强理顺模块关系，又花了一个小时重新画了人生第一张"能看的图"。那一刻我就意识到：图表的真正成本从来不是"画出来"，而是"让人读得懂"。一张设计混乱的图，轻则浪费同事的时间，重则让整个方案被误读，最后线上出问题。
后来我把图表设计的经验整理成了一套可复用的流程：先判断信息类型，再确定图表结构，接着定版式、配色和标注规范，最后输出并评审。这套流程帮我节省了大量反复修改的时间，也让团队里新同学交上来的图终于在同一套语言下工作。diagram-design 解决的不是"好不好看"的问题，而是"信息传达效率"的问题。它本质上是一门信息设计的分支学科，只是恰好通过图形的方式呈现而已。
整篇文章会围绕四个核心问题展开：这张图到底要表达什么？用哪种结构表达最省力？怎么排布才能让人三秒抓住重点？出了问题时怎么快速定位和修复？后面每个章节都会给出可落地的判断标准和操作步骤，而不是空谈"注意美观"这种正确的废话。如果你也想让自己的架构图、流程图、关系图从"咱们凑合着看"变成"一眼就能进脑子"，这篇内容应该能给你一些参考。
2. 先想清楚再动手：图表选型与结构设计
2.1 信息的五种基本形态
我见过太多人画图的第一个错误，就是直接打开绘图工具开始拖拽。真正高效的流程是先问一句：我要承载的信息，在本质上属于哪种形态？
绝大多数技术图、教学图、管理图，都逃不出五种形态。第一种是流程，核心是步骤、顺序和分支，典型如业务流程图、审批流、操作流程。第二种是结构，核心是包含、嵌套、上下级关系，典型如目录树、组织结构图、模块层次图。第三种是关系，核心是节点之间的连接与亲疏，典型如网络拓扑图、ER 图、依赖关系图。第四种是时序，核心是时间上的前后顺序和交互，典型如时序图、甘特图、状态流转图。第五种是状态，核心是有限状态之间的迁移条件和触发动作。
有朋友问我：我画的图里既有流程又有关系，怎么归类？我的回答是：不要试图把两种形态硬塞进一张图。diagram-design 里很重要的一条原则是单图单主题。如果既要表达步骤又要表达模块依赖，优先拆成两张图，再通过编号或引用互相跳转。一张图能承载的信息密度是有限的，读者一下要消化两种结构，读图成本会急剧上升。我踩过最大的坑就是把业务流程和系统依赖画在一起，结果每一层都要解释半天。
2.2 选型决策表：照着套就行
为了方便选择，我整理了一张极简的决策表，每次画图之前对照着选结构，基本不会跑偏。
| 信息形态 | 典型问题 | 推荐图型 | 关键注意点 |
|---|---|---|---|
| 流程 | "处理这个请求要经过哪些步骤？" | 流程图、泳道图 | 明确开始和结束节点，分支需要标明条件 |
| 结构 | "系统包含哪些模块？" | 树形图、分区图 | 层级统一，避免跨层连线 |
| 关系 | "哪些服务互相依赖？" | 拓扑图、ER 图、网络图 | 连线语义要一致，标注关系类型 |
| 时序 | "先后发生了什么交互？" | 时序图、甘特图 | 垂直方向严格代表时间 |
| 状态 | "订单可以处于哪些状态？" | 状态图 | 不遗漏非法迁移与异常分支 |
这个表看起来简单，但真正用起来能少走许多弯路。我以前画"订单处理流程"这种图时，总喜欢把所有模块都塞进去，结果画到一半发现既有状态判断又有流程步骤，自己都理不清。后来对照表格，把状态判断抽出来单独画一张状态图，主流程只留下步骤和分支，整个图立刻清爽了。
还有一个容易忽略的细节是"读者是谁"。给架构评审用的图，侧重点在模块边界和依赖；给新员工培训用的图，侧重点在主线流程和关键路径。同一种图型在不同场景下要保留的信息完全不同。我通常会在动手之前先写一句话定义这张图的目标，比如"这张图用来展示下单到支付完成的主链路，读者是刚入职的研发"。这句话写下来之后，后面所有取舍都有了依据。
3. 设计原则：好读永远排在好看前面
3.1 网格与对齐：图也怕歪
很多手画的图之所以显得乱，最大的原因不是配色，而是对齐。节点之间的间距忽大忽小，同一层级的框高低不一，连接线歪歪扭扭穿过文字，这些都会让读者下意识认为内容也不严谨。
我的做法是引入一个参考网格，所有节点都落在网格线上。具体来说，我会以 8 或 10 像素为最小单位，每个节点的位置、高度、宽度都取这个单位的整数倍，节点之间的间距同样保持统一。这个做法很像前端开发里的栅格系统，核心思想是让视觉节奏规律化。读者看的时候即使注意不到网格本身，也会觉得图很"稳"。
对齐这件事在自动布局工具里是默认的，但手动调整时最容易出错。我见过的典型问题是：某个节点下移了 5 像素，整条链路上的其他节点都要跟着移动，最后所有连线都变成了折线。这个问题的根治办法只有一个——在最早摆位置时就把网格吸附打开，并且一次性精确放置，不要后续微调局部节点。
在这里也提醒一句：文字是图表的组成部分，不是额外的装饰。所有节点内的文字都要做对齐处理，通常建议左上对齐或居中对齐，同一张图里统一风格。节点内同时有编号和名称时，要给编号一个固定位置，不要让它们四处乱跑。
3.2 颜色语义化：少即是多
颜色在图表里最大的价值是传递含义，而不是装饰。最典型的做法是语义色彩：正常路径用冷色，异常路径用暖色，需要强调的新模块用唯一高亮色，其余全部保持低饱和中性色。
我通常在单张图里控制主色不超过 3 种，辅助色不超过 2 种。超过这个数量，读者就开始"找颜色代表什么"，而不是"看内容是什么"。另外还要考虑灰度打印和色弱读者，所以关键信息不能只靠颜色区分，必须配套文字标注或线型差异。
我自己的默认色板是这样的：背景用浅灰或纯白，主体节点用同一色相的浅色填充，连接线用深灰或中蓝色，异常路径用橙红色，重点标记用蓝色加粗边框。这个组合在绝大多数屏幕和打印环境下都能保持可读性。如果你对颜色不敏感，直接使用软件预设的"色盲安全"色板也能达到八成效果。
3.3 连接线规则：箭头方向就是阅读路径
连接线是图表里最容易被忽略、也最影响理解的部分。diagram-design 里我对线条有三条硬要求。
第一，箭头必须明确。能画方向的一定要画方向，不要只画一条线让读者自行揣摩。箭头是阅读路径，图上每一条箭头的起点和终点都代表一次信息流动。第二，优先使用正交线。直角折线比斜线更容易追踪，也比曲线更符合技术图的严谨气质。如果一张图全是斜切线，读者视线会被中途打断。第三，减少交叉。两条线交叉一次可以容忍，但如果交叉超过两三次，就必须调整节点布局或增加"跳线"标记。
线的粗细也有讲究。主干线可以用 2 像素或 1.5 像素，二级关系用 1 像素。线宽不同能明显拉开层次，但同一层级内部必须保持一致的线宽。我现在画图时，甚至会让辅助线的透明度降到 60%，这样阅读时的注意力会自动落在线条更实的主干上。
3.4 层次结构：让眼睛有地方落
一张图应该像一篇文章一样有标题、有段落、有强调。如果没有层次，所有信息平铺在一个平面上，读者找不到阅读起点。
构建图表层次主要靠三个手段：尺寸、深浅和分组。尺寸用于区分主场景和子场景，核心模块可以用更大的方框包裹起来；深浅用于制造远近感，背景层用浅灰，内容层用白底，强调层用带色边框；分组则用带标题的容器或泳道，把属于同一域的内容框在一起。
实际操作中，我还有一个笨办法很管用：把图缩小到缩略图尺寸看一眼。如果缩得很小之后仍然能一眼看出"哪里是主流程、哪里是辅助信息"，那层次就是合格的。如果缩略图里全部糊成一团，说明层次做得不到位，需要继续调整。这个检查步骤我每次输出前必做，比任何规范都管用。
4. 工具选型与落地流程：把 diagram-design 变成日常习惯
4.1 工具选型的三个标准
工具会极大地影响设计习惯，所以选型不建议只看哪个画出来漂亮，还要看它能否支撑上面的设计原则。我选图表工具只看三个标准：文本化程度、协作便利度、导出质量。
文本化程度意味着图可以被代码库管理、被 diff、被自动生成。只要图的核心结构可以通过文本描述，修改起来就是改几行文字，而不是在画布上挪来挪去。协作便利度解决的是"多人同时编辑"的场景，如果团队里多人要贡献各自的模块，工具必须支持实时协同或清晰的分工边界。导出质量则决定图能不能直接进入文档和汇报现场，矢量导出几乎是必需品，位图导出至少要到 2 倍分辨率和透明背景。
这三条标准放在一起，你会发现某些好看的白板工具其实只适合画临时草图，不适合当正式的 diagram-design 载体。因为它们的画布虽然自由，但大家对同一张图的"共同语义"很难沉淀下来。草图可以自由，正式图必须可控。
4.2 从草稿到成图的五步流程
我把 diagram-design 的实操流程固定成了五步，每一步都不难，但合在一起能保证质量稳定。
第一步是写一段话，把图的主题、读者、核心信息点描述清楚。这段文字是整张图的"需求文档"。第二步是列出图上的所有节点和关系，用清单的方式写下来，比如"节点 A，负责人；节点 B，状态存储；A 调用 B"。这个清单能帮你发现漏掉的节点。第三步是画骨架，只摆方框和粗箭头，不处理配色和细节，重点是验证结构是否顺。第四步是细化，逐项加上文字、颜色、线型、分组，把草稿变成成品。第五步是评审，把自己当成第一次读到这张图的人，用前面提到的缩略图法、口头讲解法检查一遍。
这五步里最容易跳过的就是第二步。我见过一位同事，上来直接画，画到一半发现需要加个缓存节点，结果整条链路的布局全乱了，前后返工了一个下午。如果你先列清单，所有节点和关系在动手前就齐了，后面基本不会出现"推倒重画"级别的返工。
4.3 一套可以直接抄的默认参数
为了不让自己每次画图都纠结设置，我总结了一套默认参数，分享出来供参考。节点圆角用 4 到 6 像素；默认字体用无衬线字体，字号在 11 到 14 之间；节点间距最小 16 像素，分组间距最小 24 像素；连接线默认 1.5 像素，主干线可加粗到 2 像素。页边距保持至少 20 像素，避免导出后内容被裁切。
如果使用文本化的绘图脚本，我会把节点定义、连线定义、分组信息拆开维护。核心节点用短名称，对外显示的中文名在属性里写明。这样改结构时只需要调整短名称的位置，不会动到显示文案。以下是示意：
定义节点: 节点A: "请求入口" 节点B: "业务校验" 节点C: "数据存储" 定义连线: 节点A -> 节点B: 参数校验 节点B -> 节点C: 落库 定义分组: 组1: "接入层" 包含 节点A 组2: "服务层" 包含 节点B 组3: "存储层" 包含 节点C这种纯文本结构的好处在于，它可以被放入版本管理仓库，每次修改都能看到精确的 diff，不会因为某个人拖了一下节点导致整张图对不上。对协作团队来说，这种确定性比自由画布珍贵得多。
4.4 版本管理与评审清单
图表进了团队协作流程，最大的痛点就是版本混乱。随手改一版、另存为"图_final_v3"这种操作，几乎一定会带来同步问题。我的经验是：正式图使用文本描述作为唯一事实源，构建生成的图片产物只作为发布物，不进源码管理磁盘。
评审环节我也整理了一张清单：主题是否单一、层级是否清晰、箭头方向是否统一、颜色是否语义化、缩略图是否可读、关键名词是否拼写一致、是否标注了版本和日期。每条都只是"是/否"的判断，评审时过一遍大概五分钟。新成员参与协作时，拿着这张清单也能快速给出有效的审查反馈，而不是凭感觉说"图有点乱"。
5. 常见问题与排查技巧实录
5.1 图太乱、信息过载怎么办
figure 太乱是最高频的问题，症状是节点多、连线密、颜色杂，缩略图看过去一团黑线。排查时先数一数节点数：如果超过 20 个，大概率已经超了单图容量。解决方法是拆分而不是压缩。
我常用"中心扩散拆分法"：先找出主流程，把主流程的图保留；然后逐个把附属分支抽离成子图，用编号标注入口和出口。比如"支付"这张大图拆成"支付主流程""支付回调状态机""对账分支"三张图后，每张都能独立阅读。父图放在文档首页，子图作为附录，阅读体验会好很多。
5.2 箭头方向和线型不统一
另一类高发问题是箭头方向混乱。同一个动作有时候从 A 指向 B，有时候从 B 指向 A，读者分不清调用方和被调用方。根治办法是统一图例：在图上用注释或者图例区明确标注"实线箭头代表请求方向，虚线箭头代表回调方向，无箭头线只代表关联关系"。
如果你使用的是文本化脚本，可以做一个非常简单的检查：在全文中搜索"<->"和"->"，把双向关系单独列出来，确认它是不是真的需要双向箭头。很多时候的双向箭头其实只是"我懒得细分方向"的偷懒写法，细化之后都能改成单一方向。
5.3 导出模糊、尺寸不对、文字被截断
导出问题最影响实际交付。解决方案是优先选择 SVG、PDF 这类矢量格式；如果只能导出 PNG，就把分辨率设置成 2 倍以上，导出纸张尺寸选 A3 或更大。导出后立刻放大到 200% 检查边角文字，看是否出现模糊或裁切。
还有一个隐蔽问题：字体未嵌入。同一张图在不同人电脑上打开，字体缺失会自动替换，导致文字变宽、节点框挤出变形。所以只要跨机器传递，就要把字体处理成嵌入或路径。文本化工具没有这个问题，因为渲染是在查看端统一完成的，这也是我在团队里推动文本化方案的原因之一。
5.4 协作中颜色越改越乱
多人协作时，经常出现一人用蓝、一人用红、一人用黄，最后变成彩虹图。这是因为大家没有共用主题。我的做法是在项目根目录维护一个 color theme 文件，明确规定主色、辅助色、警示色的色值。在文本绘图脚本里，通过变量引用颜色，这样全局替换配色时只改一处即可。
如果团队已经乱到无法收拾，一个更干脆的办法是彻底清空颜色，全部先画成黑白的。黑白图确定结构没问题后，再按照语义一次性填充颜色。结构问题不应该被颜色掩盖，先黑白后上色，能逼着你把逻辑理清楚。
6. 我后来把 diagram-design 沉淀成了什么
这套方法用熟之后，我最大的改变是：不再把画图当成一件凭感觉做的事。每次拿到新内容，我第一反应先定位形态、定读者、定单图主题，然后才会打开工具。整套流程跑下来，一张中等复杂的架构图从构思到成稿，通常能控制在四十分钟以内，而且基本不需要大改。
后来我又在团队里建了一个很小的图表规范库，把色板、字体、间距、线型这些参数沉淀成模板。新同事上手画图时，不用重新发明轮子，直接用模板创建就行。规范库的好处是让"设计"这件事从个人经验变成团队资产。
如果你也经常被各种图困扰，我的建议是从最小的一步开始：下一次需要画图时，先不着急打开画布，先用半分钟写一句话说清楚这张图给谁看、想表达什么。只要坚持这个习惯，后续所有步骤都会顺很多。diagram-design 不是艺术创作，它是一项可以通过刻意练习获得的能力，而这个能力的起点，就是每一次动手前对自己多问一句：这张图，真的设计过了吗？
