很多人一提到 diagram-design第一反应就是画图嘛把方框和箭头连起来就好。可真在项目里做出过架构图、流程图、时序图之后你才会明白图表设计从能看懂到好看好用之间隔着一条巨大的鸿沟。我刚开始做系统设计文档的时候画出来的图被同事吐槽像一个毛线球后来花了很长时间才总结出一套自己的图表设计方法。这篇东西不聊空泛的美学全部是实战经验适合写技术方案、产品原型说明、数据报表和教学材料的读者参考。1. 为什么能看懂和好看是两回事先想清楚图表的目标图表设计的起点不是打开绘图工具而是先回答三个问题这张图给谁看需要他看完之后做什么决定他会在什么场景下看图很多图表失败不是绘制技术不行而是目标没想清楚。1.1 信息层级一眼扫过去就要知道重点在哪绝大多数人画图是有什么画什么把系统里每个模块、每次调用、每个字段全都摆上去。结果就是信息密度过高读者根本不知道眼睛该往哪里落。我个人的习惯是在设计第一版之前先把图的主角找出来。比如画一张系统架构图主角是用户请求的流转路径那么数据库、缓存、消息队列这些支撑组件应该被刻意弱化——不是不画而是用更轻的视觉重量去呈现让读者第一眼看到的是主链路而不是一堆旁支末节。这里有一个很实用的判断标准拿掉任何一个图形元素如果整张图的核心意义没有变化那这个元素就是冗余的。反过来如果拿掉一个元素之后读者会更难理解主流程那它就该被保留并且强化。信息层级不是靠感觉做出来的是拿删除测试逼出来的。1.2 叙述逻辑图表是按阅读顺序讲故事而不是信息堆砌还有一个容易被忽视的问题图表是有阅读顺序的。人们习惯从左到右、从上到下看一张图所以你要把最重要的起点放在左上角把结论或者最终状态放在右下角中间用连线牵引视线。我见过很多架构图把网关画在正中间把各个服务围成一圈结果读者看完根本不知道流程从哪开始、在哪结束。这种布局不是自由而是缺少叙述逻辑。画图之前先给整张图写一个一句话故事。比如用户从客户端发起请求经过网关鉴权进入订单服务最终写入数据库并返回结果。这句话就是你的布局骨架所有图形都围绕它展开。2. 图表设计的视觉语法形状、线条、颜色与字体的统一规范确定了图表的目标和逻辑之后接下来是最容易被低估的部分视觉语法的统一。所谓视觉语法就是读者潜意识里对图形元素的默认解读。你打破了这种默认解读读者就会觉得这张图别扭但往往说不清哪里别扭。2.1 形状与图标用一致性消除认知负担在常见的 diagram-design 场景里不同形状是有约定俗成含义的。流程图里矩形代表处理步骤、菱形代表判断、圆角矩形代表起止状态这些约定来自几十年的软件工程实践轻易不要打破。但实际项目里大家更爱用的是架构图和模块图这类图的形状含义没有那么严格更需要你提前建立自己的形状词汇表。比如我在某个某系统设计项目里就明确规定了业务服务用圆角矩形、基础设施组件用直角矩形、外部系统用云状图形、数据存储用圆柱体。所有团队成员画图都必须遵守这套形状规范。这套规范的背后逻辑是读者的视觉系统会快速对相似形状做归类。如果同一个层级的概念一会儿用圆角矩形、一会儿用六边形、一会儿用椭圆读者的大脑就需要额外消耗能量去辨认这个形状到底代表什么。形状越统一读图速度越快。图标的使用同样如此同一个概念不要今天用这个图标、明天用另一个图标图标库选定一套之后就一直用下去。2.2 颜色系统限制色板数量让颜色承担唯一语义真正做过图表设计的人都会告诉你配色是翻车重灾区。新手最容易犯的错误是为了让图看起来不单调把红绿蓝黄紫全都用上。结果图确实不单调了但读者会误以为每种颜色都代表某种特殊含义又找不到规律只能放弃理解。我的经验是一张图里用于表达语义的颜色不要超过三种。比如红色代表异常路径或风险模块蓝色代表核心业务链路灰色代表支撑系统或者弱化背景。其他的元素一律用同色系的不同明度来区分层级而不是用不同色相来分区。还有一个细节不要过度依赖颜色本身来传递关键信息。因为你的图可能会被打印成黑白版读者也可能是色弱人群。所以关键区分必须同时辅以形状差异、线型差异或者文字标注。这一点我是在一次评审会上被真正教育过的——当时我用红绿色标区分正常状态和报警状态会后有人说他完全分不清这两类节点。2.3 字体与文字图表里的字不在于多在于可用图表里的文字数量应该被严格控制。一个节点里的文字最好不超过一行一张图里的文字总量最好能控制在 200 字以内。文字只是图形的辅助解释而不是图表的主体主体永远是结构和关系。如果某个节点的信息量确实很大不要试图把它全部塞进图形框里。正确的做法是图形框里放一个精炼的名称然后通过注释、附录、编号引用等方式把详细信息放在图外。字体方面建议整套图只用一到两种字体中文字体用无衬线体西文和数字用等宽字体这样会让图面显得干净利落。字号也要有梯度主标题和图示说明可以稍大图形内的文字统一一个字号图边注释统一一个更小的字号绝对不要出现十种字号嵌套的局面。3. 布局与空间组织从一坨乱麻到清爽的网格如果说视觉语法解决的是每个元素长什么样那么布局解决的就是元素该放在哪里。我对布局的执念来自一次痛苦经历给某跨平台系统画一张完整的部署架构图画了三个多小时结果连线交叉密密麻麻根本没法看。从那以后我开始系统研究布局方法才知道这背后其实有规律可循。3.1 网格系统的落地方法很多人画图不用网格全靠鼠标拖动觉得位置差不多就行。但差不多的累积叠加在一起就会产生大量小角度的歪斜线。人眼对歪斜特别敏感总觉得哪里不整齐但又说不上来。我的做法是打开编辑器的网格吸附功能把网格间距设置为基础间距的倍数。所有节点的对齐必须落在网格线上节点之间的距离统一采用基础间距的整数倍。比如基础间距是 20px那么相邻两列节点之间的水平距离就用 40px 或 80px而不是随手拖出的 57px 或者 63px。网格布局带来一个附加好处连线走线会变得更规整。正交线横平竖直转折的连线在网格上非常容易对齐而正交线本身也比任意斜线更有工程图的秩序感。除了技术图流程步骤图、组织架构图也可以用这套网格逻辑效果立竿见影。3.2 布局算法选择的常见实践如果你用的是自动布局的图表工具一定要理解它内置的布局算法的适用场景。树形布局最适合呈现层级关系比如组织架构、请求链路分层布局layer layout最适合呈现有明确方向的数据流比如业务流程图力导向布局force-directed layout适合展示复杂的网状关系但它对读者非常不友好连线容易乱飞一般我不建议用在对外输出的图里。一个容易被忽略的点是自动布局只是起点不是终点。自动布局生成之后必须人工调整一遍把关键的主链路节点对齐得更加突出把次要节点往边缘推。你可以这样理解自动布局解决的是不重叠、不错乱的问题人工调整解决的是重点突出、阅读顺畅的问题两个步骤缺一不可。4. 常见图表设计坑位我踩过的低效设计以下这些坑都是我在实际项目里真的踩过、又花了很大力气爬出来的。写出来帮你绕开。4.1 箭头满天飞连线交叉与跳线处理连线交叉是图表丑陋的第一来源。一张图一旦出现三处以上的交叉连线阅读难度会成倍上升。减少交叉的办法有几个把频繁交互的节点放在相邻位置尽量让连线方向保持一致统一从每个节点的右侧出、左侧入如果同一条连线上需要标注说明文字可以把文字放在连线的中段并且保证文字不会覆盖其他连线。还有一个实用细节当两条连线交叉时用跳线来表现——就是在一根线上做一个小的圆弧跨越另一根线。很多工具默认不做跳线你需要去设置里开启。有了跳线读者能清楚分辨出哪根线在上面、哪根线在下面而不是糊成一团。这个设置在流程图和网络拓扑图里尤其重要。4.2 配色随性高饱和度色堆砌我见过不少图每个模块一种高饱和颜色红橙黄绿青蓝紫一字排开。单看每个颜色都不丑放一起就成了一道圣诞树。问题出在对饱和度和明度没有统一约束。我建议每个模块的填充色都用低饱和度的浅色系比如淡蓝、淡灰、淡米色重要的节点用较高饱和度的边框或者深色填充来强调。这样图面整体柔和重点又能跳出来。如果你不知道怎么配一组和谐的颜色一个稳妥的办法是选一个品牌色作为基础色然后用它的同色系不同深浅来画整张图仅在关键异常或外部系统引用第二种颜色。这种单一主色点缀色的策略基本不会翻车。4.3 文字溢出与微缩字体把长文字塞进小框然后为了让它能在框内显示而把字号调到 8 号、9 号这是另一大常见坑。读者把图放大两倍也看不清小框里的文字还挤成一团体验极差。处理办法很简单要么扩大图形框的尺寸要么精简文字。图形框的大小跟着文字走不要让文字迁就框的大小。我在实际项目里收到过一张某个图像处理Demo的流程图整体缩放在一屏根本看不清放大之后每个框里的文字又超出边界被我打回去重画了两次。后来定了个规矩任何图在导出前的最终检查就是整体缩放至 50% 再放大到 200%两个极端下都必须清晰可读。5. 让图表可维护从一张图到一个图表系统一次性画一张漂亮图不难难的是在项目长期演进中让所有图表保持一致的质量。我在某公司的技术文档组里做过一个内部实验让三位成员分别用各自的风格画同一套系统架构产出的三张图放一起谁看都会认为这是三个不同团队画的。这就是缺少图表设计规范的问题。5.1 用模板和组件库固化设计规范把你总结好的形状规范、颜色规范、字体字号规范、网格间距规范做成模板存成组件库。这样一来任何人新建图表都在同一套框架下开始不需要从零定义一个看起来怎么样。组件库里还需要放置常用图标、通用节点样式、统一的箭头样式和线宽设置。不要小看线宽的一致性一条 1px 的线出现在一堆 3px 的线旁边会显得非常突兀这种细节恰恰是决定图表是否专业的关键。我在实际推进过程中发现团队里真正愿意手动改线宽的人极少所以最好的办法是把线宽直接固化在模板样式里让使用者不需要思考这个问题。5.2 命名规范与版本管理图表文件本身的命名和版本管理也是 diagram-design 的一部分虽然不太起眼但影响很大。我见过别人的工程目录里同类图表叠了五六个版本叫 final_v2、final_最新、final_最终版没人分得清哪一版才对应现在的代码实现。建议的命名方式是图表主题_绘制日期_作者标识比如订单服务架构_20240415_张三。每一次修改都另存为新版本而不是覆盖原文件。如果图表表达了系统的某个状态最好把对应的版本号或时间点写进图内的页脚注释里。这样在你回溯历史设计决策的时候图表的版本信息会省掉大量排查沟通时间。5.3 协作审阅流程图表设计最好也纳入评审流程。个人画图很容易陷入自己看懂就默认别人也能看懂的盲区。我所在的团队现在要求所有对外输出的架构图必须经过至少一层同行评审评审的重点不是画得好不好看而是信息是否准确和读者是否难以理解。评审时有一个非常高效的检查方法让一个没有参与该项目的人看图然后请他用自己的话复述一遍图里的流程。如果复述的内容跟图想表达的内容有出入那就是图表本身有问题而不是读者理解能力有问题。这个复述测试我已经用过很多次几乎每次都能发现至少一处布局歧义或者语义不清的地方。6. 从工具链到实操模板我是怎么把它落地的最后说说工具层面的选型和落地这是很多人关注的部分。6.1 工具选型思路市面上的绘图工具五花八门通用型的有 draw.io、Figma程序员常用的有 PlantUML、Mermaid还有各类在线白板工具。我的建议是先确定你的图表交付场景再选工具。如果是写技术方案、需要嵌入 Markdown 文档、希望方便版本管理那么文本型工具例如 PlantUML 或 Mermaid是首选优点是图表随代码走方便 review diff缺点是复杂图表的美观度和自由度有限。如果是做产品演示、对外汇报、设计文档配图需要精细控制布局和视觉细节那么通用型绘图工具更合适优点是自由度高、模板多缺点是需要手动维护规范团队成员多了以后容易出现风格漂移。我个人的组合拳是快速原型用文本型工具正式对外输出用通用型工具通过模板组件库保证两者产出的视觉风格尽量一致。6.2 一个最基础的图表规范模板给你一套可以直接复制走的基础规范模板你可以按自己项目的实际情况调整项目建议值说明画布网格间距20px所有节点对齐落到网格基础间距20px 的整数倍节点间距统一主色单一品牌色表达核心链路强调色一个补充色只用于异常/风险节点弱化色灰色系支撑组件与背景字体无衬线中文字体 等宽数字字体中文与数字混排清晰图形内字号12px ~ 14px不超过两行文字连线宽度统一 2px主线可加粗至 3px箭头形式单线实心箭头明确指向连线折行正交折线45/90 度避免斜线与过多交叉这套模板看着简单但只要你坚持用图面的专业度会提高一个档次。7. 最后图表设计是一个设计系统问题我个人做了这么多年的技术文档和演示材料最深的体会是图表设计不是一个单点问题而是一个设计系统问题。单张图画得好只是偶然一套图每张都稳定在线才是体系化的结果。这套体系里既包含你对读者需求的理解也包含你对视觉规范的坚持还包括你对工具链的驾驭。如果你正在为画图头疼我建议你不要急着去学某个绘图工具的高级技巧先把这张图到底想传达什么、给谁看、用什么视觉语言表达这三件事想清楚。哪怕只用最简单的矩形和箭头只要层级清晰、布局整齐、语义一致成品也不会差到哪里去。反过来就算你用上了花哨的特效和丰富的图标只要这三件事没想清楚图照样是乱的。绘图工具的迭代越来越快自动生成图表的能力也越来越强但工具永远替代不了你对图表结构和信息逻辑的判断。把功夫花在这上面收益远比多学几个快捷键要高得多。希望这篇内容能帮你在 diagram-design 这条路上少踩几个坑也期待你分享自己画图时遇到过的好问题和好解法。 
长河君 · 2026/10/26 19:32:23 · 阅读 1.2k diagram-design实战：架构图与流程图的视觉规范与布局技巧
很多人一提到 diagram-design第一反应就是画图嘛把方框和箭头连起来就好。可真在项目里做出过架构图、流程图、时序图之后你才会明白图表设计从能看懂到好看好用之间隔着一条巨大的鸿沟。我刚开始做系统设计文档的时候画出来的图被同事吐槽像一个毛线球后来花了很长时间才总结出一套自己的图表设计方法。这篇东西不聊空泛的美学全部是实战经验适合写技术方案、产品原型说明、数据报表和教学材料的读者参考。1. 为什么能看懂和好看是两回事先想清楚图表的目标图表设计的起点不是打开绘图工具而是先回答三个问题这张图给谁看需要他看完之后做什么决定他会在什么场景下看图很多图表失败不是绘制技术不行而是目标没想清楚。1.1 信息层级一眼扫过去就要知道重点在哪绝大多数人画图是有什么画什么把系统里每个模块、每次调用、每个字段全都摆上去。结果就是信息密度过高读者根本不知道眼睛该往哪里落。我个人的习惯是在设计第一版之前先把图的主角找出来。比如画一张系统架构图主角是用户请求的流转路径那么数据库、缓存、消息队列这些支撑组件应该被刻意弱化——不是不画而是用更轻的视觉重量去呈现让读者第一眼看到的是主链路而不是一堆旁支末节。这里有一个很实用的判断标准拿掉任何一个图形元素如果整张图的核心意义没有变化那这个元素就是冗余的。反过来如果拿掉一个元素之后读者会更难理解主流程那它就该被保留并且强化。信息层级不是靠感觉做出来的是拿删除测试逼出来的。1.2 叙述逻辑图表是按阅读顺序讲故事而不是信息堆砌还有一个容易被忽视的问题图表是有阅读顺序的。人们习惯从左到右、从上到下看一张图所以你要把最重要的起点放在左上角把结论或者最终状态放在右下角中间用连线牵引视线。我见过很多架构图把网关画在正中间把各个服务围成一圈结果读者看完根本不知道流程从哪开始、在哪结束。这种布局不是自由而是缺少叙述逻辑。画图之前先给整张图写一个一句话故事。比如用户从客户端发起请求经过网关鉴权进入订单服务最终写入数据库并返回结果。这句话就是你的布局骨架所有图形都围绕它展开。2. 图表设计的视觉语法形状、线条、颜色与字体的统一规范确定了图表的目标和逻辑之后接下来是最容易被低估的部分视觉语法的统一。所谓视觉语法就是读者潜意识里对图形元素的默认解读。你打破了这种默认解读读者就会觉得这张图别扭但往往说不清哪里别扭。2.1 形状与图标用一致性消除认知负担在常见的 diagram-design 场景里不同形状是有约定俗成含义的。流程图里矩形代表处理步骤、菱形代表判断、圆角矩形代表起止状态这些约定来自几十年的软件工程实践轻易不要打破。但实际项目里大家更爱用的是架构图和模块图这类图的形状含义没有那么严格更需要你提前建立自己的形状词汇表。比如我在某个某系统设计项目里就明确规定了业务服务用圆角矩形、基础设施组件用直角矩形、外部系统用云状图形、数据存储用圆柱体。所有团队成员画图都必须遵守这套形状规范。这套规范的背后逻辑是读者的视觉系统会快速对相似形状做归类。如果同一个层级的概念一会儿用圆角矩形、一会儿用六边形、一会儿用椭圆读者的大脑就需要额外消耗能量去辨认这个形状到底代表什么。形状越统一读图速度越快。图标的使用同样如此同一个概念不要今天用这个图标、明天用另一个图标图标库选定一套之后就一直用下去。2.2 颜色系统限制色板数量让颜色承担唯一语义真正做过图表设计的人都会告诉你配色是翻车重灾区。新手最容易犯的错误是为了让图看起来不单调把红绿蓝黄紫全都用上。结果图确实不单调了但读者会误以为每种颜色都代表某种特殊含义又找不到规律只能放弃理解。我的经验是一张图里用于表达语义的颜色不要超过三种。比如红色代表异常路径或风险模块蓝色代表核心业务链路灰色代表支撑系统或者弱化背景。其他的元素一律用同色系的不同明度来区分层级而不是用不同色相来分区。还有一个细节不要过度依赖颜色本身来传递关键信息。因为你的图可能会被打印成黑白版读者也可能是色弱人群。所以关键区分必须同时辅以形状差异、线型差异或者文字标注。这一点我是在一次评审会上被真正教育过的——当时我用红绿色标区分正常状态和报警状态会后有人说他完全分不清这两类节点。2.3 字体与文字图表里的字不在于多在于可用图表里的文字数量应该被严格控制。一个节点里的文字最好不超过一行一张图里的文字总量最好能控制在 200 字以内。文字只是图形的辅助解释而不是图表的主体主体永远是结构和关系。如果某个节点的信息量确实很大不要试图把它全部塞进图形框里。正确的做法是图形框里放一个精炼的名称然后通过注释、附录、编号引用等方式把详细信息放在图外。字体方面建议整套图只用一到两种字体中文字体用无衬线体西文和数字用等宽字体这样会让图面显得干净利落。字号也要有梯度主标题和图示说明可以稍大图形内的文字统一一个字号图边注释统一一个更小的字号绝对不要出现十种字号嵌套的局面。3. 布局与空间组织从一坨乱麻到清爽的网格如果说视觉语法解决的是每个元素长什么样那么布局解决的就是元素该放在哪里。我对布局的执念来自一次痛苦经历给某跨平台系统画一张完整的部署架构图画了三个多小时结果连线交叉密密麻麻根本没法看。从那以后我开始系统研究布局方法才知道这背后其实有规律可循。3.1 网格系统的落地方法很多人画图不用网格全靠鼠标拖动觉得位置差不多就行。但差不多的累积叠加在一起就会产生大量小角度的歪斜线。人眼对歪斜特别敏感总觉得哪里不整齐但又说不上来。我的做法是打开编辑器的网格吸附功能把网格间距设置为基础间距的倍数。所有节点的对齐必须落在网格线上节点之间的距离统一采用基础间距的整数倍。比如基础间距是 20px那么相邻两列节点之间的水平距离就用 40px 或 80px而不是随手拖出的 57px 或者 63px。网格布局带来一个附加好处连线走线会变得更规整。正交线横平竖直转折的连线在网格上非常容易对齐而正交线本身也比任意斜线更有工程图的秩序感。除了技术图流程步骤图、组织架构图也可以用这套网格逻辑效果立竿见影。3.2 布局算法选择的常见实践如果你用的是自动布局的图表工具一定要理解它内置的布局算法的适用场景。树形布局最适合呈现层级关系比如组织架构、请求链路分层布局layer layout最适合呈现有明确方向的数据流比如业务流程图力导向布局force-directed layout适合展示复杂的网状关系但它对读者非常不友好连线容易乱飞一般我不建议用在对外输出的图里。一个容易被忽略的点是自动布局只是起点不是终点。自动布局生成之后必须人工调整一遍把关键的主链路节点对齐得更加突出把次要节点往边缘推。你可以这样理解自动布局解决的是不重叠、不错乱的问题人工调整解决的是重点突出、阅读顺畅的问题两个步骤缺一不可。4. 常见图表设计坑位我踩过的低效设计以下这些坑都是我在实际项目里真的踩过、又花了很大力气爬出来的。写出来帮你绕开。4.1 箭头满天飞连线交叉与跳线处理连线交叉是图表丑陋的第一来源。一张图一旦出现三处以上的交叉连线阅读难度会成倍上升。减少交叉的办法有几个把频繁交互的节点放在相邻位置尽量让连线方向保持一致统一从每个节点的右侧出、左侧入如果同一条连线上需要标注说明文字可以把文字放在连线的中段并且保证文字不会覆盖其他连线。还有一个实用细节当两条连线交叉时用跳线来表现——就是在一根线上做一个小的圆弧跨越另一根线。很多工具默认不做跳线你需要去设置里开启。有了跳线读者能清楚分辨出哪根线在上面、哪根线在下面而不是糊成一团。这个设置在流程图和网络拓扑图里尤其重要。4.2 配色随性高饱和度色堆砌我见过不少图每个模块一种高饱和颜色红橙黄绿青蓝紫一字排开。单看每个颜色都不丑放一起就成了一道圣诞树。问题出在对饱和度和明度没有统一约束。我建议每个模块的填充色都用低饱和度的浅色系比如淡蓝、淡灰、淡米色重要的节点用较高饱和度的边框或者深色填充来强调。这样图面整体柔和重点又能跳出来。如果你不知道怎么配一组和谐的颜色一个稳妥的办法是选一个品牌色作为基础色然后用它的同色系不同深浅来画整张图仅在关键异常或外部系统引用第二种颜色。这种单一主色点缀色的策略基本不会翻车。4.3 文字溢出与微缩字体把长文字塞进小框然后为了让它能在框内显示而把字号调到 8 号、9 号这是另一大常见坑。读者把图放大两倍也看不清小框里的文字还挤成一团体验极差。处理办法很简单要么扩大图形框的尺寸要么精简文字。图形框的大小跟着文字走不要让文字迁就框的大小。我在实际项目里收到过一张某个图像处理Demo的流程图整体缩放在一屏根本看不清放大之后每个框里的文字又超出边界被我打回去重画了两次。后来定了个规矩任何图在导出前的最终检查就是整体缩放至 50% 再放大到 200%两个极端下都必须清晰可读。5. 让图表可维护从一张图到一个图表系统一次性画一张漂亮图不难难的是在项目长期演进中让所有图表保持一致的质量。我在某公司的技术文档组里做过一个内部实验让三位成员分别用各自的风格画同一套系统架构产出的三张图放一起谁看都会认为这是三个不同团队画的。这就是缺少图表设计规范的问题。5.1 用模板和组件库固化设计规范把你总结好的形状规范、颜色规范、字体字号规范、网格间距规范做成模板存成组件库。这样一来任何人新建图表都在同一套框架下开始不需要从零定义一个看起来怎么样。组件库里还需要放置常用图标、通用节点样式、统一的箭头样式和线宽设置。不要小看线宽的一致性一条 1px 的线出现在一堆 3px 的线旁边会显得非常突兀这种细节恰恰是决定图表是否专业的关键。我在实际推进过程中发现团队里真正愿意手动改线宽的人极少所以最好的办法是把线宽直接固化在模板样式里让使用者不需要思考这个问题。5.2 命名规范与版本管理图表文件本身的命名和版本管理也是 diagram-design 的一部分虽然不太起眼但影响很大。我见过别人的工程目录里同类图表叠了五六个版本叫 final_v2、final_最新、final_最终版没人分得清哪一版才对应现在的代码实现。建议的命名方式是图表主题_绘制日期_作者标识比如订单服务架构_20240415_张三。每一次修改都另存为新版本而不是覆盖原文件。如果图表表达了系统的某个状态最好把对应的版本号或时间点写进图内的页脚注释里。这样在你回溯历史设计决策的时候图表的版本信息会省掉大量排查沟通时间。5.3 协作审阅流程图表设计最好也纳入评审流程。个人画图很容易陷入自己看懂就默认别人也能看懂的盲区。我所在的团队现在要求所有对外输出的架构图必须经过至少一层同行评审评审的重点不是画得好不好看而是信息是否准确和读者是否难以理解。评审时有一个非常高效的检查方法让一个没有参与该项目的人看图然后请他用自己的话复述一遍图里的流程。如果复述的内容跟图想表达的内容有出入那就是图表本身有问题而不是读者理解能力有问题。这个复述测试我已经用过很多次几乎每次都能发现至少一处布局歧义或者语义不清的地方。6. 从工具链到实操模板我是怎么把它落地的最后说说工具层面的选型和落地这是很多人关注的部分。6.1 工具选型思路市面上的绘图工具五花八门通用型的有 draw.io、Figma程序员常用的有 PlantUML、Mermaid还有各类在线白板工具。我的建议是先确定你的图表交付场景再选工具。如果是写技术方案、需要嵌入 Markdown 文档、希望方便版本管理那么文本型工具例如 PlantUML 或 Mermaid是首选优点是图表随代码走方便 review diff缺点是复杂图表的美观度和自由度有限。如果是做产品演示、对外汇报、设计文档配图需要精细控制布局和视觉细节那么通用型绘图工具更合适优点是自由度高、模板多缺点是需要手动维护规范团队成员多了以后容易出现风格漂移。我个人的组合拳是快速原型用文本型工具正式对外输出用通用型工具通过模板组件库保证两者产出的视觉风格尽量一致。6.2 一个最基础的图表规范模板给你一套可以直接复制走的基础规范模板你可以按自己项目的实际情况调整项目建议值说明画布网格间距20px所有节点对齐落到网格基础间距20px 的整数倍节点间距统一主色单一品牌色表达核心链路强调色一个补充色只用于异常/风险节点弱化色灰色系支撑组件与背景字体无衬线中文字体 等宽数字字体中文与数字混排清晰图形内字号12px ~ 14px不超过两行文字连线宽度统一 2px主线可加粗至 3px箭头形式单线实心箭头明确指向连线折行正交折线45/90 度避免斜线与过多交叉这套模板看着简单但只要你坚持用图面的专业度会提高一个档次。7. 最后图表设计是一个设计系统问题我个人做了这么多年的技术文档和演示材料最深的体会是图表设计不是一个单点问题而是一个设计系统问题。单张图画得好只是偶然一套图每张都稳定在线才是体系化的结果。这套体系里既包含你对读者需求的理解也包含你对视觉规范的坚持还包括你对工具链的驾驭。如果你正在为画图头疼我建议你不要急着去学某个绘图工具的高级技巧先把这张图到底想传达什么、给谁看、用什么视觉语言表达这三件事想清楚。哪怕只用最简单的矩形和箭头只要层级清晰、布局整齐、语义一致成品也不会差到哪里去。反过来就算你用上了花哨的特效和丰富的图标只要这三件事没想清楚图照样是乱的。绘图工具的迭代越来越快自动生成图表的能力也越来越强但工具永远替代不了你对图表结构和信息逻辑的判断。把功夫花在这上面收益远比多学几个快捷键要高得多。希望这篇内容能帮你在 diagram-design 这条路上少踩几个坑也期待你分享自己画图时遇到过的好问题和好解法。