企业官网建设流程全解析

做技术方案最怕的不是代码写不出来，而是逻辑明明想清楚了，讲出来别人听不懂。某次内部评审，一位工程师把后端服务画成一张四十多个节点的大图，颜色加起来快十种，每条线都跨过半个画布连到对面，会议开了二十分钟，还有人在问"这个数据库到底是从哪边接入的"。图没有画错，问题出在diagram-design上：它不是美术课，而是一种信息表达工程。

这篇文章写给所有需要画架构图、流程图、时序图、ER图的工程师、产品经理和文档写作者，讲的是怎么把一张"信息密度很高"的图，设计成"看一眼就懂"的图。我在各种项目里画过几百张图之后发现，dianagram-design真正要处理的核心矛盾只有一个——让读者的注意力按照你想给的方向走。这个方向走顺了，图自然好看；方向乱了，颜色再漂亮也是噪音。

1. 先回答三个问题：给谁看、讲什么、在哪看

很多图画砸了，不是技术问题，而是开始动手之前少问了两句。拿起工具就拖拽框，拖完才开始想"这条线该怎么连"，是人的本能，但也是diagram-design里成本最高的习惯。正确做法是先停下来，回答三个问题。

1.1 给谁看：受众决定了信息密度与抽象层级

同一套系统，画给开发同学看的图和画给业务方看的图，本质上是两种生物。

给开发同学看，可以保留类的名称、接口名、数据库字段级的细节，甚至可以在这里画一个DSL的关系对象模型；给业务方看，你要去掉所有他们不认识的术语，把"消息队列"换成"异步中转站"，把"注册中心"换成"服务登记处"。信息层级不是越低越好，而是越贴近读者的心智模型越好。

我习惯把受众分成三档。第一档是"同行"，他们了解上下文，你可以直接画底层细节；第二档是"跨职能同事"，他们知道你系统的存在，但不知道内部机制，需要你把主要模块和高层流程画出来；第三档是"决策者"，他们只关心投入产出、风险、边界，图里甚至不需要出现组件名。

判断受众之后，给这张图命名也成了设计方案的一部分。给决策者看的图标题可以叫"最终用户下单链路概览"，给同行看的就叫"订单服务依赖关系图"。前者强调的是整体结果，后者强调的是技术结构。同一个模型，图名一变，读者预期也就变了。

1.2 讲什么：一张图只讲一个主要叙事

我见过太多人试图在一张图里同时表达"系统架构""核心流程""异地容灾""性能瓶颈"四个主题，结果读者每三秒就要问一次"那这部分和那部分是什么关系"。

要克制。diagram-design里有一条近乎万能的原则：一张图只讲一个主谓宾。主语是系统或者角色，谓语是行为或关系，宾语是另一个系统或数据。比如"用户通过网关进入订单服务"，这就够一张图撑起它的主线了。其余的东西，要么删掉，要么在子图里做。

如果你确实需要表达多个维度，不要试图用图例、颜色、备注去硬塞。直接把一张大图拆成三到五张小图：系统整体架构一张、关键时序一张、依赖关系一张。小图的阅读成本指数级下降，维护成本也成比例降低。把内容拆开不是偷懒，是真正的可读性设计。

我还常用一个办法验证叙事是否聚焦：用一句话向别人复述这张图的内容，如果一句话说不完，说明这张图的信息量超载了。超载的图，要么拆分，要么降级。

1.3 在哪看：评审屏、文档页、手机端的布局差异

同样一张图，投影仪上能看清的字号，在手机文档里就是一排小蚂蚁。我曾经把一张宽度两千像素的架构图直接贴进移动端文档，最后读者只能在手机上不断放大缩小，体验非常糟糕。

图表设计必须在布局阶段就考虑承载媒体。如果是投影仪评审，正文与标题的字号最好不要低于16px，因为会议室的观看距离往往在两米以上；如果是文档页面，尽量让整张图在单屏内完整呈现；如果必须支持手机端，建议从"宽度优先"改为"纵向走读"，把横向结构改成纵向分层。

另一个容易忽略的问题是导出格式与缩放倍率。在高分屏上，尽量按2倍尺寸导出PNG，防止文字模糊。同时，在文档里给出指向原图文件的链接，让读者能够放大查看细节。这是很多实践团队的标准动作，也是diagram-design里最廉价、最实用的可访问性措施。

2. 图类型选择：别让甘特图干流程图的活儿

打开任何绘图工具，模板库里有几十种图：流程图、状态图、时序图、甘特图、ER图、泳道图、拓扑图……模板多不是问题，问题是很多人只看名字不看语义，选了一个"看起来差不多"的模板，把内容硬往里装。

2.1 流程类图：流程图与状态图的分工

