企业官网建设流程全解析

架构图、流程图、ER 图、时序图……只要在公司里写过方案、做过设计评审、带过新人，就会知道一件事：图这件事，谁都能画，但不是谁都能画清楚。同样是系统架构，有人半小时草草拉一堆框和箭头，评审时被反复追问；有人用一套克制的视觉方案加清晰的层级关系，一张图讲完十分钟的汇报。diagram-design 这个方向，看着是"画图"，背后的门道其实是信息设计。绘图工具只是底线，真正的差距在于：你能不能把一堆模块、依赖、流转关系压成一张人脑轻松消化掉的图，并且让观看者的视线跟着你的逻辑走。

这篇文章不聊具体的工具快捷键，也不做某个软件的教程。我会拆解 diagram-design 从构思到成图的完整链路：先讲清楚一张好图要回答什么问题，再给一套可以直接上手的绘制流程，然后把图表"显专业"的视觉细节和不同场景下的变体做法说明白，最后分享一些实际踩过的坑和排查思路。无论你画的是技术架构图、业务流程图，还是数据关系图，这套方法都能让你的图上一个台阶。适合正在写设计方案的技术同学、需要梳理业务逻辑的产品和运营，以及一切想把"脑子里的东西"清清楚楚交给别人的人。

1. 先搞清楚 diagram-design 到底在解决什么问题

很多人一上来就画笔刷和配色，其实方向反了。设计一张图，本质上是一次信息的"降维输出"。你脑子里可能有几十个模块、上百条依赖关系，但观看者的工作记忆只能同时处理三到五个概念。diagram-design 的第一步，不是决定圆形还是圆角矩形，而是决定：这张图的信息量到底控制在什么密度，观众第一眼落在哪里，第二眼又往哪走。

1.1 一张图的核心价值不是好看，是把关系说清楚

我见过很多精致到可以当壁纸的架构图，配色柔和、图标统一、阴影细腻，但看完完全记不住系统怎么流转。也见过很多粗犷的手绘图，歪歪扭扭，线还是手拉的，但讲解的人指着框讲一遍，所有人都点头。问题就出在：前者的设计资源全部花在了"装饰"上，后者的心思花在了"关系表达"上。diagram-design 的视觉表现力，前提是关系表达准确。

关系表达有几种基本类型，我画图前会先自问这张图主要表达哪一种：

• 层级关系：谁在上层、谁做底层支撑，典型的就是系统分层架构图。这类图要突出"层"的边界和对齐。
• 流转关系：数据、请求、业务单据从哪来到哪去，典型的是时序图、流程图。这类图要突出"顺序"和"分支"。
• 依赖关系：一个模块调用、依赖另一个模块，典型的是服务依赖图、类图。这类图要突出"引用方向"。
• 归属关系：哪些组件属于同一个系统、同一个域，典型的是后台模块结构图。这类图要突出"分组"。

一张图最好只承担一到两种关系的表达。如果既想画分层又想把每条调用链都标清楚，图很快就会变一团乱。实际项目里我经常看到有人把一层里的一个服务单独拉出来，用虚线连到另一个层，再加一堆说明文字，最后整张图的阅读路径完全被打断。如果你发现自己正在一张图里混入了第三种关系，最合理的做法是拆图，而不是硬塞。

1.2 图表必须回答的三个基本问题

在动手画之前，我会强制自己用三句话描述这张图的阅读线索，回答不了就说明思路没成型：

第一，这张图的主角是谁？是系统整体，还是其中某个模块？主角应该在图中占据最显著的视觉位置。有经验的画手会把核心系统放在几何中心或黄金分割点附近，而不是左上角。

第二，这张图的边界在哪？哪些东西画在图内，哪些用一条线框表示外部系统？边界不清晰是常见病，新手往往把外部依赖也画得和内部模块一样重，导致观众看不出哪些是我们要建设的内容。

第三，观众看完后应该记住哪个结论？是"我们多了一层网关来收敛流量"，还是"用户请求经历了三次跨系统调用"？整个图的设计，包括强调色、标注箭头、顺序编号，都应为这个结论服务。如果你把每个框都加粗、每个箭头都标数字，结论就会被噪音淹没。

