企业官网建设流程全解析

1. 先把“diagram-design”拆透

1.1 图表设计到底管的哪几摊事

上个月评审一个订单系统的改造方案，我对着PPT里那张架构图看了快十分钟，愣是没看出来调用链是从上往下走还是从右往左绕。讲的人说得口干舌燥，底下人越听越迷糊。散会之后我就在想，问题根本不在于方案本身，而在于那张图。信息都在，关系全乱。这就是典型的“会做系统但不会画图”。

“diagram-design”这个词拆开看就是图表设计。但这里说的不是让图表变得好看那么简单，而是让一张图真正承担起“沟通语言”的职责。在我接触过的团队里，技术方案、业务流程、数据结构、部署拓扑、项目排期，几乎每个环节都逃不过图表。画图这件事的门槛极低，用Word画个矩形加箭头也叫图，但那种图只能证明“画过”，不能证明“讲清楚”。

图表设计本质上干的是三件事：第一，把复杂系统的结构关系可视化，让人一眼看懂模块边界和数据流向；第二，把流程中的分支、判断、异常路径梳理清楚，避免口头沟通时各自脑补；第三，把设计决策和演进过程沉淀成文档资产，后面新人接手、架构评审、故障复盘全都用得上。

我在实际工作中见过太多反面教材——流程图里箭头乱飞、架构图上的框大小不一、时序图的消息编号对不上、ER图的关联字段写错。这些问题归根结底不是工具的问题，而是没有一套统一的图表设计规范。好的diagram-design，应该让团队里任何人拿起图都能在30秒内抓住重点。

1.2 一个项目里的图表角色

如果你以为图表设计只是“画架构图”，那就把这件事想窄了。一个完整的软件项目，从需求到上线，至少要经历好几类图表，每种的侧重点完全不同。

第一类是流程类图表，典型代表是业务流程图、状态机图、活动图。这类图的核心是表达“时间顺序”和“条件分支”，比如用户下单后，订单状态从“待支付”到“已支付”再到“已发货”，中间有哪些校验、超时、异常回滚。画这类图的难点在于边界条件，很多新人画流程只画主流程，分支全都漏掉。

第二类是结构类图表，典型代表是系统架构图、模块依赖图、目录结构图。这类图的核心是表达“空间关系”和“层级关系”，比如前端、网关、服务层、数据层之间的调用关系。架构图最容易犯的毛病是“什么都往一张图里塞”，把部署细节、代码细节、配置细节全画进去，最后变成一张谁也看不懂的蜘蛛网。

第三类是数据类图表，典型代表是ER图、类图、数据流图。这类图服务于数据结构设计，核心是表达“实体之间的关系”——一对一、一对多、多对多，主外键对应关系、索引策略。很多人觉得画ER图就是把表结构截图贴上去，实际上ER图的价值在于暴露设计问题，比如循环引用、字段冗余、缺失唯一约束。

第四类是时序类图表，典型代表是时序图、甘特图、泳道图。时序图对协作系统尤其重要，因为它能表达“消息在多个组件之间的传递顺序”，排查线上问题的时候，一张准确的时序图比看半天日志管用得多。

所以“diagram-design”不是某一种绘图技巧，而是一套覆盖“流程—结构—数据—时序”的方法论。你在不同阶段需要调用的图表能力完全不同，想靠一个模板通吃所有场景，基本不可能。

2. 图表设计的基本原则，踩过坑才记得住

2.1 层级先行，信息才有主次

画图最容易犯的错误，是动手就画。拿到需求之后直接拉个框、连根线，画到一半发现信息放不下，又开始删。这个习惯必须改。所有高信息密度的图表，第一步永远是“确定层级”。

什么是层级？就是一张图中哪些信息是主骨架，哪些是细节补充，哪些是完全不用上图的边角料。我自己常用的方法是在画图前先列一个信息清单，把所有要表达的内容写出来，然后逐个打标：A类是画面上必须一眼看到的，B类是支撑A类细节、可以就近注明，C类属于背景信息、放在文档正文或者注释里，根本不需要上图。