流程图描述的是"一件事从开始到结束的路径"，它的核心是动作与判定。你画出"用户提交订单""校验库存""支付成功"，这三者之间是事件的前后关系。流程图适合回答"这件事会怎么发生"。

状态图描述的则是一个对象若干状态之间的迁移。比如订单的状态有"待支付""已支付""已发货""已取消"，状态图强调的是一件事在不同条件下怎么切换，它适合回答"这个对象在下述场景中会怎么变化"。

很多人把两者混着画：把状态莫名其妙画成流程节点，又把条件判断画得到处分支。一张图里动作和状态混在一起，读者就要反复切换理解模式，认知成本直接翻倍。选择图类型的底层逻辑是：你想让读者建立"路径感"，还是建立"状态感"。前者选流程图，后者选状态图。

2.2 结构类图：架构图、拓扑图与组织图的差异

架构图展示的是软件系统的分层与组件之间的调用关系，拓扑图展示的是网络物理节点之间的连接与数据流向，组织图展示的是人或模块的归属关系。三者的表现要素完全不同。

架构图用层级与区块表达职责边界，连线通常表示接口调用；拓扑图强调节点的连接方式，一般会标注链路类型与IP网段；组织结构图强调"谁向谁汇报"，使用树形结构最合适。把架构图画成拓扑图，读者会误以为"服务之间是物理节点互连"；把组织图画成架构图，读者会去追问"上层依赖下层的接口是什么"。

我常用的决策方式是：先问"读者需要理解的是逻辑分层还是物理连接，还是行政归属"。回答之后，图类型就基本锁定了。选定类型后，再调用工具模板里的对应布局风格，很省力。

2.3 关系类图：ER图、思维导图与知识图的取舍

数据密集的场景，ER图几乎是唯一可靠的选择。它描述实体、属性与关系，有严格的方法论。但很多人在做"概念梳理"时也用ER图，就会过度建模——明明只是罗列一些需求点，非要画出一堆主外键，反而把简单事情复杂化了。

如果是头脑风暴、需求梳理、知识整理，思维导图明显更好用。它把层级关系变成树结构，不需要定义关系的基数与属性。知识图则适合表达"多个实体之间有一对多、多对多关系"的网状信息，有一定的语义建模能力。

我的经验是：关系密度低，用思维导图；关系密度高、需要精确对应，用ER图；关系之间不止"谁连着谁"而是"为什么连接"时，用知识图并加注释。关键不在于你会画哪一种，而在于你能不能在一开始就判断出"内容的结构形态合不合适这张图"。

2.4 动态场景：时序图、活动图与甘特图的分工

一旦涉及到时间维度，图类型的选择也容易出错。

时序图最珍贵的能力是表现"消息在对象之间按时间顺序流动"。它强调同心协作的先后顺序，比如网关、认证中心、订单服务之间的同步调用链路。活动图则关注多个并发分支的执行与同步条件，适合表述复杂业务编排。甘特图是项目管理工具，表达任务的时间窗口与依赖，很多人却拿它来表达流程调度，结果一个任务只能对应一个推进条，表达不了反复尝试和回滚。

所以每次画动态场景，我都会先问：你想强调的是消息先后、并发分支，还是时间窗口？答案定了，图类型就定了。避免把三者的要素揉在一张图里。

3. 布局与连线：先管好看图顺序，再管好不好看

图类型的骨架搭好之后，真正决定diagram-design成败的，是布局与连线。布局的本质是给读者设计视觉动线，连线的本质是帮读者在节点之间建立无歧义的关系。很多图内容正确，但布局糟糕，读者看到一半就迷路了。

3.1 分组与留白：距离本身就是语义

在图里，元素之间的距离不是空白，它是语义线索。两个方块靠得近，读者潜意识会认为它们属于同一组；离得远，自然认为它们不属于一组。这种不需要文字说明的引导，是布局设计中最高级的手段。

我给自己定过一个规则：用留白区分层级，组内间距是组间间距的一半。比如模块内部的子组件相距16px，模块与模块之间相距32px，组与组之间留白64px。这样可以快速形成视觉集聚，读者一眼就能判断"这几个东西是一个整体，那一块又是什么部分"。

分组要配合外框或浅色底块使用。给一组相关模块加一个圆角矩形底，并在底块左上角标注组名，就能让读者在完整理解节点之前先建立分类框架。这个方法在画大型架构图时特别管用，它能极大降低读者记忆分组关系的工作量。

3.2 主方向：阅读方向就是数据流方向

中文环境下，读者的阅读方向习惯是从左到右、从上到下。图的流向尽量遵从这两个方向绕不过去。

我见过一些图，数据流从右下角进入，经过左边缘，再折回中心，读者要反复扭头才能跟完一条链路。这种设计的本质是"节点摆放随意，连线跟着随意跑"。正确做法是先确定整个图的主方向：主流程从左到右，层级从顶到底。如果必须回头，尽量减少回折，必要时用统一的"返回箭头"代替长线。

