架构图设计实战：diagrams.net绘图方法论与工程化最佳实践

前几天给一个老客户的系统做架构评审，对方一边翻PPT一边问我："你们这套系统的核心调用链，图里怎么没画？"我低头看了两秒，确实没画——不是漏了，是因为那张图我已经画得太乱，根本塞不进去。节点大小不一、箭头交叉成蜘蛛网、颜色至少有十种，我自己看一眼都头疼，更别说让别人在五分钟内看懂业务流转。

这件事之后我认真想了一个问题：diagram-design这件事，看起来人人都能做，但真正做得好的人极少。我们天天用绘图工具，却很少有人把它当成一门"设计"来对待。这篇内容不是教你怎么点按钮，而是把我这几年画架构图、流程图、部署图、ER图积累的方法论、工具选择和踩坑记录完整整理一遍。适合需要画技术图表的开发、运维、产品和任何想把事情讲清楚的人。看完你会发现，好看的图不是画出来的，是"设计"出来的。

1. 从一场"被追问到无话可说"的技术评审说起

那场评审会让我意识到，多数人画图不顺眼，问题根本不在工具，而在没有设计约束。你以为自己在画图，其实是在一张无限画布上做排版、做信息架构、做视觉传达——三件事叠加在一起，却没有任何规则兜底，画出来的东西自然失控。

1.1 三秒内看不懂的图，等于没画

人眼扫一张复杂图表，前两三秒只能建立整体印象：这是什么系统、分几层、核心在哪。如果两三秒之后你还需要逐个点去找重点，这张图就失去了它存在的意义。技术图表不是艺术品，它的唯一使命是压缩信息——把一段冗长的架构说明压缩成一块可以扫码的视觉摘要。压缩失败，画再久都是自嗨。

我见过很多团队文档里的架构图，密密麻麻铺满整页A4，每一个服务都画成圆角矩形、每一个矩形里都塞一段文字，看起来"信息量很足"，实际没人愿意看。真正有效的图表应当有一个视觉焦点，让读者第一眼知道"看哪里"。这个焦点的建立，靠的不是加粗或画红圈，而是靠信息层级——哪些元素应该抢眼、哪些应该安静，必须在落笔之前想清楚，而不是画完之后补救。

1.2 三个底层要素，决定图表成色

我在实践中把图表设计拆成三个独立层次，每一层出了问题都会直接毁掉成品。

第一层是信息架构。你画这张图是为了回答什么问题？读者是谁？他们关心的是系统有几个模块，还是模块之间的依赖关系，还是数据从哪进来从哪出去？信息架构没理清，后续所有视觉工作都是在给错误的结构涂脂抹粉。我自己的习惯是先列一张元素清单，把节点和关系全部写下来，确认没有遗漏，再考虑怎么画。这一步很多人直接跳过，一边画一边补，结果经常画到一半发现布局塞不下，只能推翻重来。

第二层是视觉表现。形状、颜色、字号、线条粗细、间距，这套东西构成了图表的"表情"。系统边界用什么表达？服务用什么形状？数据库用什么形状？外部依赖和内部服务的颜色如何区分？这些视觉变量需要一套稳定规则，而且规则一旦定了，整个图乃至整个文档体系都要遵守。

第三层是阅读体验。读者拿到图以后，视线如何移动？是先看标题还是先看中心节点？要素之间的间距是否给了眼睛喘息的空间？连接线是横平竖直还是歪歪扭扭？这层最容易被忽略，因为它不是"画出来"的，而是"留出来"的——需要破坏性设计，敢于留白、敢于删减、敢于把不重要的信息弱化甚至去掉。

这三层环环相扣。信息架构错了，视觉表现越精致越误导人；视觉表现乱了，再清晰的结构也传达不出去。文章后面的所有内容，本质都是围绕这三个层次展开。

2. 工具选型：为什么绕了一圈，我还是留在 diagrams.net 生态

画图工具多如牛毛，我基本都试过一轮，包括纯代码方案和在线协作方案。先说结论：日常开发文档、技术方案、架构评审的图表，我用diagrams.net（也就是以前的 draw.io）最多，原因不是它功能最花哨，而是它在"够用"和"可控"之间找到了最适合工程场景的平衡点。

2.1 主流工具的真实体感对比