定层级背后的逻辑是“读图者的注意力是稀缺资源”。一张图上如果同时出现10个重点，实际上等于没有重点。我在评审会上观察过很多次，架构图上最显眼的往往不是核心链路，而是配色最花哨的那个模块。信息层级一旦失控，图就变成了装饰品。

操作上我建议先画“骨架图”，只放主流程或主结构，画完之后退后一步盯着看，问自己一个问题：不看任何标注，能不能说出这张图的主角是谁？如果答案是模糊的，就先不要加细节，而是先把骨架调清楚。很多图之所以乱，不是细节太多,而是骨架本身就是歪的。骨架定下来了，再往里填血肉。

2.2 颜色和字体控制，克制才是专业

颜色是diagram-design里最容易被滥用，也最容易被忽视的一环。很多项目图表看起来“脏”，90%的原因出在颜色上。老话讲“少即是多”，这在图表配色上体现得尤其明显。

我常用的配色方案是给图表场景定义一套“语义色系”——主色用来画核心模块，辅助色用来画依赖模块，强调色只用来标异常或重点路径，中性色用来做背景和辅助框。颜色不超过5种，重色的面积控制在画面的30%以内。很多工具都自带调色板，但我建议不要直接用默认色，那套配色在PPT投到投影仪上几乎必翻车。我自己整理了一套在深色浅色背景下都能用的色值组合，深色背景用浅色描边，浅色背景用深色文字，整体对比度保证在4.5:1以上。

字体的坑比颜色更隐蔽。不同操作系统、不同浏览器对字体的渲染差异巨大，在Windows上看着正常的宋体，换到Mac上就可能错位；draw.io里保存的字体，导出PNG后到了同事电脑上变成默认字体，直接导致框内文字溢出。这个问题我踩过好几次，现在的规范是：国内团队默认用“微软雅黑+Consolas”组合，英文和代码用Consolas，中文用微软雅黑；如果团队跨平台，就统一用“PingFang SC + Inter”，并在导出时把字体嵌入。还有一个容易被忽略的点：字号层级。标题、模块名、说明文字、连线标签，至少要分出3档字号，最大和最小之间保持1.5到2倍差距，这样读图的人才能快速分清主次。

2.3 布局与连接线，决定“读图”的顺不顺

如果说层级是骨架、颜色是皮肤，那布局和连接线就是肌肉和血管。一张图读起来费不费劲，很大程度上取决于走线和布点的合理性。

先说布局。常规图表的信息流方向应该遵循“左上到右下”的阅读习惯，除非特殊场景，否则不要制造反直觉的流向。分层架构图从上往下画，第一层是入口、第二层是应用、第三层是服务、第四层是存储；业务流程从左往右画，步骤编号顺着走。模块之间保持统一间距，我习惯用8的倍数作为间距基准，比如模块间最小留白16px、组间间距32px。这样画面会呈现出一种隐蔽的节奏感，读者看着舒服，但又说不清为什么舒服。

连接线是最难处理的环节。交叉线是图表乱的最主要原因，两条线交叉一次可以忍，超过三次基本就废了。减少交叉的方法有几个：第一，把关联紧密的模块靠近摆放，从源头缩短线的长度；第二，允许连接线走“L形”或“Z形”，而不是硬拉斜线；第三，用容器（泳道、虚线框）把同一层级的模块包起来，减少跨区域连线；第四，如果连线实在太多，果断改为“编号+说明”的方式，在图上标①②③，下面统一注释对应关系。

箭头方向必须统一，永远表示“调用方指向被调用方”或“数据流向目标”。最怕的就是一张图里有些箭头表示依赖、有些箭头表示数据流，读者理解成本极高。正确的做法是在图的左下角加一个“图例说明”——不是形式主义，而是让看图的人不用猜。图例内容就三样：箭头含义、颜色含义、边框样式含义。三行字能省掉一屋子人十分钟的困惑。

3. 工具选型：没有万能工具，只有合适场景