对于需要双向流动的场景，我通常会把"正向流程"放在主方向，把"反向补偿流程"放在下一层或另一条辅助通道。这样读者先建立起主链条，再去读分支，理解成本会低很多。

3.3 最小化连线交叉的三种手段

连线交叉多，图的可读性会急剧下降。每多一个交叉点，读者就要多做一次"判断这条线到底走哪里"的工作。要降低交叉，我常用的手段有三个。

第一个手段是"用边界锚点代替直角折线"。在draw.io、Excalidraw这类工具里，连线可以设置为"沿网格走"，系统会自动规划路径，避免穿过节点区域。需要自己排版时，尽量让连线从方块的左右两侧进出，保持水平轨道，减少垂直折弯。

第二个手段是调整节点位置。把有高交互关系的节点尽量相邻摆放，交叉概率就会降低。这需要你先列出所有节点之间的连接次数，按连接频次排布位置，相当于做一次非常轻量的"图嵌入"计算。

第三个手段是走线复用。当多条线指向同一个目标节点时，可以在画布边缘汇集成一条总线，再在目标节点处按分支展开。这有点类似总线路由的思路，实际阅读时比满天飞的交叉线好懂得多。

3.4 对齐与网格：让每个元素"有迹可循"

人类对杂乱排列非常敏感。元素东倒西歪，读者下意识会觉得这张图不专业、不可信。所以，在diagram-design的收尾阶段，必须做严格的对齐与网格整理。

大多数绘图工具都支持网格吸附与对齐参考线。我一般把画布网格设置为8px或16px，所有节点尺寸取偶数，所有间距落在网格线上。这是因为8px网格在普通屏幕上缩放时不易产生半像素模糊，而且按倍数缩放时保持清晰。

对齐不仅指水平与垂直对齐，还包括元素内部文字的对齐。方块里的标题垂直居中、说明文字统一左对齐，会让图在视觉上非常干净。对于箭头线端，也需要对齐到节点边框的中间锚点，而不是落在节点内部任意位置，否则读者会误认为"连到了某个具体字段"。

4. 颜色、字号与图形：一套克制而有表达力的视觉规范

布局解决完"读者往哪看"，接着就需要一套视觉规范来解决"读者怎么分类地看"。颜色、字号、图形语言构成了图的设计体系，这个体系越统一，读者理解起来越省力。

4.1 中性色优先，强调色只有两种以内

我在项目里总结过一条规律：一张技术图里，大面积使用的颜色应该全是中性色，颜色饱和度只留给2%的内容。所谓中性色，就是灰、白、深灰、浅灰这些不刺激视知觉的颜色；强调色则是需要引起注意的蓝、橙或红。

一个很常见的错误是，每个模块都给不同的底色，最后整张图像一块彩色拼布。读者看不出这些颜色有什么区别，只感觉到"花"。正确做法是：基础模块统一用白底灰框，当前重点模块用一个蓝色边框，异常状态模块用红色或橙色标记。定义成规则后，读者看到红色，就会条件反射地寻找异常。

我自己常用的一套色值是这样的：

这套色值在投影仪和文档上都比较稳定，对比度足够，打印成灰度图也不会失真。

4.2 字号与字重：同一张图里不超过三档字号

字号是信息层级的第二个重要载体。一张图里如果同时出现七八种字号，读者会一直被"这个字体为什么这么大"分心。我通常只用三档字号：画布标题用最大一档，节点名称用中间档，说明文字用最小档。各档字号之间差距要明显，比如22px、15px、12px。

字重也有讲究。节点名称用中粗体，辅助说明用常规体，强调项用加粗体。用字重而不是配色来区分主次，可以让图即使打印成黑白的，层级依然清楚。字体方面，我倾向于使用无衬线的开源字体，例如一些通用现代字体，保证在不同操作系统里显示一致。

文字承载的意义要尽量短。节点名称能用3个字表达，就不要用8个字。比如"库存管理服务"在图中写成"库存服务"，配合上下文读者能立即理解。图内的说明文字尽量用短语，不要用完整句子。所有长解释都放到图下方的图例或段落说明里。

4.3 形状语义：矩形、圆角矩形、菱形、胶囊的约定

形状在diagram-design里是语义，不是装饰。业界有一些约定俗成的用法，值得沿用，避免读者重新学习。

矩形通常用于表达一个过程或服务模块；圆角矩形在流程图里常表示开始或结束，在架构图里也可以代表相对独立的子系统；菱形严格表示判定或分支；胶囊形表示外部角色或系统边界。只要你在一张图里保持形状与语义的映射一致，读者会很快建立起一种"看到菱形就知道要分叉"的条件反射。