先给一张我自己的工具选择对照表，基本能覆盖大多数人的需求场景。

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 里按Ctrl+Shift+P（或菜单 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 栅格体系：

3.4 用容器和泳道传递系统边界

系统边界是架构图里最需要讲清楚的事之一，而容器（Container）就是干这个的。diagrams.net 里选择矩形工具后，把 Shape 设为"容器"（Container=1），就能往里面摆放其他节点。容器一拖出来，分组关系立刻清晰：一个容器代表一个子系统、一个部署环境或一个业务域。

泳道（Swimlane）则适合表达流程中的角色或阶段划分，常见于跨部门流程图、业务时序图。泳道的方向跟流程方向垂直：横向泳道适合表达上下多角色协作，纵向泳道适合表达阶段递进。

使用容器的几个实操建议：

• 容器要有明确的背景色，但颜色饱和度不能高，否则内部节点会被"吃掉"。建议用浅灰、浅蓝、浅绿这类低饱和色。
• 容器标题用稍大的粗体字，放在左上角或顶部居中，字体颜色用比背景深 2-3 级的颜色。
• 容器内部要留足 padding，不要让内部节点贴着容器边缘。一般来说容器四周至少留 20px。
• 嵌套容器不要超过两层。嵌套超过三层，视觉上会产生严重的层级迷宫，信息传达效率断崖式下降。

4. 一套建立一次、受用很久的颜色与样式规范

颜色是图表设计里最容易翻车的环节。默认调色板颜色太多，很多人画图时凭感觉选色，结果一张图上出现十几种颜色，看过去像打翻的颜料盘。真正专业的图表，颜色通常非常克制——不是审美保守，而是颜色在图表里是语义编码，不是装饰。

4.1 色板设计的"3+1"配色模型

我给自己定的规范是：一张架构图最多使用三种主色加一组中性色，用颜色区分系统层级与类型，而不是逐节点挑选。

举一个典型的微服务架构图配色方案：

核心业务服务用最深的颜色，因为它是全图的焦点；数据层用绿色，因为"数据是资产"这个直觉在大多数读者那里是共通的；外部依赖用橙色，起到警示和区分的作用；基础设施用灰色，安静地待在背景里服务全局。

这套方案的原理是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 允许把某个节点的样式保存成模板，也可以直接编辑样式字符串。选中节点后按Ctrl+Shift+M可以打开样式编辑界面，你会看到类似这样的字符串：

rounded=1;fillColor=#2563EB;strokeColor=#1E40AF;fontColor=#FFFFFF;strokeWidth=2;

这就是节点的完整视觉描述。理解了这个机制，你就可以做一件非常有价值的事：为团队制定一套样式规范字符串，让所有人画图时直接复制粘贴到样式编辑器，保证全团队的图风格完全一致。这比口头要求"大家多对齐对齐"有效一百倍。

比如我常用的核心服务样式：

rounded=1;whiteSpace=wrap;html=1;fillColor=#2563EB;strokeColor=#1E40AF;fontColor=#FFFFFF;strokeWidth=2;

数据层样式：

shape=cylinder3;fillColor=#059669;strokeColor=#047857;fontColor=#FFFFFF;strokeWidth=2;direction=vertical;

把这份字符串清单放进团队的 Wiki 或 README，新成员画图直接套用，产出的图天然统一。这也是做 diagram-design 最有杠杆效应的一步。

5. 完整实操：一张系统架构图是怎么从零画出来的

前面讲了大量原则，接下来进入核心环节——跟着我的操作链路，完整画一张系统架构图。我们以一个常见的"电商后端系统架构"为例，这张图既要放进技术方案文档，也要在评审会上投影讲解。

5.1 第一步：信息架构清单，五分钟列完

任何图的第一件事都不是打开工具，而是拿一张纸列出需要表达的所有元素。我的清单模板长这样：

• 核心节点：客户端（App/Web）、API网关、用户服务、订单服务、商品服务、支付服务、消息队列、用户数据库、订单数据库、商品数据库、Redis缓存
• 关系类型：调用关系（粗实线）、数据读写（细实线）、异步消息（虚线）、外部依赖（带外部标识）
• 分组：接入层、应用层、数据层、第三方依赖
• 核心链路：客户端 -> 网关 -> 下单服务 -> 订单库 / 支付服务 -> 第三方支付

