企业官网建设流程全解析

1. 从需求到成品：先搞清楚一张图到底要解决什么问题

很多人拿起绘图工具就开画，画到一半发现节点位置一团乱，连线交叉成蜘蛛网，最后只能反复拖拽来“修正”，结果越修越乱。你问他在画什么，他说画架构图；你再问他这张图给谁看、想传达什么结构，他却答不上来。这不是工具的问题，而是缺了一套可复用的图表设计方法。我整理这套 diagram-design 方案，就是想把“画图”这件事，从依赖手感转向依赖规则：明确图形表达什么信息，视觉细节如何统一，产出怎么沉淀为可复用的组件，让架构图、流程图、时序图这些高频图表真正变得清晰、稳定、能维护。

这套方案适合谁？后端工程师要把系统模块画清楚，前端要给交互流程做可视化，产品要出功能路径图，文档工程师要维护一套长期更新的说明图。每个角色都离不开图表，但大多数人没有系统想过：一张图由哪些基础元素组成，连线虚实代表什么，颜色差异承担什么语义，节点间距是否有统一标准。diagram-design 的核心就是把这些问题按层面拆开，一层层给出可执行的答案。

我自己的体会是，这项工作最大的价值不是“画出某一张图”，而是建立一张图可以长期生长的方式。新模块加进来，旧模块删掉，团队换了几拨人，图的结构和样式依然保持稳定。这个效果，只靠“画得好看”是做不到的。

1.1 先给 diagram-design 定个位

diagram-design 不是某一个具体的制图工具，也不是一套固定模板，而是定义图表从“信息组织”到“视觉呈现”再到“工程化落地”的规则体系。它回答三个问题：第一，这张图的节点和边分别是什么；第二，不同类型的图形元素如何用统一的视觉语言表达；第三，如何让这套表达方式在团队里被一致复用，而不是依赖某个人的个人习惯。

这里的关键是“规则”。举个例子，假设你需要画一张系统部署图。信息层面的规则可能是：每个服务是一个节点，服务间的调用关系是连线；节点按层次分成接入层、应用层、数据层。视觉层面的规则可能是：层次用背景色块区分，调用方向用箭头表示，异常链路用虚线标出。工程层面的规则则要求节点尺寸、字体大小、间距全部有固定取值，换成任何人来画，产出的风格都一致。

把这三个层面分开想，图表设计才能从“灵光一现”变成“可持续实践”。

1.2 为什么必须结构优先、样式其次

画图顺序上，我见过最多的错误就是一上来就调颜色和圆角。先挑个漂亮的配色方案，再把节点拖得整整齐齐，最后发现关系表达错了，所有调整全部白费。正确顺序是先把结构定死，再谈视觉。结构指的是节点之间真正的逻辑关系：A 依赖 B，B 包含 C，C 与 D 是顺序关系。这些关系画错了，样式再精美也是一张废图。

我习惯用一个类比来讲这件事：盖楼不能先贴瓷砖，你得先打地基、立框架。图表的地基是节点集合与关系集合，框架是这些关系的组织方式，比如树形、分层、线性流程、循环、网络。瓷砖才是颜色、字体、圆角、阴影。结构不清晰的图，读者第一眼看到的是堆在一起的色块，要花很大力气才能分辨出层级关系。

当你把结构画清楚之后，样式调整才有意义。因为这时候你知道哪些信息需要被强调，哪些信息只需要一眼带过。我在实际操作中的做法是，先用最简单的方块和箭头把逻辑走一遍，确认自己看懂了，团队里其他人也看懂了，再开始套视觉规范。这个过程省下的时间，远比想象中多。

1.3 统一规范不等于做成模板库

有人一听“统一规范”就担心，是不是所有的图都要长成一个样了。其实不是。规范统一的是表达规则，不是内容结构。就像一栋楼里所有房间都遵循同一套电路规范，但客厅和卧室的布局依然可以千差万别。diagram-design 里统一的通常是这些：线条的虚实代表什么、颜色的深浅代表什么、节点圆角大小代表什么、多级标题的字号梯度是什么。这些规则一旦定下来，读者只要接触过其中一张图，就能迅速读懂其余所有图表，学习成本急剧下降。

模板库则是另外一回事。它是针对某个具体场景的成品，比如“三层的微服务架构模板”“登录流程时序模板”。模板追求拿来即用，规范追求跨场景的一致表达。一个健康的团队应该积累规范 + 适度模板，规范保证下限，模板提高上限。如果只有模板，遇到模板没覆盖的场景，图就会立刻变得风格迥异。

2. 图表设计的关键细节：节点、连线、标签、布局、色彩

把结构想清楚之后，下一步是处理视觉细节。很多人觉得视觉细节就是“审美问题”，审美确实有主观成分，但图表不是纯粹的视觉作品，它要承担信息传达任务。因此这里讲的细节，主要服务于“减少阅读负担”，而非“好看”。

