前几天给一个老客户的系统做架构评审对方一边翻PPT一边问我你们这套系统的核心调用链图里怎么没画我低头看了两秒确实没画——不是漏了是因为那张图我已经画得太乱根本塞不进去。节点大小不一、箭头交叉成蜘蛛网、颜色至少有十种我自己看一眼都头疼更别说让别人在五分钟内看懂业务流转。这件事之后我认真想了一个问题diagram-design这件事看起来人人都能做但真正做得好的人极少。我们天天用绘图工具却很少有人把它当成一门设计来对待。这篇内容不是教你怎么点按钮而是把我这几年画架构图、流程图、部署图、ER图积累的方法论、工具选择和踩坑记录完整整理一遍。适合需要画技术图表的开发、运维、产品和任何想把事情讲清楚的人。看完你会发现好看的图不是画出来的是设计出来的。1. 从一场被追问到无话可说的技术评审说起那场评审会让我意识到多数人画图不顺眼问题根本不在工具而在没有设计约束。你以为自己在画图其实是在一张无限画布上做排版、做信息架构、做视觉传达——三件事叠加在一起却没有任何规则兜底画出来的东西自然失控。1.1 三秒内看不懂的图等于没画人眼扫一张复杂图表前两三秒只能建立整体印象这是什么系统、分几层、核心在哪。如果两三秒之后你还需要逐个点去找重点这张图就失去了它存在的意义。技术图表不是艺术品它的唯一使命是压缩信息——把一段冗长的架构说明压缩成一块可以扫码的视觉摘要。压缩失败画再久都是自嗨。我见过很多团队文档里的架构图密密麻麻铺满整页A4每一个服务都画成圆角矩形、每一个矩形里都塞一段文字看起来信息量很足实际没人愿意看。真正有效的图表应当有一个视觉焦点让读者第一眼知道看哪里。这个焦点的建立靠的不是加粗或画红圈而是靠信息层级——哪些元素应该抢眼、哪些应该安静必须在落笔之前想清楚而不是画完之后补救。1.2 三个底层要素决定图表成色我在实践中把图表设计拆成三个独立层次每一层出了问题都会直接毁掉成品。第一层是信息架构。你画这张图是为了回答什么问题读者是谁他们关心的是系统有几个模块还是模块之间的依赖关系还是数据从哪进来从哪出去信息架构没理清后续所有视觉工作都是在给错误的结构涂脂抹粉。我自己的习惯是先列一张元素清单把节点和关系全部写下来确认没有遗漏再考虑怎么画。这一步很多人直接跳过一边画一边补结果经常画到一半发现布局塞不下只能推翻重来。第二层是视觉表现。形状、颜色、字号、线条粗细、间距这套东西构成了图表的表情。系统边界用什么表达服务用什么形状数据库用什么形状外部依赖和内部服务的颜色如何区分这些视觉变量需要一套稳定规则而且规则一旦定了整个图乃至整个文档体系都要遵守。第三层是阅读体验。读者拿到图以后视线如何移动是先看标题还是先看中心节点要素之间的间距是否给了眼睛喘息的空间连接线是横平竖直还是歪歪扭扭这层最容易被忽略因为它不是画出来的而是留出来的——需要破坏性设计敢于留白、敢于删减、敢于把不重要的信息弱化甚至去掉。这三层环环相扣。信息架构错了视觉表现越精致越误导人视觉表现乱了再清晰的结构也传达不出去。文章后面的所有内容本质都是围绕这三个层次展开。2. 工具选型为什么绕了一圈我还是留在 diagrams.net 生态画图工具多如牛毛我基本都试过一轮包括纯代码方案和在线协作方案。先说结论日常开发文档、技术方案、架构评审的图表我用diagrams.net也就是以前的 draw.io最多原因不是它功能最花哨而是它在够用和可控之间找到了最适合工程场景的平衡点。2.1 主流工具的真实体感对比先给一张我自己的工具选择对照表基本能覆盖大多数人的需求场景。工具适合场景最大优势最大痛点diagrams.net架构图、流程图、部署图、UML本地文件、免费、功能均衡默认样式偏朴素需自己调Mermaid轻量流程图、时序图、Git文档内嵌纯文本、可Diff、上手极快复杂布局基本不可控PlantUMLUML类图表、类图、用例图文本描述、集成度高布局超出预期时很难微调FigmaUI/UX设计、团队在线协作设计能力最强、协作流畅技术图表的形状库较弱偏设计Excalidraw快速草图、头脑风暴手绘风、零门槛不适合正式文档交付Mermaid 和 PlantUML 这种代码画图我依然在使用但场景很固定比如 README 里画个简单流程图、代码注释里描述状态机强调可版本管理和浏览方便。一旦图复杂到一定规模代码生成布局的不可控性就会变成灾难——你想把两个相邻节点换个位置需要改代码、推断布局逻辑、刷新预览可能来回折腾十分钟。而 drag-and-drop 工具里只需要拖一下。Figma 我也用过一段时间做对外汇报的精致架构图确实爽协作体验碾压所有技术绘图工具。但它有一个致命问题图不在代码仓库里。架构图是文档的一部分文档和代码要一起发布、一起评审、一起归档。Figma 文件是封闭的跟 Git 的集成要么靠导出静态图要么靠第三方插件流程一复杂就容易断。而且用 Figma 画技术图常常会陷入过度设计——一个图标要调半天的阴影和圆角偏离了技术文档的初衷。2.2 diagrams.net 的隐藏优势用久了才知道diagrams.net 文件的核心格式是.drawio本质是一个 XML 文件。这带来一个被严重低估的能力它可以进 Git 做版本管理。架构图和代码一样有演进历史这周加了两个微服务、下周拆了一个数据库、再下周把缓存层换掉了——有了 Diff 能力你可以精确地看到每次改动改了什么。这个特性在审计和协作场景里价值极高。更妙的是diagrams.net 支持直接把图保存成.drawio.svg或.drawio.png格式。这种文件本质上是把 XML 内容嵌入了 SVG 或 PNG 文件意味着你导出的图片本身就是可编辑的源文件。在 GitHub/GitLab 上在线预览时能直接看图下载后又能继续编辑再也不用维护一份图片和一份源文件并且担心它们不同步。如果配合 VS Code 的 Draw.io 插件还能在 Markdown 里直接引用.drawio.svg文件改完图保存文档那边自动同步更新。另一个优势是本地优先。文件存在自己电脑或自己的 Git 仓库不依赖任何云服务没有隐私担忧也没有账号过期和免费版限制的问题。你只需要一个浏览器就能打开 diagrams.net离线场景照样能用。这一点对很多公司尤其重要——数据安全合规要求资料的流转链路是可控的在线画图工具默认上传到第三方服务器的行为在严格环境下是过不了审的。3. 落笔前先定视觉骨架比例、栅格、留白和阅读动线工具选好了接下来是最容易被跳过、却最关键的一步在正式放节点之前先规划整张图的骨架。如果把最终图画比作一栋房子这个骨架就是建筑结构——墙能砌在哪、窗户能开在哪都是结构决定的。不画结构直接摆砖头最后往往墙歪窗斜。3.1 页面、方向和栅格基础设施决定上限我几乎每张图都从调整画布属性开始。diagrams.net 里按CtrlShiftP或菜单 File - Page Setup可以设置页面尺寸和方向。技术图表我一般选横向画布16:9 或 4:3 比例因为人的双眼视野是横向的横向排布也更适配 PPT 和文档页面的展示场景。然后开栅格。diagrams.net 默认有网格点这不仅是辅助对齐的工具更是建立间距体系的基准。建议把网格间距设为 10px 或 20px然后所有节点的尺寸、位置都建立在网格的整数倍上。举个例子你画一个服务节点宽 160px、高 60px两个节点之间的间距设为 40px 或 60px——这些数字全是 20 的倍数。这样做的好处是所有元素都在统一的模数体系里整张图自然产生秩序感。乱画之所以显得乱最根本的原因就是尺寸和间距毫无规律每个元素都在随机位置。开启对齐辅助线View - Guides也很有用。拖动节点时出现的红色辅助线会帮你自动对齐其他节点边缘和中心。更进阶的做法是先摆好第一个节点作为锚点其余节点以它为准进行等距排列而不是每个节点都手动目测对齐。3.2 黄金阅读动线从左到右、从粗到细绝大多数技术图表遵循从左上到右下的阅读顺序。这不是什么玄学而是文字阅读习惯的自然延伸。我在布局时会把最核心的组件放在画布中上方或左上区域让它成为视线最先落地的锚点次要组件围绕它向右侧和下方展开最细枝末节的东西放到底部或边缘。动线还决定了连接线的走向。理想的架构图应当主线清晰、支线不抢戏。如果核心数据流是从 A 到 B 再到 C这条链路应该是全图最突出的一条线——要么用更深的颜色要么走直线少拐弯必要时加粗一点点。反观次要的配置流、管理流、日志流则可以用浅色虚线弱化确保主线能一眼被识别。有一个我常用的具体方法先在白纸上粗略画一个方块布局草稿每个方块只写模块名不画任何细节。然后用箭头表示模块之间最核心的关系看看主线有没有交叉。如果一张图在草稿阶段就有超过两处主线交叉说明布局思路有问题需要重新安排模块位置。草稿阶段调整成本极低等上了工具再改就费劲了。3.3 留白不是浪费是信息密度调节器新手画图最常见的毛病是把图填满。一页纸恨不得塞下所有服务、所有接口、所有注释最后阅读体验和早高峰地铁一样拥挤。我见过很多图节点之间只有十几像素的间距箭头标签叠在线上看一会儿就头晕。间距的本质是视觉呼吸。两个相邻的服务节点如果你的内容是文字注释它们至少需要 40px 以上的间距否则文字和边框会黏在一起如果是大段文字内容间距还要更大。容器和容器之间比如业务层和基础设施层之间建议留出 60-80px并用背景色或泳道分隔清晰传递这些是一组、那些是另一组的信息。留白还有一个作用暗示关系亲疏。模块 A 和模块 B 靠得近读者会潜意识认为它们关系紧密A 和 C 离得远自然觉得它们弱耦合。这个直觉可以被用来强化架构表达——把强依赖的组件放一起把弱关联的组件拉开距离。不用画任何注释读者光看间距就能建立正确的系统认知。我给一个可直接抄的间距参考表基于 20px 栅格体系元素关系建议间距同组节点之间40px不同分组之间60-80px容器与外框间距40px连接线与节点间距20px文字与形状边距8-12px3.4 用容器和泳道传递系统边界系统边界是架构图里最需要讲清楚的事之一而容器Container就是干这个的。diagrams.net 里选择矩形工具后把 Shape 设为容器Container1就能往里面摆放其他节点。容器一拖出来分组关系立刻清晰一个容器代表一个子系统、一个部署环境或一个业务域。泳道Swimlane则适合表达流程中的角色或阶段划分常见于跨部门流程图、业务时序图。泳道的方向跟流程方向垂直横向泳道适合表达上下多角色协作纵向泳道适合表达阶段递进。使用容器的几个实操建议容器要有明确的背景色但颜色饱和度不能高否则内部节点会被吃掉。建议用浅灰、浅蓝、浅绿这类低饱和色。容器标题用稍大的粗体字放在左上角或顶部居中字体颜色用比背景深 2-3 级的颜色。容器内部要留足 padding不要让内部节点贴着容器边缘。一般来说容器四周至少留 20px。嵌套容器不要超过两层。嵌套超过三层视觉上会产生严重的层级迷宫信息传达效率断崖式下降。4. 一套建立一次、受用很久的颜色与样式规范颜色是图表设计里最容易翻车的环节。默认调色板颜色太多很多人画图时凭感觉选色结果一张图上出现十几种颜色看过去像打翻的颜料盘。真正专业的图表颜色通常非常克制——不是审美保守而是颜色在图表里是语义编码不是装饰。4.1 色板设计的31配色模型我给自己定的规范是一张架构图最多使用三种主色加一组中性色用颜色区分系统层级与类型而不是逐节点挑选。举一个典型的微服务架构图配色方案颜色RGB值用途深蓝#2563EB核心业务服务核心业务服务翠绿#059669数据存储层数据存储层数据库、缓存橙色#D97706外部依赖/第三方服务外部依赖或第三方服务灰色系#6B7280、#E5E7EB基础设施、网络、通用节点基础设施、网络、通用节点核心业务服务用最深的颜色因为它是全图的焦点数据层用绿色因为数据是资产这个直觉在大多数读者那里是共通的外部依赖用橙色起到警示和区分的作用基础设施用灰色安静地待在背景里服务全局。这套方案的原理是60-30-10 法则的图表化应用大约 60% 的画面面积是中性色灰、白30% 是辅助色绿、橙10% 是主焦点色深蓝。这样读者的视线会被自然吸引到那 10% 的区域也就是你最想让对方注意的地方。每加一种新颜色都是在稀释视觉焦点所以加色要极其谨慎。4.2 形状的语义化使用除了颜色形状也在传递信息。我见过有人在架构图里把所有元素都画成一样的圆角矩形然后靠文字区分——这等于放弃了一个重要的编码维度。我把常用形状和语义固化成规范圆角矩形服务、应用、功能模块技术图中绝大多数节点圆柱体数据库、缓存、消息队列等存储类组件直角矩形系统边界、外部系统、硬件设备菱形判断、分支节点流程图中使用云朵外部网络、不可控环境、第三方云服务扁六边形网关、路由、负载均衡器人形图标用户角色、外部人员这套形状语义一旦固定看图的成本会大幅降低。读者不需要逐个读文字扫一眼形状就知道这个元素属于哪一类。这也是为什么我建议团队内部最好统一一份形状使用规范文档哪怕只是几行备注长期价值都很可观。4.3 文字、描边和投影的使用纪律文字是图表中信息最密集的载体但很多人对文字的使用非常随意。字号建议至少三种层级类似排版系统标题/容器名称16-18px加粗节点主名称13-14px正常字重辅助说明/注释11-12px颜色可淡一些同一张图中相同层级的文字必须保持相同字号不能有的节点用 14px、有的用 15px。字体族建议统一使用无衬线字体比如微软雅黑、苹方或 Helvetica避免出现衬线体与非衬线体混排的违和感。描边stroke的使用规则更简单默认统一 1px 或 2px重点强调的节点可以加粗到 3px但全图加粗的节点不要超过两三个。投影尽量少用或不用。diagrams.net 默认会给某些形状加阴影这种阴影在导出的图片里常显得脏我一般全图统一关闭。如果你追求层次感用背景容器颜色比用投影更干净。4.4 把样式沉淀成模板而不是每次重调diagrams.net 允许把某个节点的样式保存成模板也可以直接编辑样式字符串。选中节点后按CtrlShiftM可以打开样式编辑界面你会看到类似这样的字符串rounded1;fillColor#2563EB;strokeColor#1E40AF;fontColor#FFFFFF;strokeWidth2;这就是节点的完整视觉描述。理解了这个机制你就可以做一件非常有价值的事为团队制定一套样式规范字符串让所有人画图时直接复制粘贴到样式编辑器保证全团队的图风格完全一致。这比口头要求大家多对齐对齐有效一百倍。比如我常用的核心服务样式rounded1;whiteSpacewrap;html1;fillColor#2563EB;strokeColor#1E40AF;fontColor#FFFFFF;strokeWidth2;数据层样式shapecylinder3;fillColor#059669;strokeColor#047857;fontColor#FFFFFF;strokeWidth2;directionvertical;把这份字符串清单放进团队的 Wiki 或 README新成员画图直接套用产出的图天然统一。这也是做 diagram-design 最有杠杆效应的一步。5. 完整实操一张系统架构图是怎么从零画出来的前面讲了大量原则接下来进入核心环节——跟着我的操作链路完整画一张系统架构图。我们以一个常见的电商后端系统架构为例这张图既要放进技术方案文档也要在评审会上投影讲解。5.1 第一步信息架构清单五分钟列完任何图的第一件事都不是打开工具而是拿一张纸列出需要表达的所有元素。我的清单模板长这样核心节点客户端App/Web、API网关、用户服务、订单服务、商品服务、支付服务、消息队列、用户数据库、订单数据库、商品数据库、Redis缓存关系类型调用关系粗实线、数据读写细实线、异步消息虚线、外部依赖带外部标识分组接入层、应用层、数据层、第三方依赖核心链路客户端 - 网关 - 下单服务 - 订单库 / 支付服务 - 第三方支付清单列完你会立刻发现一个信息这张图的主角是订单链路所以订单服务和支付服务应当放在视觉中心而商品、用户等服务作为支撑环绕在周围。这个判断在信息架构阶段做好后面每一步都不会跑偏。5.2 第二步搭建画布和布局框架新建 diagrams.net 页面后我先把页面设置为横向 16:9按CtrlShiftP设置网格间距保持默认的 10px 或直接改成 20px。然后不急着拖节点先从形状库拖出四个容器分别命名为接入层、应用服务层、数据层和第三方依赖按从上到下的顺序摆好。这一步相当于打地基。四个容器把画布分成了清晰的带型区域后续只需在对应区域里放对应节点天然就会形成层次感。容器与容器之间的垂直间距我一般留 60px让每个区域有明显的段落感。5.3 第三步按区域填充节点尺寸统一每个服务节点我统一使用 160x60px 的圆角矩形标题文字居中字号 14px。拖入第一个节点后按住Ctrl拖动复制或者选中节点按CtrlD快速复制再通过对齐工具Arrange - Align将其排列整齐。要用好一次性多选对齐把一组节点全选然后点击水平均匀分布Distribute Horizontally和垂直居中Align Middle几秒钟就能排出一行整齐的服务图标。手动一个个拖对齐是新手最容易踩的效率陷阱。数据层的数据库用圆柱体形状shapecylinder3大小统一为 140x70px。缓存层用一个小圆角矩形或专用形状。第三方支付则用一个云朵形状配橙色填充并加上外部环境的文字标注。5.4 第四步连线让关系看得清而不是看得全节点放好就该连线了。很多人喜欢把所有关系都画出来我不反对但前提是分清主次。在电商架构图里核心链路是客户端 - 网关 - 订单服务 - 订单数据库这条线我使用 3px 的深蓝色实线是全图最重的元素订单服务到支付服务、支付服务到第三方支付的线用 2px 实线其余服务间的调用用 1.5px 灰色实线异步消息用灰色虚线。连接线的终点不要直接怼到节点边框上。diagrams.net 默认连接会吸附到形状边缘的固定锚点建议在线条属性中把出口方向手动指定为左右或上下避免出现斜线交叉。如果两个节点之间的连线需要跨过其它节点宁可绕一圈也不要产生斜穿整个图表的线条——斜线是图表杂乱感的主要来源。连完线之后做一次简化检查问自己如果去掉任意一条线读者理解图意会不会受严重影响如果不会这条线就是噪音删掉或弱化它。技术图表的最高境界不是信息最多而是每一条线都有其存在的理由。5.5 第五步标注、图例和细节收尾图表里文字量最大的部分不是节点而是连接线上的标签。我给每条核心连接线都加上了一个极简的动词短语例如HTTP/JSON、异步事件、SQL 读写。标签字号 11px颜色用中性灰色避免标签比节点标题还抢眼。另一个容易被忽略但影响专业度的元素是图例Legend。当你的图表使用了颜色编码比如深蓝核心服务、绿色数据层、橙色外部依赖应当在图的右下角或左下角放一个图例块解释颜色和线型的含义。这个块体积不大但是能让第一次看图的人快速建立解码体系而不是靠猜。diagrams.net 的形状库里有现成的图例形状拖出来改文字即可。最后做一次全图缩放查看按CtrlShift1缩放到适应页面。缩略图模式下最容易被发现的问题有两类一类是某处间距明显不均匀放大时看不出来缩小后一目了然另一类是整个布局重心偏移图偏向画布左侧右侧空了一大块。发现问题后微调容器宽度或节点位置直到整体重心居中、四边留白均衡。5.6 检查清单交付前五连问每次画完图在正式放进文档或评审材料之前我都会过一遍下面这个清单你可以直接拿走用核心链路是否能在 3 秒内被识别如果不能继续弱化次要元素。节点尺寸和间距是否遵循统一模数有没有随机出现的异形尺寸颜色数量是否控制在 3 种主色 中性色以内有没有节点颜色是顺手挑的连接线是否有交叉、斜穿、绕线混乱能否通过调整节点位置消除交叉图例、标题、标注是否齐全换一个完全不了解背景的人能读懂这张图吗这五条过完图的质量基本能进入可以交付的行列。你可能会觉得过程繁琐但多画几张之后这些规范会成为肌肉记忆画图速度反而比乱画再改快得多。6. 图表工程化让 diagram 真正融入研发协作体系图表画得好是一回事能在项目和团队里持续产生价值是另一回事。diagram-design 的进阶玩法是让图表进入工程链路成为代码库的一部分而不是散落在个人电脑里的孤立图片。6.1 版本管理与代码评审图也是代码前面提过.drawio文件是 XML这意味着它天生适合 Git。团队协作时架构图的变更可以像代码一样被评审打开 Pull Request改动点一目了然——订单服务图标改了个标题、新增了一个 Redis 集群节点。这在架构演进频繁的团队里价值巨大因为它让架构变更记录不再依赖记忆而是有了可追溯的历史。操作上我建议约定一个文档目录规范例如docs/diagrams/下按模块分子目录图标统一命名为order-service-architecture.drawio.svg这类格式。这样文件本身就是可预览的图片不需要打开编辑器就能在 GitHub 上看到渲染结果。配合自动化检查甚至可以让 CI 对图表文件做基础校验比如检查是否有孤立的未连线节点但目前这块生态还不成熟我刚才说到的做法更多是轻量的约定不依赖重工具。6.2 从图到 PPT、从图到文档的跨介质复用架构图的生命周期通常不只是存在仓库里还要不断被复制进 PPT、方案文档和知识库。diagrams.net 的导出选项里有几个我在实践的推荐配置PNG 导出适合一般文档插图。导出时建议把缩放设为 2 倍避免在 Retina 屏幕上模糊。背景色改成透明还是白色取决于目标页面的背景。白色背景几乎是默认安全选择。SVG 导出适合需要后期二次编辑或高质量印刷的场景。SVG 是矢量格式放大多少都不糊而且导出的 SVG 编辑层级基本保留可以用编辑器或脚本继续处理。PDF 导出适合打印、正式评审材料或需要嵌入长篇报告的场景。PDF 的矢量特性保证了质量稳定可控。这里有个细节值得单独说导出 SVG 时diagrams.net 默认会把字体转为路径或依赖本机字体跨设备打开可能出现字体替换的问题。如果你把 SVG 嵌入到网页中建议在导出设置里勾选嵌入字体选项或者干脆把导出内容的关键文字转成路径确保任何设备上打开都长一样。6.3 把图表嵌入文档系统的几种成熟姿势如果你是 Markdown 文档的重度用户可以试试 VS Code 的 Draw.io Integration 插件。这个插件让.drawio.svg和.drawio.png文件可以直接在编辑器里打开和编辑并存档回文件相当于把绘图能力嵌入编码环境。写架构文档时直接在文档旁边打开图画两笔保存关闭文档自动更新体验非常顺。如果你用飞书/Confluence 这类文档平台方式会更重一些通常需要先导出 PNG/SVG再上传附件或插入图片。这类平台对图表源文件的集成支持普遍比较弱意味着后续维护时你要同时更新源图和目标文档。我的经验是尽量把源图放在 Git 仓库文档里只引用仓库内图片的固定链接或相对路径这样至少保证源文件只有一份权威版本。7. 我在 diagram-design 实战里反复踩过的坑最后这部分是纯经验教训汇总。这些坑我基本都亲手踩过大部分不止一次写出来希望你绕着走。7.1 连接线交叉成蜘蛛网根因是布局顺序错了我早期画架构图最爱犯的错是随便定节点的位置然后去接线线的交叉就交给工具自动路由。结果复杂系统接完线中间乱成一团根本没法看。后来我意识到连接线交叉的解药不是画完再调而是布局时按连线最少交叉原则排列节点。具体操作方法是先把有着重要连接关系的节点相邻放置再安排次要节点。比如 A 与 B 之间有强连接、B 与 C 之间有强连接那就应该按 A-B-C 的顺序排成一条直线或 L 形而不是把 B 放在中间、A 和 C 夹在两边造成十字交叉。所有连接放在同一方向比如所有下向连接集中在中轴线能大幅降低视觉混乱度。7.2 默认字体和导出字体的薛定谔问题有一段时间我导出的 PNG 图在同事电脑上打开文字全是口口口。排查了一圈问题出在字体兼容性上——我在 macOS 上用了苹方字体而同事在 Windows 上打开同样文件系统里没有这个字体降级渲染就把文字显示成了方块。解决方式有两种。第一种是把字体优先设置为跨平台通用的安全字体比如微软雅黑、Arial、Helvetica 等别用本地特色字体。第二种是导出前把文字转为路径但这会牺牲源文件编辑性只适合最终交付、不再改动的场景。我建议团队内部统一字体规范并在 README 里写明图表字体统一用 XXXX省得后续为字体问题反复沟通。7.3 图片模糊的真相不是导出格式的问题是缩放比例有人问为什么同一张图导出 PNG 后放在文档里很模糊看起来像是压缩坏了。其实绝大多数情况下不是平台压缩的问题而是导出时分辨率设低了。diagrams.net 导出 PNG 时会让你选择Zoom比例默认是 100%。如果原始画布只有 1200px 宽放上大屏投影或高清屏文档就会产生拉伸模糊。我的经验是导出时把 Zoom 调到 200% 甚至 300%。这样生成的 PNG 像素数是原始画布的好几倍放在任何场合都清晰锐利。文件体积会增加但现代文档平台处理几张几百 KB 的插图毫无压力。类似地从矢量 SVG 导出 PDF 时也要注意 PDF 页面尺寸是否匹配目标画布大小否则会出现一大片白边。7.4 自动吸附是帮手也是坑diagrams.net 的自动吸附节点靠近时会自动吸附对齐在多数情况下非常高效但在需要故意错开的场景里就成了坑。比如你想把两个节点错开半个身位表达某种不对等自动吸附会强行把它们拉回整齐对齐这时需要按住Alt键再拖动节点临时关闭吸附功能获得精确的自由摆放。这个快捷键很小但实用性极高。另一个吸附陷阱是当你拖动一个容器的时候容器内的所有元素会跟着整体移动有时你以为只选中了一个容器实际把内部几十个节点都挪了。所以在拖动之前一定要确认选中对象的层级或者干脆把容器和内部节点放进不同的图层Layers需要整体调整时只操作容器层需要精细调整时操作节点层。7.5 一份图例为什么比 1000 个字 更值钱我最后分享一个最简单但收益极高的改进任何图只要颜色编码超过两种就配一个图例块。很多人觉得自己画的图中英文字都标得很清楚了图例多余。但实际看图的人和画图者掌握的信息是不对等的——你画图时心里想的是蓝色核心服务但读者看到蓝色只会想为什么这几个节点是蓝色的。如果右下角有一个 3cm x 4cm 的图例块写着蓝色核心服务绿色数据存储橙色外部依赖所有疑问瞬间消失。图例块在我的绘图流程中是和正文一起创建的不是事后补的。把它当成图的一部分而不是附注这样架构图就能脱离讲解者的口头解说而独立存在。这也回到了最初那个技术评审场景——如果我的架构图自带清晰图例和层级规范会上那种你这张图核心链路在哪的追问根本不会发生。diagram-design 这件事做得好与做得差之间只隔了一套方法论。别怕前期花时间定规范和搭模板它们会在后面的每一次画图里加倍回报你。