我在设计评审前经常让同事先看三十秒我画的图，然后让他复述看到了什么。复述内容和我想要的结论越接近，这张图就越成功。这套小方法比任何设计理论都直接，大家可以试试。

2. 从零搭建一张标准架构图的实操流程

想画的图思路理清了，接下来就是落地。我习惯把绘图过程分成三个阶段：先画轮廓，再定关系，最后做排版。很多人喜欢边画边排、边找图标，结果花了大量时间在挪位置和换素材上，核心关系反而没理顺。按这个顺序走，效率会高很多。

2.1 先画轮廓：分层与模块拆解

第一步永远是拿一张白纸（或者是画布上随意摆放的便签），把系统里的核心模块全部列出来，然后按逻辑分堆。这个过程不要碰对齐工具，不要选颜色，先把所有组成要素摆出来。

以一套常见的基础架构为例，模块可能包括：接入层、网关、业务服务 A/B/C、消息队列、缓存、数据库、文件存储、外部服务。我的做法是在白板上把模块分成三到四层，比如上行接入层、业务核心层、数据支撑层、外部依赖层。每一层内部再按业务域或调用顺序整理。

分完层之后，给每一层命名。这个命名技巧很关键：层名要体现层的职责，而不是技术的具体实现。比如"接入层"就比"Nginx 集群"更适合做架构图的第一层称谓，因为后者把实现细节过早暴露出来，观众会陷入思考"为什么用 Nginx 而不是其他部署方式"这种问题，而忽略了你其实是想表达统一入口。除非这个架构图的重点恰恰是技术选型对比，否则层名尽量抽象一级。

2.2 再定关系：连线与依赖的表达

轮廓搭好了，第二步是划线，这是 diagram-design 里最见功力的一步。我先决定这张图要不要画箭头：如果只是表达分层归属，层与层之间甚至不需要箭头，用简洁的直线或干脆留白即可；如果是表达依赖和调用，箭头方向和汇入位置就要重点设计。

画线有几个经验可以分享：

• 线上不能有交叉是理想状态。如果交叉实在避免不了，尽量让交叉发生在空白较多的区域，且用跨线桥接（小圆弧）表示跨过，而不是直接十字穿过。
• 同一张图里线的转角风格要统一。比如统一走直角两段折线，不要一会直线斜切、一会 U 形绕线。直角折线的路径更容易被视觉追踪。
• 一条线最好只表达一种语义。如果需要同时表达"调用"和"回调"，用两种线型去区分，比如实线代表同步调用、虚线代表异步通知。线型的种类控制在三种以内，再多就肉眼难以区分了。
• 标注关系时，尽量把标签写在线的上方或正中间，且顺着线的方向旋转阅读。标签一多就会碎，如果关系文本很长，更好的做法是在线上做编号，在图的底部加图例。

这个阶段我会反复追问自己：每一条线是不是都有必要画出来？很多图乱，不是因为关系少，而是画手想把所有可能的关系都让人看到。事实上，一张图只保留对当前讲解结论最重要的调用关系，其余放到文档里写，会让图面的信息信噪比大幅提升。

2.3 最后做排版：网格、对齐与留白

关系画明白了，第三步才是视觉排版。这一步决定了图看起来"专不专业"，很多人其实就输在这里：模块与模块之间的间距忽大忽小，框的长度有的包住三个字、有的包住十个字，整个图面像随意掉落的积木。

我常用的排版规则很简单：所有框的宽度按文字内容统一到少数几个档位。例如，每个服务名都放到相同宽度的框里，避免参差不齐；如果框内是短词，就统一使用固定的小尺寸；如果框内是长短语，单独用大一号的尺寸。图面上同一层级的框，尺寸必须一致，这是视觉专业感的第一来源。

对齐是第二个关键点。打开绘图工具的"对齐"功能，让同一层的模块中心线对齐、间距相等。网格吸附功能强烈建议打开，它能让模块边缘贴合到网格线，后面所有微调都会轻松很多。间距方面，我一般使用模块高度的 0.5 倍到 1 倍作为模块间距，留白太少会显得拥挤局促，留白太多又让图层连接变得松散。