2.1 先把图表类型做一次收敛

图表的世界看上去包罗万象，但高频出现的核心结构有限。我把工作里常见的图表归纳为五类：流程类、层级类、时序类、关系类、汇总类。流程类描述步骤先后，典型是业务流程图；层级类描述归属关系，典型是组织架构图和系统模块树；时序类描述交互顺序和消息传递，典型是时序图；关系类描述多方之间的依赖或关联，典型是网络拓扑和依赖图；汇总类则把多维指标放到一张图里做总览，典型是功能全景图和监控大屏。

这五类结构各有各的表达重点，对应关系不能混用。比如把面向过程的流程图画成树形，读者就分不清时间顺序；把面向关系的架构图画成线性列表，读者就看不出模块间的依赖网络。

2.2 节点、连线、标签的默认规则

节点是图表的基本单元。每类节点应该有清晰的边界：同一张图里，同类节点的尺寸保持一致。如果你发现某个节点上的文字太长导致尺寸失控，优先压缩文字，而不是放任节点越变越大。不同类节点可以用边框形状区分，比如矩形表示模块、圆角矩形表示交互页面、圆形表示网关或入口。为了兼容色弱和黑白打印场景，不能只靠填充颜色区分节点类型，还需要辅以形状或文字标识。

连线用于表达节点之间的关系，这是图表中语义最容易混乱的部分。我给连线定的默认规则是：实线表示确定关系，虚线表示逻辑上的可选关系或未来规划，粗线表示核心链路，普通细线表示次要链路。箭头方向统一为“数据流向”或“调用方向”，一张图里不能一会儿从左到右表达流程，一会儿从下到上表达依赖。如果出现了双向关系，就用双向箭头，不要用两根线来回画。

标签是读者定位信息的锚点。标签要离它修饰的对象尽量近，通常放在节点内部正中央、节点下方第一行或连线中间位置。文字不能跨过连线，也不能压在边框上。标签内容坚持一个原则：能短则短，不要试图在节点里写整段描述，细节可以放到图注或文档里。

2.3 布局节奏与对齐体系

图表的“乱”，大多是节点位置没有节奏。同样是树形结构，如果每个子节点之间的间距完全不同，眼睛找对齐线会非常累。我推荐用网格思维来对齐：把画布设置为 8 像素基础网格，节点间距取值为 8、16、24、32 的整数倍。这样即使节点数量很多，整体视觉也能保持整齐。

同一层级的节点顶部对齐，同级子节点的间距保持一致。连线尽量走横向和纵向，不让斜线成为主力，必要时才用斜向折线表达跨层关系。这背后的原因是人的视觉习惯：水平和垂直线更容易追踪路径，斜线多了容易拐弯失控。

白空间也该被刻意设计。密集的图需要留出“呼吸区”，主要元素周围的留白要比次要元素多一些。节点与节点之间至少保留 16 像素的间隙，分组容器与内部节点之间至少保留 24 像素的间隙，这些数字从设计系统的角度来说是随便拍的“硬参数”，但它们一旦固定下来，就有助于形成可预测、可复制的排版效果。

2.4 配色的克制原则

图表配色最忌讳“五颜六色只为了区分”。颜色在图表里的角色是编码信息，不是装饰。同一张图里的主色建议不超过 2 个，辅助色再加 2 到 3 个。主色用于强调核心模块或当前主题，辅助色用于区分次级模块。状态信息的颜色单独定义：比如正常用主色填充，告警用红色描边，待定用灰色虚线框，危险用红色填充。这样读者一看到颜色就能映射到状态，而不是把每种颜色当作一个独立的新类别。

我给很多团队定过配色规则，有一条经验尤其管用：用“语义色”替代“装饰色”。也就是说，一个颜色在整套图表体系里只能表达一种含义。红色永远是异常或警示，绿色永远是成功或正常，灰色永远是待定或次要。如果一张图里用了蓝色表示正常的服务状态，另一张图用绿色表示同样的含义，阅读者就不得不重新学习语义。

色彩之外还需要冗余编码。颜色之外增加文字、形状或者线型的区别，避免完全依赖色彩做信息区分，既有可访问性上的考虑，也方便黑白的打印场景。

3. 完整实操流程：从需求梳理到代码化生成

讲完细节，现在走一遍完整流程。这一节我会用一个模拟需求作为例子：某跨平台系统需要绘制一张精简的业务功能架构图，包含移动端、桌面端和服务端三个区域，以及它们的核心功能模块和数据流向。整条流程走完之后，你得到的不仅是一张图，还能沉淀一套可以重复使用的图表资产。

3.1 需求梳理：先回答五个问题