清单列完，你会立刻发现一个信息：这张图的主角是"订单链路"，所以订单服务和支付服务应当放在视觉中心，而商品、用户等服务作为支撑环绕在周围。这个判断在信息架构阶段做好，后面每一步都不会跑偏。

5.2 第二步：搭建画布和布局框架

新建 diagrams.net 页面后，我先把页面设置为横向 16:9（按Ctrl+Shift+P设置），网格间距保持默认的 10px 或直接改成 20px。然后不急着拖节点，先从形状库拖出四个容器，分别命名为"接入层"、"应用服务层"、"数据层"和"第三方依赖"，按从上到下的顺序摆好。

这一步相当于打地基。四个容器把画布分成了清晰的带型区域，后续只需在对应区域里放对应节点，天然就会形成层次感。容器与容器之间的垂直间距我一般留 60px，让每个区域有明显的"段落感"。

5.3 第三步：按区域填充节点，尺寸统一

每个服务节点我统一使用 160x60px 的圆角矩形，标题文字居中，字号 14px。拖入第一个节点后，按住Ctrl拖动复制，或者选中节点按Ctrl+D快速复制，再通过对齐工具（Arrange -> Align）将其排列整齐。

要用好一次性多选对齐：把一组节点全选，然后点击"水平均匀分布"（Distribute Horizontally）和"垂直居中"（Align Middle），几秒钟就能排出一行整齐的服务图标。手动一个个拖对齐是新手最容易踩的效率陷阱。

数据层的数据库用圆柱体形状（shape=cylinder3），大小统一为 140x70px。缓存层用一个小圆角矩形或专用形状。第三方支付则用一个云朵形状，配橙色填充，并加上"外部环境"的文字标注。

5.4 第四步：连线，让关系"看得清"而不是"看得全"

节点放好就该连线了。很多人喜欢"把所有关系都画出来"，我不反对，但前提是分清主次。在电商架构图里，核心链路是"客户端 -> 网关 -> 订单服务 -> 订单数据库"，这条线我使用 3px 的深蓝色实线，是全图最重的元素；订单服务到支付服务、支付服务到第三方支付的线用 2px 实线；其余服务间的调用用 1.5px 灰色实线；异步消息用灰色虚线。

连接线的终点不要直接怼到节点边框上。diagrams.net 默认连接会吸附到形状边缘的固定锚点，建议在线条属性中把"出口方向"手动指定为左右或上下，避免出现斜线交叉。如果两个节点之间的连线需要跨过其它节点，宁可绕一圈，也不要产生斜穿整个图表的线条——斜线是图表杂乱感的主要来源。

连完线之后做一次"简化检查"：问自己，如果去掉任意一条线，读者理解图意会不会受严重影响？如果不会，这条线就是噪音，删掉或弱化它。技术图表的最高境界不是信息最多，而是每一条线都有其存在的理由。

5.5 第五步：标注、图例和细节收尾

图表里文字量最大的部分不是节点，而是连接线上的标签。我给每条核心连接线都加上了一个极简的动词短语，例如"HTTP/JSON"、"异步事件"、"SQL 读写"。标签字号 11px，颜色用中性灰色，避免标签比节点标题还抢眼。

另一个容易被忽略但影响专业度的元素是图例（Legend）。当你的图表使用了颜色编码（比如深蓝=核心服务、绿色=数据层、橙色=外部依赖），应当在图的右下角或左下角放一个图例块，解释颜色和线型的含义。这个块体积不大，但是能让第一次看图的人快速建立解码体系，而不是靠猜。diagrams.net 的形状库里有现成的图例形状，拖出来改文字即可。

最后做一次全图缩放查看（按Ctrl+Shift+1缩放到适应页面）。缩略图模式下最容易被发现的问题有两类：一类是某处间距明显不均匀，放大时看不出来，缩小后一目了然；另一类是整个布局重心偏移，图偏向画布左侧，右侧空了一大块。发现问题后微调容器宽度或节点位置，直到整体重心居中、四边留白均衡。

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 这件事，做得好与做得差之间只隔了一套方法论。别怕前期花时间定规范和搭模板，它们会在后面的每一次画图里加倍回报你。