留白不是浪费空间，而是给观众的视觉呼吸感。好的架构图通常有大面积的"安静区域"，引导视线集中在核心区域。我经常看到有人把图画满整个画布，生怕浪费一分空间，结果就是观众找不到重点。画完可以缩小到 50% 看整体，哪里的空白让人舒服、哪里又堵得慌，一目了然。

3. 让图表不"业余"的细节设计

结构对了以后，细节决定观感的上限。配色、字体、线条粗细、间距和阴影，这些设计细节单个拿出来都不复杂，但组合起来会让一张图的专业程度明显分层。这一章讲的东西，是我在实际绘制中总结得最具体的部分。

3.1 配色与视觉层级：用 70-25-5 的克制原则

我见过太多图是"彩虹色"。每个模块一个颜色，红橙黄绿蓝全用上，看起来内容很丰富，实际上观众视线被颜色牵着到处乱跑，根本不知道哪个是重点。一个好的 diagram-design 在配色上通常遵循 70-25-5 原则：

• 主色占画面约 70%，通常是中性色，也就是灰白、浅蓝灰这类背景和普通模块的颜色。
• 强调色占约 25%，用于核心模块、关键路径的边框或填充，让观众第一眼锁定重点。
• 点缀色占约 5%，用于警告、风险、特殊标识，比如红色的失败链路、橙色的待迁移模块。

具体操作时，我会把全部模块先统一成一个中性底色，然后只给当前最需要强调的主角模块上强调色，其余模块一律灰化处理。很多同事第一次看到我这样配色会问：这么多模块都做成灰色，多单调？但等我把图投到屏幕上，大家马上发现视线会自动聚焦到唯一的彩色模块上，讲解效率立刻提升。

如果必须区分多个系统，我建议使用不同色相但饱和度一致的配色方案，同时把颜色数量控制在四个以内。再多就会造成视觉负担。配色不是越多越丰富，越克制反而越显高级和专业。

3.2 字号、线宽与间距的搭配

文字和线条是图表的基本构成，它们的搭配直接影响可读性。我的经验是定义一套简单的"样式系统"，全图统一执行：

• 一级标签（层名）：14 到 16 号字，加粗，用于标识图层的名称。
• 二级标签（模块名）：12 号字，常规即可，最多对核心模块加粗。
• 说明文字：10 号到 11 号字，只用于图例和少量注释。
• 边框线宽：普通模块 1px，核心模块 2px，整体最多只保留三种线宽。

字号之间不要只差 1 像素，那样肉眼分不出层级。要给足差距，12 和 14 是分得清的，12 和 13 就很勉强。线宽也是同理，1、2、3 这种阶梯式的层级才有效果。

间距方面有几个小原则：框内文字要留出充足内边距，至少是字体高度的 0.5 倍，否则文字紧贴边框显得非常局促；框与框之间的最小间距不要低于 20 像素，太小会导致连线标注挤在一起。所有的间距尽量保持视觉上的一致，比如都用 16px 或 24px，不要忽大忽小。这会让整个图面形成一种持续的节奏感。

3.3 图标的"克制"原则与阴影禁用

很多新手喜欢一上来塞满图标：数据库要画一个圆柱体，服务器要画一个机架，消息队列要画一个信封。图标用得好确实能加分，但用不好会直接拉低专业度。原因很简单：图标天然自带一套语义和视觉重量，不同的图标库风格还不一致，混在一起就成了"拼贴画"。

我的建议是：默认用简单的几何图形加文字，只有当图标能够显著降低理解成本时才使用，比如用圆柱体表示数据库，确实比写"Database"更直观。但一旦决定用图标，就必须做到两点：一是全部图标来自同一套风格，线条粗细一致；二是图标停留在装饰层面，不要占用过多画布面积，不要让图标挤压文字空间。

关于阴影：能不用就不用。现在的绘图工具一键加阴影太方便了，导致很多架构图每个框都是悬浮的。阴影会增加视觉层级，但同时也让图面显得脏。我见过的优秀架构图，几乎都是扁平化处理，几个阴影只出现在最关键的核心模块上，用来制造"从纸面浮起来"的强调效果。当你不确定该不该加时，选择不加，这是最保险的选择。