制图之前先别打开画布，先回答几个问题。这张图给谁看？给研发团队看，还是给业务方汇报看，决定了信息颗粒度。它在什么场景出现？在文档里作为静态插图，还是上线后作为大屏展示，决定了画布尺寸和细节复杂度。核心信息只有一条？架构图应该让读者一眼看出三端边界和数据流向，而不是同时表达部署细节和权限体系。哪些信息必须保留，哪些可以丢弃？画图的过程必然是信息筛选的过程，留主干、砍分支。图的内容边界在哪？上一个图与下一个图的衔接点在哪里？明确边界，避免把两张图的内容混成一张。

这个阶段的目标是形成一页纸的内容草稿，里面只有方块和连线，没有任何样式。很多“画图慢”的问题都出在跳过这一步直接进入工具，然后在工具里反复调整逻辑结构。先拿到认可的结构，再去做视觉设计，效率高得多。

3.2 结构化：把内容拆成统一的图元模型

需求确认之后，把内容转成图元模型。所有图表本质上都可以拆为四类元素：节点、连线、分组容器、标签。节点承载实体对象，连线承载关系，分组容器表达边界或层级，标签补充说明。对应到刚才的例子，移动端、桌面端、服务端各是一个分组容器，容器里有若干功能节点，节点之间用箭头连线表达调用或数据流关系。

为了让后续能够被程序处理或自动化生成，我习惯把图元模型转成结构化数据。这里用 JSON 示例做一次展示：

{ "title": "跨平台业务系统功能架构图", "canvas": { "width": 1920, "height": 1080, "grid": 8 }, "groups": [ { "id": "mobile", "name": "移动端", "level": 1 }, { "id": "desktop", "name": "桌面端", "level": 1 }, { "id": "server", "name": "服务端", "level": 1 } ], "nodes": [ { "id": "n1", "name": "用户登录", "group": "mobile", "type": "page" }, { "id": "n2", "name": "扫码识别", "group": "mobile", "type": "module" }, { "id": "n3", "name": "数据面板", "group": "desktop", "type": "page" }, { "id": "n4", "name": "订单服务", "group": "server", "type": "service" }, { "id": "n5", "name": "用户服务", "group": "server", "type": "service" } ], "edges": [ { "from": "n1", "to": "n4", "label": "REST API", "style": "solid" }, { "from": "n2", "to": "n4", "label": "REST API", "style": "solid" }, { "from": "n3", "to": "n5", "label": "REST API", "style": "solid" } ] }

这样做的价值在于，图和数据分离。后续想改节点名称、增删连线，就不用动图形本身，改数据后重新生成即可。即使团队里有人不熟悉画图工具，他也能通过维护这份数据来更新图表。

3.3 套用视觉规范：定义一套主题变量

图元模型确定了内容，接下来套视觉规范。视觉规范不应该是逐一手动设置每个节点的颜色、字体、边框，而应该像前端样式一样抽象成一组“主题变量”。

这组变量包含：画布背景色、分组容器填充色与边框色、页面类节点填充色、服务类节点填充色、连线颜色与箭头样式、主标签字号与字重、次标签字号、节点圆角半径、间距基准值。把这些变量统一定义后，所有图元只引用变量名，不重复携带具体取值。这样换主题时只需要改变量定义，整张图的风格就会联动更新。

在颜色取值上，我建议先定主色与中性色。主色可以选择一个中低饱和度的蓝色系或青色系，中性色用深浅不同的灰色。容器背景比节点背景浅一级，节点再使用统一的白色或浅色填充。文字颜色统一用深灰，不用纯黑，纯黑在屏幕上的对比度过强，看久了容易累。

3.4 从数据到成图：代码化生成与自动布局

确定了主题变量之后，图元数据可以被程序渲染成最终图形。这一步不是强制要求，但做出来之后收益最大。基本的思路是：读入 JSON 数据，通过布局算法计算每个节点的坐标，再根据主题变量渲染节点和连线。

常用布局策略有几种。层级结构适合用自上而下的分层布局：先把根节点放在顶部，其直接子节点分布在同一水平线上，子节点的子节点继续下移。分组结构适合用容器布局：先为每个分组分配一个外框，再在框内执行对应布局。树形结构可以用叶子节点对齐的方式，更容易实现紧凑排布。

我写过一个简化版的坐标计算思路。以刚才的业务架构图为例，三个分组并列放置在画布上，每个组内部的节点采用水平流式排列。大致的计算逻辑是：

function layoutGroup(nodes, startX, startY) { let cursorX = startX; const nodeGap = 24; nodes.forEach((node, index) => { node.x = cursorX; node.y = startY; cursorX += node.width + nodeGap; }); return cursorX; }