3.1 主流工具的优缺点对比

聊完设计原则，绕不开工具选型。我见过不少团队为了“统一工具”争得面红耳赤——用Visio的觉得draw.io不专业，用Figma的觉得ProcessOn太简陋，用PlantUML的觉得图形化工具不好做版本管理。其实这些争论没什么意义，工具的终极目标就一条：用最低的成本画出符合设计规范的图，并且让协作尽可能顺畅。

我用过一个比较完整的工具链，覆盖不同场景，这里直接列个对比供参考。

真实情况是：工具本身不会让你的图变好，就像好笔不能让字变好一样。但选对工具能显著降低你执行设计规范的摩擦力。如果规范要求的间距、字体、颜色在工具里改起来非常费劲，那大概率坚持不下来。

3.2 我的选型组合建议

在目前实际项目中，我采取的是“双轨制”组合。基础绘图用draw.io，因为它免费、开源、文件是纯XML格式，可以直接存进Git仓库做版本管理。评审的时候打开历史版本看演进记录非常方便。时序图、类图这一类偏代码思维的图，我用PlantUML生成——尤其是消息链路复杂的时序图，手工拖线根本拖不清楚，用代码画反而精确，但这类图有一个弊端，就是“画出来的图不由你控制”。PlantUML会根据代码自动布局，改一行代码整个图的位置就全变了，想微调非常困难。所以它适合“生成一次看整体”的快速验证，不适合作为交付级的成稿工具。

Excalidraw是我用来做方案预沟通的——画个草图跟产品聊需求，手写风格天然带着一种“还没定稿”的暗示，对方会更愿意提意见，很小的成本就能换来更充分的讨论。正式的架构图、交付级流程图，我会在draw.io里精修。

这里有一个特别重要的建议：工具可以混用，但最终交付的图必须风格统一。我见过一个团队，架构师用draw.io画底座、后端用PlantUML画时序、前端用Figma画交互，最后拼到文档里花花绿绿，字体字号完全没法看。妥协的办法是约定“最终合稿工具”，所有图表统一到工具A里合稿，再导出。或者更先进一点的做法：用文本绘图工具的画图代码，然后导入到draw.io里二次精修，两种工具的优势兼得。

4. 实操复盘：从零画一张系统架构图

4.1 先定画布、再定标准

交代一下背景：最近在做一个订单中台的架构梳理，老王（架构师）想用一张图把前端、网关、订单服务、库存服务、支付服务、消息队列、数据库、缓存的关系一次讲清楚。这张图如果要画好，必须做diagram-design，不能随手拉框。

第一步不是打开draw.io，而是定标准和画布。我在项目里整理了一套团队通用的架构图规范，直接套用到这次的图上。画布尺寸我习惯先用1920px宽的横向画布，后续根据内容增减再调整。然后定义网格“吸附尺寸”，draw.io里可以设置网格为8px，这样所有框的尺寸、间距自动落在8的倍数上。图层名称的字体设为12px，模块名14px，大标题20px，都统一用微软雅黑。配色按前面说的语义色系走：背景用浅灰（#FAFAFA）、容器边框用深灰（#555555）、核心模块用暖色填充（#FFF3E0）、边缘模块用冷色（#E3F2FD）、异常节点用红色描边（#D32F2F）。

这套定义花10分钟，但能让后续一个半小时的画图过程变得非常省心。你可以理解为：“先修路，再开车”。没定规则之前画的图，后面返工成本远超你省下的那点“前摇时间”。

4.2 分层堆内容，先骨架后血肉

架构图的骨架分四层：入口层、应用层、服务层、数据层。我在画布上先画了四条横向泳道，按比例分配高度——入口层占10%、应用层占25%、服务层占45%、数据层占20%。为什么服务层最高？因为这个图的主角是订单核心链路，业务逻辑都在服务层，空间不够后面加框很痛苦。