4. 不同业务场景下图表设计的变体处理

架构图只是 diagram-design 应用的一类，不同场景对图表设计的要求差异挺大。这一部分我挑三个最常见的场景展开：技术方案中的架构图、业务流程图、以及数据模型图。每个场景的侧重点不同，处理的优先级也不同。

4.1 技术架构图：强调层次、聚合与信任边界

技术架构图在方案设计和系统评审中的出镜率最高，它想讲清楚的是"这个系统由哪些部分组成，各自负责什么，彼此之间怎么协作"。因此它的设计重点有三个：分层清晰、模块聚合、信任边界明确。

分层的表达，我一般用整块的横向色带做背景层，把层内的模块放在色带上。这样观众即使在快速浏览时，扫一眼底色就能理解"哪块东西属于同一层"。层与层之间用留白自然分隔，注意不要让上一层的模块触碰到下一层的背景带。

信任边界是很多人容易忽略的点。比如你画一个包含外部支付网关的系统，外部系统和我们内部系统之间有严格的安全边界，这个边界建议用一条粗虚线或者一道明显的竖线分隔出来，内部系统的模块不要越线对外延伸。这样评审会上，安全同学一眼就能看到信任边界是否清晰。

模块聚合是另一个常见问题。如果一个业务域下有三四个服务，先画一个大的"容器框"表示这个业务域，再把服务放到容器内部。这相当于在视觉上增加了一个分组层级，减少观众的理解负担。

4.2 业务流程与状态流转图：情绪的焦点在顺序和分支

流程图的核心不是模块，而是步骤顺序和分支条件。技术架构图看重空间布局，流程图看重的则是时间线。我画流程图时会特别注意三个方面：主路径优先、分支收敛、状态表达。

主路径优先的意思是：最核心的正常流程（Happy Path）在图中占据最明显的位置——通常是从左到右居中偏上的直线路径，同时主路径上的节点用比较深的填充色突出。异常分支、回退分支则用浅色或灰化处理，并放在主路径的下方。这一点很多画手没想明白，他们把判断分支画得和关键流程一样重，观众看完根本记不住主线。

分支要尽早收敛。能并成同一个判断条件的就合并，能用一个状态表示的就不要拆成多个节点。流程图最怕的就是分支之后长时间无法合并，导致图面迅速膨胀成网。实在无法收敛的复杂分支，建议拆成多张子流程，而不是硬画在一张图里。

状态流转图我建议用统一的状态节点样式去表达，比如所有状态用圆角矩形、所有动作用箭头、所有触发条件标注在箭头旁。千万不要状态用矩形、动作也画成矩形，那观众就分不清哪个是"等待结果"哪个是"执行动作"了。

4.3 数据模型图与 ER 图：处理好关系基数和字段分组

画数据 ER 图是 diagram-design 里最"费眼"的场景之一，因为表的数量一多，连线错综复杂，很容易变成蜘蛛网。我的处理思路是从物理表上升到逻辑模型，按业务域把相关的表聚类放置。

关系基数是 ER 图的灵魂：一对多、多对多必须表达清楚。通常我用连线末端的"鸭掌"符号，或者直接用文字标注 1、N、M。项目里最常犯的错误是只画线不标基数，这在做数据库设计评审的时候几乎是致命的，会导致下游开发对关系的理解完全靠猜。

字段多的表可以只在图中展示关键字段，其余字段折叠起来做成备注。这样图面积被大幅压缩，但又不失信息的完整性。如果确实要展示全部字段，就采用上下分区的实体样式：标题区放表名，字段区放字段，主键字段加粗或前缀符号标识。同一张 ER 图里的表务必保持字段展示策略一致，要么都展开，要么都折叠，否则视觉会非常混乱。

5. 常见问题与排查避坑实录

画图这个事，光看方法和理论不够，还得靠踩坑积累直觉。这里分享几个我在真实项目里反复遇到的问题和排查思路，都是可以直接用的教训。

5.1 图总是画得太满，如何处理信息过载

不少人画架构图，恨不得把系统里所有模块全部画上去，二十几个框挤得满满当当。一张图塞进五十个概念，结果就是观众一个也记不住。我的判断标准是：一张图里的模块数量如果超过 15 个，就要考虑拆图或者做分层展示。