实际生产中，更复杂的场景会使用力导向布局或分层布局，但核心思路一致：坐标由程序计算，而不是人手工拖拽定位。手工定位适合一次性的图，代码化布局适合需要频繁修改、长期维护的图。于是，制图的瓶颈从“手动调位置”转移到“定义好结构”，后者恰恰是更可控的步骤。

3.5 导出与交付：不同场景下的正确姿势

图渲染完成之后，交付环节同样有讲究。如果图要放到文档里供读者放大查看，导出矢量格式最稳妥，常见的矢量格式包括 SVG 和 PDF。矢量图在缩放时不会失真，文字也能保持清晰。如果图要在 IM 或网页分享中作为图片展示，导出为位图格式则需要额外注意分辨率问题。特别是带文字的图，必须导出足够大的位图尺寸。我一般用 2 倍甚至 3 倍导出：画布宽 1920 就导出 3840 或 5760，避免被压缩后文字模糊。

文件命名上也要遵循可检索原则。建议采用“项目名-图类型-版本号”结构，比如“cross-platform-arch-v2.3.svg”。版本管理如果用的是 Git 类工具，把源文件和数据文件一起纳入版本管理，方便日后追溯。很多团队只留存导出后的位图，源文件丢失，结果三个月后想改一处连线，只能从头再画。

4. 我在实际操作中踩过的坑：问题与排查速查

规范讲起来清楚，做起来总会有意外。这里整理一些我反复遇到的问题，给你作避坑参考。

4.1 图越来越乱，往往不是结构问题而是布局问题

有一次，团队里有人反馈某张架构图越看越乱，我打开源文件后发现节点关系定义得没问题，问题出在节点位置完全靠手动拖拽，同层节点没有对齐，相隔很近的两个跨组连线硬是绕了远路。解决方法很简单：把布局逻辑交给算法或至少走一遍网格对齐，设置统一间距，重新排列。

手动拖拽适合草稿期快速验证，一旦结构确认，就该用对齐工具一键整理。每次整理后检查三条：同一层级的节点是否在同一水平线或垂直线上，连线与节点边缘交叉点是否合理，分组是否完整包住内部节点。

4.2 标签重叠和文字过密

图中文字一旦多起来，标签重叠几乎不可避免。规约上的建议是控制节点文本长度，例如不超过 8 到 10 个汉字。当文本超长时，优先考虑拆分：把主标题放在节点内，副标题或补充说明放在图例里。如果实在需要长文本，可以为节点单独开一个“标注区”，而不是塞进节点框内。

我还遇到过一个典型问题：字号设定过小导致导出图片后文字无法辨认。制图的时候屏幕看着清晰，导出到文档缩放到 50% 后就糊了。设计阶段建议把字号基准放大到 14 到 16 像素，标签字号不低于 12 像素。不要为了塞更多信息而用小于 12 像素的字，那几乎等于在一张印刷图上刻蚊字。

4.3 团队协作时风格分裂

当多人共同维护一套图表时，最容易出现的情况是：A 同事画的图用蓝色表示主模块，B 同事用绿色表示主模块；两周之后，图例都对不上了。解决这个问题的方法就是 3.3 节说的主题变量。把所有颜色、线型、字号放进共享的规范文件，每位成员只引用规范值，不在具体图形里自己发明颜色编号。

我强烈建议在团队内部做一次“规范走查”：把近期产出的所有图表放在一页里对比，标出不一致的地方，例如边框粗细、箭头样式、字体层级、圆角大小，然后在一份文档里统一记录。走查不是做艺术评审，而是找表达语义的矛盾。规范落地的关键不是一次性写完美，而是每次发现问题后把解决方案补进文档，循环更新。

4.4 导出的图在文档里发虚

导出位图时不设置合适的缩放倍数，是文档发虚的直接原因。常规做法是导出为 2 倍图，即设计稿宽度乘以 2。如果图中包含大量细线和小号文字，建议导出 3 倍图。另外还要留意平台是否对上传图片做二次压缩。为了保险，可以把关键信息尽量用大号字体和粗线条呈现，不能假设读者会放大图片去看细节。

4.5 一张图要塞下所有信息

图表篇幅失控是另一个高频问题。当你想表达的内容过多，一张图承载不了时，正确做法是拆图，而不是缩小节点。拆分原则是按“读者需要一个完整的认知单元”来切：在一张架构图里，先给出三端边界和主流程，把每个端点的内部模块细图放到附录或链接文档中。主图承担“总览”功能，子图承担“细节”功能。采用这种二级结构之后，文档的可读性会显著提升。

下面是故障速查表，方便你对照自查：

做图表设计和写代码有一个相似之处：初稿很容易，重构才是常态。把规则预先定好，把重复劳动变成自动化流程，你的精力就可以放在真正有价值的部分——理解和梳理信息关系上。这也是 diagram-design 最终想让你获得的能力。