同一种形状不要承载多种含义。有人用矩形表示普通模块，又用矩形加粗边框表示核心模块，这没问题，因为加粗边框是另一个维度。但如果一会儿用圆角矩形表示"服务"，一会儿又用圆角矩形表示"外部系统"，读者就会彻底混乱。

4.4 图例：一图一例的配套规范

图例不是可有可无的点缀。只要图的受众并非"只看到一种颜色、一种形状"，你就应该放一个简单图例。图例通常放在图的左下角或右上角，列出颜色与形状的语义。

图例不需要很长，两三行足矣。例如：

• 蓝框：本方案新增模块
• 红框：存量模块
• 菱形：条件分支

这个动作看起来很小，但对跨职能读者特别友好。有些团队把图例做成固定模板，每次新图画完，直接复制图例组件，减少重复劳动。我认为这是最值得推广的工程化习惯之一。

5. 工具选型与成品前的检查清单

最后说说工具和验证流程。diagram-design不止是设计方法，还要靠一套顺手工具来落地。选对工具，比死磕某一个软件的高级功能要重要得多。

5.1 手绘感与工程感：Excalidraw和draw.io的分工

手绘风工具的最大价值是天然地把读者带入"随时会改、无需过度严谨"的心理状态。适合内部讨论、快速对齐思路、画白板替代品。它的线条是不规则的，读者不会死抠细节，讨论效率很高。

工程感更强的绘图工具则适合交付物。节点可以规范对齐、连线有网格吸附、导出清晰可靠，而且支持自定义图层和外部模板。我一般把第一版架构草图放在手绘工具里完成，迭代到基本稳定后，再迁移到工程感工具里精修。这个流程比从一开始就精细画要快得多，因为早期的"发现哪些模块该拆并"往往需要大量试错。

5.2 文本绘图：PlantUML/Mermaid的取舍

文本绘图的价值在于可版本化、可评审、可自动生成。PlantUML和Mermaid都是比较常见的文本绘图方案，尤其适合画时序图、流程图和ER图。因为在文本形式下，节点位置完全交给布局引擎，你可以把注意力集中在内容模型上。

缺陷也一样明显——复杂空间布局的表达能力有限。如果你要精细控制节点间的视觉距离，文本绘图会让你相当痛苦。所以我把文本绘图用于两类场景：一是放进代码仓库与源码一起维护的架构文档，二是需快速生成时序图、用例图等依赖关系清晰的场景。如果是要做演示级视觉图，还是回归手绘工具与工程感工具的搭配方案。

5.3 面向正式设计稿：在通用设计工具里统一交付

当图需要嵌入技术方案书、售前材料、年度报告时，它已经不只是技术图表，而是一个"视觉交付物"。此时最好把已经定稿的图导入通用设计工具，统一字体、统一图标、统一边距，再输出成品。

这里值得注意的是可维护性。每次图变了，都要回到原始文件里改，再同步到交付文档。所以，我会在文档中同时保存一份源文件链接和一个静态图快照。源文件用于更新，静态图用于快速预览。否则三个月后有人问"这个图能不能换个颜色"，你只能对着已经压平的PNG发愁。

5.4 发布前的自检：一张图发布前问自己七个问题

我在长期实践中总结了一个七问自检清单，每次导出前照着过一遍。这些问句可能看起来简单，但几乎每一条都能拦住一批真实问题：

• 第一，这张图有没有明显的主方向？主流程是否从左到右、从顶到底？
• 第二，图里的颜色是否满足"大面积中性、小面积强调"？
• 第三，同一类型的内容是否用了一致的形状、边框、底色？
• 第四，文字是否短到不能再短？有没有完整句子混在里面？
• 第五，连线有没有明显交叉？交叉是否可以再优化？
• 第六，离远看十秒钟，第一眼看到的是不是这个图最重要的信息？
• 第七，如果读者只看图不看文字，能理解主要结论吗？

最后这一条我尤其重视。好的diagram-design应该让读者"看图说话"，如果他第一反应只能说"这是个大系统"，那说明图还很失败；如果他第一反应是"这里有四个模块，其中两个是新增的，主链路是从左到右"，这张图才算真正完成。

我自己在实际项目里最大的感受是：画图过程一定要与读者对齐，而不是与屏幕对齐。图画的次数多了，最后看一张方案图，已经不是在看方块和线条，而是在看一种压缩过的叙事。每一次动手之前，多问几个"给谁看、讲什么、在哪看"，图的返工率都会肉眼可见地降下来。最后再分享一个小技巧：把所有反复用到的模块样式存成一个自己的图形模板库，新图画起来，效率至少翻一倍。diagram-design不是玄学，它是一套可以训练的技能，画得越多，手感越准。