拆图有几种拆法：按层次拆解，先画一张全局框图，再为每个核心层单独画一张详细子图；按链路拆解，把完整的调用链拆成几条路径展示；按关注点拆解，把"部署视角"和"逻辑视角"分开。这种拆图手法会让文档的主题架构看起来多了一些子图，但整体的信息清晰度会大幅提升，评审效率是在实打实提高的。

另一个相关的技巧是提供"简化视图"。我会先画一张完整版，再在文档里放一张只保留核心模块的极简版，用来在汇报的开头和总结阶段快速建立画面感。很多读者不是看不懂你的图为，是没耐心看完，简化视图能帮他们快速进入状态。

5.2 团队协作时，样式不统一怎么破

多人协作画一张大图，几乎必然出现样式混乱：这个人的框是直角，那个人的是圆角；一个人用的蓝、另一个人用的灰。如果你们用的是一个可以多人编辑的绘图工具，这个问题的解法是建立团队图例模板，把样式规范固化下来。

具体的做法是：在团队模板的第一页画好标准样式面板，包括模块框的默认填充色、边框色、圆角值、层级色带、箭头线型、字号体系。每次画图前，从模板新建，不要从空白画布开始。这样至少能保证同批次的图在基础视觉上是一致的。

如果是评审场景，我还建议设置统一的画面画幅，例如统一使用 16:9 的宽幅，方便投屏；或者统一把画布宽度设成固定值。很多人画图不考虑画幅，最后导出的图在文档里被压缩成牙刷那么宽，字都看不清，这其实不是图表设计的问题，而是"画布设计"的问题。

5.3 从"看不出重点"到"一眼看懂"的调整案例

分享一个典型的调整过程。某个项目中，我们画了一张外部系统接入的集成架构图，初稿的问题非常典型：所有外部系统、内部网关、内部服务全部画成了一排，颜色相同、框尺寸相同、线型也相同。评审会上，大家沉默了很久，最后有人问：所以我们要改造的是哪个系统？

调整的第一步，是确定主角——我们的内部网关。我们把网关模块放大到其他模块的 1.5 倍，填充强调色，同时把所有外部系统灰化，并放在图的最左侧区域。第二步是简化线型：把所有业务无关的跳转线去掉，只保留三条关键调用链路，并给关键链路加粗。第三步是增加信任边界分隔线，把外部系统与内部区域清晰隔开。

调整完的图投到屏幕上，几乎所有人在十秒内就能回答"这么改的目的是什么"。同一个内容，信息量没有变化，变化的是视觉的重心。这就是 diagram-design 的核心魅力所在。

5.4 图例设计的习惯问题：字小、位置偏、省略

图例是图表的"说明书"。我见过有人把图例放在图的右下角，字号缩到 8 号，感觉是怕人看到一样。图例的第一个原则：位置要显眼，通常放在图的左下角或右下角，但字号不能比说明文字小。第二个原则：图例一定要自包含，图里用到的线型、虚线、颜色、特殊符号，都应该在图例里有解释。尤其是当你的图里同时出现实线、虚线、点线的时候，如果没有图例，观众的解读会造成严重偏差。

第三个经验是：图例放在主图正下方比放在角落更容易理解，因为阅读顺序是从上往下。如果图太长，也可以在文档里单独开一节"图例说明"。总之，图例不是可选项，凡是图里出现了超过两种的线型或颜色，就必须配上。

我自己画了这么多年图，最大的体会是：diagram-design 的本质不是画图技巧，而是思维整理。每次画图找不到一个合理的布局，或者感觉怎么看怎么乱，我都会停下来重新追问那张图的核心信息到底是什么。很多时候图的问题不是视觉问题，是思路还没想清楚。去代码里、文档里、讨论里把那一句话关系彻底想明白再来画，图自然就顺了。最后再分享一个小技巧：每次画完图，保存一版只有黑白的线稿，去掉所有颜色再看一遍。如果黑白状态下关系仍然清晰，说明这张图的骨架是稳的，颜色只是锦上添花。这个习惯，我保持到现在，每次都能在黑白稿里发现自己接线逻辑的问题。