入口层放了三种客户端：小程序、H5、App。应用层放了API网关和BFF层（Backend For Frontend），这两块用虚线框圈在一起，表示它们是同一部署单元。服务层是重点，我画了订单服务、库存服务、支付服务、用户服务、消息服务五个模块。数据层画了MySQL主库、Redis缓存、ES索引库、MQ消息队列四类存储组件。

这里有一个实操细节你一定会遇到：draw.io默认新建的矩形大小不一，手动拖拽很难对齐。我的方法是全部用“编辑数据”面板统一设置宽度和高度，比如服务层模块统一设为280px宽、72px高，间距对齐到网格。业务模块之间要表达依赖关系时，不直接画箭头先画“锚点连接”，把每个模块的出边点和入边点固定好，系统会根据锚点自动绕线，这个功能在draw.io里叫“固定连接点”，画复杂连线之前务必打开。

连线的标签是另一个重点。每根线上必须标注调用方式：HTTP、RPC、MQ消息、异步回调，否则看图的人根本不知道链路里哪些是同步阻塞、哪些是异步解耦。我在这张图里用实线表示同步调用、虚线表示异步消息、点划线表示回调，标签写到线的中段，方向箭头指向被调用方。

4.3 检查与导出，细节决定交付质量

图画完不等于交付，还差“检查”和“导出”两步，这两步做不好，前面的规范全白费。

检查的第一步是“连线无交叉验证”。我简化掉图中两条跨层连接线，把直接连DB的调用改为“经过DAO层再连库”，这不仅让图更规范，也把架构中已经存在的封装逻辑表达出来了。连完线之后放大到200%逐块检查，重点看锚点位置是否对齐、标签是否压在线上、虚线边框的描边是否在导出后被吞掉。

检查完还有一步“信息核对”，在图上找出不明确的地方做标注：比如订单服务连接Redis那条线，我加了“缓存订单状态，TTL=30min”的注释，支付回调那条线标注了“幂等校验，失败重试三次”。这些小注记让图不仅表达结构，同时嵌入关键决策，一张图直接可以当设计文档用。

导出设置里最容易踩坑的两个点：第一，导出PNG时分辨率调成2x，否则放在高清屏上看全是锯齿；第二，导出前在“文件—属性”里把画布调整为“适应内容”，否则图周围会留一大圈空白。如果需要放进Markdown文档，我建议导出SVG而不是PNG，SVG是矢量格式，文档里放大不糊，而且体积小得多。最后再把文件另存为一份.xml版本提交到Git仓库，方便后续按版本追溯变更。

5. 常见问题与排查技巧实录

5.1 布局总是乱，怎么治

布局乱是所有图表项目的头号杀手，而且通常不是一处乱，越改越乱。最常见的场景是：画到一半发现还有模块没放进去，于是硬塞，结果把整个布局顶歪了。

治“乱”要分两种情况。一种是布局过程中就发现要乱了，不要幻想后面能自然对齐，立即停手，选定一个“基准模块”重新排。基准模块一般是图中最核心的那个，比如订单服务。我习惯了先拖一个600px宽的主区域当容器，把所有核心模块放进去，子模块再内部排。外部模块一律往两边放，绝不往里挤。这样即使增加内容，也是新增外挂模块，不会牵动核心区域。

另一种情况是整体看着还行，但部分区域比较拥挤。这时候优先调整布局方向，而不是缩小模块尺寸。架构图从“上下结构”改成“左右结构”往往能救活一张溢出边界的图；流程图方向调整后，可以大大降低多分支带来的视觉混乱。另一个容易被忽略的招数：允许“重复出现”。如果A和B两个模块在图中多处关联，可以把A的一个引用副本放在B旁边，用虚线框标注“参照A”，而不是拉一根横穿全图的长线。这不算偷懒，反而是一种可读性极好的表达方式。

5.2 字体、坐标、导出“三件套”问题

在diagram-design的实操中，有 “字体、坐标、导出”三个高频问题，我单独拎出来说说。

字体问题的经典场景：在draw.io里用“微软雅黑”画好了图，发给同事之后对方打开发现字体全变了，模块里的文字溢出框外。大部分原因是他电脑上没装这个字体，渲染器自动替换了。解决方式有两种——要么导出时不依赖对方的本地字体，全部转曲线（draw.io没有直接转曲线功能，但可以把文字导出成图片；FontLab等工具则自带转轮廓功能）；要么在团队内统一一个跨平台字体。我们在实测中发现“思源黑体”的跨平台兼容性比较好，但文件会比微软雅黑大。如果图简单，最省心的做法是“端到端图片化”交付——直接导出PNG/SVG给对方，不传源文件。

坐标问题的本质是“锚点错位”。在旧版draw.io里复制粘贴模块时连接锚点会丢失，导致后续连线对准的位置五花八门，看起来歪歪扭扭。排查方法是：选中模块打开“编辑数据”面板，确认坐标数值是整数（没有0.5这种小数），一口气统一修正后再连线。如果一整排模块水平错位，直接全选后使用“对齐—顶端对齐”，再用“分布—水平等距”，两张操作基本能解决80%的坐标乱象。

导出问题更多出现在“PNG白边”和“SVG字体丢失”。PNG导出时务必勾选“包含画布背景”，否则透明背景在某些文档主题下会变黑；SVG导出后字体可能被替换，因为SVG本质是XML，它记录了“字体名称”而不是字形。别人电脑上没有这个字体时，SVG打开就会降级渲染。最稳妥的方案：如果图里字体是核心表达元素，导出SVG时把文字转成路径（draw.io里“编辑—全选—形状—选中图层—转换为路径”），代价是文件变大且后续编辑不便，所以只在最终交付时用。

5.3 多人协作时最容易踩的坑

团队协作画图，最大的坑不是画得不好看，而是“各画各的，互相覆盖”。draw.io免费版没有多人同时编辑能力，以前我们两个人同时改一个文件，后保存的人把先保存的人的改动全冲掉，白白返工一小时。现在我的协作方法是：

• 软实时协作类（需要多人同时操作）：用ProcessOn或Figma的图形工具，能实时看到别人拖拽。适合头脑风暴环节，但规范的执行度会差一些。
• 版本管理类（需要追溯和评审）：用draw.io的.xml文件存Git，配合分支管理，每次修改走Merge Request，评审意见直接挂在文件diff上。

一个问题：Git的diff对XML文件其实不友好，文件里任何一个小矩形坐标变动，整段跟随变化，review起来很痛苦。我们折中方案是维护一个“图上变更摘要”：画图的人在每次提交时附带一张截图对比图，评审人直接看图片，不用看xml diff。这个做法让协作效率翻倍。

还有几个必须提前约定的协作规范，否则团队越大越乱：图层命名格式统一（比如“01-入口层”“02-应用层”）；每个模块必须带owner标签（可以是负责人名字），后面有人改图知道该找谁确认；画布右下角放“变更记录表”，列出日期、修改人、修改点摘要，每次改完更新一行。这些约定看上去啰嗦，实际省下的沟通成本远超执行成本。

6. 关于diagram-design的最后唠叨

做了这么多年图，我的体会是：diagram-design的瓶颈从来不在手上，而在脑子里。很多人以为画不好图是工具不熟、模板不多，实际上是对要表达的内容理解不够深，或者理解了但不知道怎么取舍。

这里分享一个我一直沿用的判断标准：一张图如果拿掉所有文字标注，仅凭图形本身就能让人看明白主要结构和流向，这张图就及格了；如果还能让人看出哪些是主链路、哪些是旁路分支、哪里可能有性能瓶颈，那这张图就是优秀的。能用一张图说明白的事，绝对不用三页PPT。

最后一个小技巧：每张图定稿之前，花两分钟做一次“电梯测试”——假设你在电梯里遇到一个刚加入项目的同事，给他看图，只给他15秒，然后请他复述他看到了什么。如果复述结果和你想要传达的核心信息基本一致，这张图的diagram-design就成功了。如果不能，哪怕技术上再精妙，都得改。因为图的终极目的是沟通，不是自我表达，这一点到什么时候都不会变。