2026/9/4 9:50:48
FEATURED · 精选文章 
“这里是删掉原来的所有箭头再重做的箭头全是我铺的。”这句话如果出现在需求文档、原型评审或架构方案里它一点也不像是在抱怨反而说明了一个很容易被忽略的事实一张图最重要的部分恰恰是那些没有人愿意一根一根去铺的箭头。在技术协作中“删掉所有箭头再重做”是很高频的动作。很多人以为这是一次纯粹的体力返工是工具用得不熟或者画图的人不够细心。但真正的原因是自动连线虽然能保证“节点之间有边”却不能保证“边在表达业务语义”。节点回答的是“系统里有什么”箭头回答的才是“请求从哪儿来、往哪儿去、谁依赖谁、哪个调用先发生”。后者才是流程、架构、方案评审真正要确认的内容。这篇文章不想停留在“画图要耐心”这种建议上而是想拆清楚三件事第一箭头在语义上到底承担什么角色为什么不能把所有连接都画成同一种实线箭头第二“删掉所有箭头再重做”这个过程应该按什么顺序推进才能避免越铺越乱第三如果连可视化工具的自动布局都无法满足要求手工铺线到底在铺什么、能控制什么。我会从一个可直接运行的 SVG 最小示例出发讲清楚手工铺设路径的原理并给出边关系表、常见问题排查和工程化建议。适合正在画架构图、数据结构图、需求流程图或需要给团队产出可维护图纸的开发者阅读。1. 为什么一张流程图的成败往往在箭头先做一个思维实验把一张完整的系统架构图里所有箭头全部删掉只剩节点和方框。结果通常是两个一是你很难判断谁是上游谁是下游二是很多原本清晰的模块关系会退化成“我不知道它为什么摆在这里”。这说明箭头不是图的装饰而是图的语法。节点可以理解成名词箭头则是动词和连词。一个方框叫“订单服务”另一个方框叫“库存服务”这两个名词放在一张图上时什么结论也得不出来。但当它们之间出现一根箭头并且标注了“扣减库存”之后阅读者才能知道这是一个调用关系。箭头上的方向、虚实、粗细、颜色、标签都在压缩额外信息。如果画图时省略了这些信息图就只能给人一个“大概结构”经不起技术评审。第二个原因是工具的自动布局不会理解业务语义。绝大多数流程图工具里的自动连线本质上是按照图论里“两个节点相邻就生成一条边”的方式工作的。它只能保证节点之间存在连线不会判断这条线是该画成同步调用还是异步回调、主流程还是异常分支、向上返回还是向下流转。自动布局甚至可能出现一条从画面正中穿过去的长线把其他节点全部压住。从图论的角度看这条线没有问题从人的阅读顺序看这张图已经坏了。所以“手动重新铺箭头”不只是为了好看而是为了重新给图建立阅读顺序。一张能被评审的图应该让人在 30 秒内看出主流程从哪开始、到哪结束、中间经过了几个关键节点、哪些是异步补偿。先做到这几件事再谈美观。2. 箭头不是“线”先从语义上分清线的类型很多图的混乱不是因为节点太多而是因为所有关系都画成了同一种实线箭头。一旦删除所有箭头再重做就等于获得了一次重新划分线型的机会。在动手铺线之前建议先约定一套“线型语义”。不必照搬 UML 全部规范但至少要在图例里说明实线、虚线、粗细和箭头方向分别代表什么。下面是一套比较通用的约定可以直接作为团队内部默认规则线型样式语义含义典型例子注意点实线 实心三角箭头同步调用、强依赖、请求写入订单服务调用库存服务扣减库存不要再用它表达异步回调虚线 细箭头异步通知、事件、回调支付网关支付成功后回调订单服务需要配合文字标签说明事件名粗实线 粗箭头主链路、请求主流程主流程从网关到业务再到数据库一张图内尽量不超过一条主链路双向细实线双向会话、互相依赖长连接、双向同步在时序图里建议拆成两条单向线无箭头连线静态从属、配置关联模块依赖、容器挂载尽量少用否则无法阅读方向彩色线异常、失败、降级路径超时、熔断、回滚补偿一般用红/橙色并在图例中说明这张表的核心价值不在于它严谨而在于它让每一条线在画出来之前已经知道自己承担什么职责。很多刚接触绘图的人会认为“虚线”只是一种样式选择其实在架构图和流程图中虚线和实线表达的是完全不同的请求模型。同步调用通常要求调用方等待结果因此用实线表达“强绑定”异步通知发完即返回调用方不会一直阻塞所以用虚线表达“松耦合”。如果二者都用实线箭头阅读者就无法从图面上判断这个接口是 RPC 还是消息事件只能再去看标签或代码。有一个很实用的判断方法每画一根线之前先试着把它的关系写成“谁 做什么动作 到谁那里去”。比如“订单服务 调用 库存服务扣减库存”成立才应该画一根线“订单服务 和 库存服务之间有关系”不成立因为“有关系”不是动作。凡是无法用一句带谓语的话说清楚的连线画上去只会让图更含糊。箭头重做的第一步不是调整坐标而是把这种动词关系全部列出来。如果两个模块之间确实需要双向通信也建议不要画一根双向箭头而是画两条方向相反、语义各自独立的单向箭线。比如“A 发起请求B 返回结果”实际是两个动作。合成一个双向箭头后一旦其中一个动作超时或失败图例上很难标注出差异拆开后则可以把失败、重试、异常放在对应的那条线上。箭头越细粒度图纸越能支撑后续排查。3. “删掉所有箭头再重做”到底在删什么在动手重铺之前首先要意识到删除不是归零而是把“关系”从“位置”中剥离出来。很多图之所以需要把原有箭头全部删掉是因为原来的连线已经污染了阅读者判断。画图的人很容易被旧箭头带偏明明左边有一个节点就把所有出口都拉向左侧标题写着“支付成功回调”线却从“创建订单”的底部穿过去。真正需要保留的不是某条具体折线而是这条折线背后的拓扑关系。节点之间的连接关系可以抽象成一张“边表”它不依赖任何坐标。把旧图清理干净时不要让画布上的节点位置反过来决定流程而要让关系清单决定节点如何摆放。建议按四个阶段推进。第一阶段是盘点。把所有节点和所有应该存在的边写下来先不要打开画布。比如“A 到 B 是同步调用”“B 到 C 是回调”“A 到 D 是失败重试”。只要关系还在删掉多少条线都不伤元气。第二阶段是重置主路径。选择一条能覆盖核心业务的主链路把它横向摆在画布中部。主链路上的节点一次性放完不要中途穿插其他分支。主链路决定了一张图的阅读主轴它应该尽量从左到右或从上到下延续避免回头路。第三阶段是铺设主干线。从主链路第一个节点开始按照调用方向逐个连接。这一步只画主链路涉及的边先不要管异步通知、日志上报、补偿任务等支线。这样做的原因是主链路的走向决定了后续所有支线的锚点错误的锚点会让每条支线都变得扭曲。第四阶段才是补支线。把异步回调、事件通知、异常返回等线放在主链路的下方或两侧尽量让支线与主线形成平行关系避免直接从画面中央斜穿。补线的顺序一般是先同步分支再异步通知最后画失败和回滚路径。这个顺序会让整张图的阅读负担最小化因为最关键的主链路已经提前被固定住了。所以“删掉所有箭头再重做”不是画图效率低下的表现而是一种有意识的重构。真正应该删除的不是“关系”而是旧坐标带来的视觉噪音。只要提前把关系表整理干净重做只是把正确的语义放到正确位置的过程。4. 手工铺箭头通用操作与工具避坑手工铺箭头在不同工具里的叫法不完全一样但底层操作可以归纳成三类选连接方式、定连接点、调折点。先说连接方式。大多数绘图工具允许一条线使用“直线”“折线”“曲线”三种路径。很多新手为了图面柔和一开始就选曲线结果节点密集时曲线会互相缠绕反而更难维护。更稳妥的默认选择是正交折线也就是横平竖直的路径只在需要转弯时出现折点。正交线更符合流程图与架构图的阅读习惯也更容易在后续拖动节点时保持结构稳定。其次是连接点。手工铺线最容易踩的坑是线确实连到了目标节点附近但没有真正吸附到节点的连接端口上。这样的线在静止状态下看起来正常一旦拖动节点就会露出“悬空”或“偏移”的问题。正确做法是从节点边缘的端口拖出连线而不是在节点内部随便点一个位置开始拉线。端口不光是视觉锚点在工具内部它会记录这条边属于哪个节点决定拖动时是否跟随。然后是折点控制。手工铺箭头最灵活的地方在于可以单独移动折点。把一条线段从节点 A 连到节点 B 之后不是只能等它自动生成路径而是可以拖动中间线段增加或删除折点让线从其他节点的空隙中穿过。折点数量不是越多越好。大多数情况下两条正交折线就能跨过一片区域折点太多阅读时视线会在线上打很多个结。如果出现一条线需要五次以上的折弯才能避开其他节点那不是这条线的问题而是布局没有排好。以 draw.io、ProcessOn 等常见工具为例需要掌握的关键动作包括选中连线后拖动虚线中间段可以整体平移该段双击连线可以插入新的折点按删除键可以把折点收回去在“样式”面板里可以统一修改颜色、线宽、虚线样式和箭头端点。不同工具菜单位置不同但这些基础能力都很接近。需要注意的是不要一上来就启用“自动重排路径”一类的功能。它会在节点被拖动时尝试自己重新规划整条线当你希望保留手工铺的路径时它会成为最大的干扰项。手工铺线还有一个需要练习的细节就是入口与出口方向。理想情况是一个节点的主入口放在左侧主出口放在右侧异常返回从下方走出异步通知从上方或右侧的独立端口发出。每一条线在进入下一个节点时应该尽量垂直或水平地“戳”到端口上而不是斜着插入。斜线看起来一时省事但当图上有几十条线时斜向交叉会迅速摧毁可读性。手工铺箭头的核心目标不是“让线更艺术”而是“让线更守规矩”。5. 铺线之前先用一张“边关系表”校准依赖当节点超过十个、连接达到二三十条时单纯靠肉眼判断“该先铺哪根线”很容易出错。更稳妥的方式是在动手之前先维护一张边关系表把图画语义先固定下来。下面的表格示例可以在需求评审和画图前作为草稿使用。每一行代表一条边字段包括起止节点、动作语义、线型、是否属于主链路。这张表比图更适合被 diff因为它只描述依赖关系不包含坐标和样式噪声。顺序起始节点目标节点动作语义线型主链路1订单服务库存服务扣减库存实线箭头是2支付服务订单服务支付结果回调虚线箭头否3订单服务优惠券服务发放优惠券虚线箭头否为了让关系表更容易被程序处理可以把它写成 CSV 或者 JSON。比如 CSV 版本适合在 Excel 里编辑JSON 版本适合作为以后接入流程图引擎的数据源。from,to,action,arrow_type,main_path 订单服务,库存服务,扣减库存,sync,true 支付服务,订单服务,支付结果回调,async,false 订单服务,优惠券服务,发放优惠券,async,falseJSON 版本可以把更多属性带上比如颜色、路由方式、是否需要绕过节点、标签文字等[ { id: e1, from: order, to: stock, action: 扣减库存, type: sync, main: true }, { id: e2, from: pay, to: order, action: 支付结果回调, type: async, main: false }, { id: e3, from: order, to: coupon, action: 发放优惠券, type: async, main: false } ]这样一张表最有价值的地方在于它把“画图”变成“填边”。评审时可以先看这张表确认方向、线型、主链路是否正确再看图里的颜色和坐标。否则评审者很容易被一张布局精致的图带着走而忽略真正重要的语义问题这条回调到底是不是异步的那条失败路径为什么没有出现在图上有了边表之后铺线的顺序也就很清晰了。先把maintrue的同步调用线全部铺完形成主链路再把其他同步分支逐条铺上去最后铺异步虚线。如果边表里出现了环比如 A 依赖 B、B 依赖 A就要在铺线前先讨论清楚这是不是循环依赖。不要在图上直接画一个回路试图表达它因为图上的回路只是视觉结果并不会帮助你判断依赖是否合理。6. 能灵活控制的手工箭头一个直接运行的 SVG 示例流程图的连接线最终都可以抽象成一条带端点的路径。可视化工具里的“自动路由”只是在自动生成这条路径的坐标手工铺箭头就是由人工直接决定这条路径经过哪里、从哪里拐弯、箭头落在哪个方向。为了把这个原理看清楚可以用一段 SVG 代码做一个最小示例。下面这个文件模拟了三条关键路径主链路从“创建订单”到“支付成功”是一条同步实线支付成功后到“异步通知”是一条异步虚线。箭头样式由一个marker统一声明路径本身则用path的d属性指定贝塞尔控制点这就是手工铺线的最小形态。文件路径manual-arrow.html!DOCTYPE html html langzh-CN head meta charsetUTF-8 / title手工铺设箭头示例/title style body { font-family: Microsoft YaHei, Arial, sans-serif; background: #fafbfc; } .node text { font-size: 14px; fill: #1f
架构图与流程图中的箭头：手工铺设路径的工程化方法
“这里是删掉原来的所有箭头再重做的箭头全是我铺的。”这句话如果出现在需求文档、原型评审或架构方案里它一点也不像是在抱怨反而说明了一个很容易被忽略的事实一张图最重要的部分恰恰是那些没有人愿意一根一根去铺的箭头。在技术协作中“删掉所有箭头再重做”是很高频的动作。很多人以为这是一次纯粹的体力返工是工具用得不熟或者画图的人不够细心。但真正的原因是自动连线虽然能保证“节点之间有边”却不能保证“边在表达业务语义”。节点回答的是“系统里有什么”箭头回答的才是“请求从哪儿来、往哪儿去、谁依赖谁、哪个调用先发生”。后者才是流程、架构、方案评审真正要确认的内容。这篇文章不想停留在“画图要耐心”这种建议上而是想拆清楚三件事第一箭头在语义上到底承担什么角色为什么不能把所有连接都画成同一种实线箭头第二“删掉所有箭头再重做”这个过程应该按什么顺序推进才能避免越铺越乱第三如果连可视化工具的自动布局都无法满足要求手工铺线到底在铺什么、能控制什么。我会从一个可直接运行的 SVG 最小示例出发讲清楚手工铺设路径的原理并给出边关系表、常见问题排查和工程化建议。适合正在画架构图、数据结构图、需求流程图或需要给团队产出可维护图纸的开发者阅读。1. 为什么一张流程图的成败往往在箭头先做一个思维实验把一张完整的系统架构图里所有箭头全部删掉只剩节点和方框。结果通常是两个一是你很难判断谁是上游谁是下游二是很多原本清晰的模块关系会退化成“我不知道它为什么摆在这里”。这说明箭头不是图的装饰而是图的语法。节点可以理解成名词箭头则是动词和连词。一个方框叫“订单服务”另一个方框叫“库存服务”这两个名词放在一张图上时什么结论也得不出来。但当它们之间出现一根箭头并且标注了“扣减库存”之后阅读者才能知道这是一个调用关系。箭头上的方向、虚实、粗细、颜色、标签都在压缩额外信息。如果画图时省略了这些信息图就只能给人一个“大概结构”经不起技术评审。第二个原因是工具的自动布局不会理解业务语义。绝大多数流程图工具里的自动连线本质上是按照图论里“两个节点相邻就生成一条边”的方式工作的。它只能保证节点之间存在连线不会判断这条线是该画成同步调用还是异步回调、主流程还是异常分支、向上返回还是向下流转。自动布局甚至可能出现一条从画面正中穿过去的长线把其他节点全部压住。从图论的角度看这条线没有问题从人的阅读顺序看这张图已经坏了。所以“手动重新铺箭头”不只是为了好看而是为了重新给图建立阅读顺序。一张能被评审的图应该让人在 30 秒内看出主流程从哪开始、到哪结束、中间经过了几个关键节点、哪些是异步补偿。先做到这几件事再谈美观。2. 箭头不是“线”先从语义上分清线的类型很多图的混乱不是因为节点太多而是因为所有关系都画成了同一种实线箭头。一旦删除所有箭头再重做就等于获得了一次重新划分线型的机会。在动手铺线之前建议先约定一套“线型语义”。不必照搬 UML 全部规范但至少要在图例里说明实线、虚线、粗细和箭头方向分别代表什么。下面是一套比较通用的约定可以直接作为团队内部默认规则线型样式语义含义典型例子注意点实线 实心三角箭头同步调用、强依赖、请求写入订单服务调用库存服务扣减库存不要再用它表达异步回调虚线 细箭头异步通知、事件、回调支付网关支付成功后回调订单服务需要配合文字标签说明事件名粗实线 粗箭头主链路、请求主流程主流程从网关到业务再到数据库一张图内尽量不超过一条主链路双向细实线双向会话、互相依赖长连接、双向同步在时序图里建议拆成两条单向线无箭头连线静态从属、配置关联模块依赖、容器挂载尽量少用否则无法阅读方向彩色线异常、失败、降级路径超时、熔断、回滚补偿一般用红/橙色并在图例中说明这张表的核心价值不在于它严谨而在于它让每一条线在画出来之前已经知道自己承担什么职责。很多刚接触绘图的人会认为“虚线”只是一种样式选择其实在架构图和流程图中虚线和实线表达的是完全不同的请求模型。同步调用通常要求调用方等待结果因此用实线表达“强绑定”异步通知发完即返回调用方不会一直阻塞所以用虚线表达“松耦合”。如果二者都用实线箭头阅读者就无法从图面上判断这个接口是 RPC 还是消息事件只能再去看标签或代码。有一个很实用的判断方法每画一根线之前先试着把它的关系写成“谁 做什么动作 到谁那里去”。比如“订单服务 调用 库存服务扣减库存”成立才应该画一根线“订单服务 和 库存服务之间有关系”不成立因为“有关系”不是动作。凡是无法用一句带谓语的话说清楚的连线画上去只会让图更含糊。箭头重做的第一步不是调整坐标而是把这种动词关系全部列出来。如果两个模块之间确实需要双向通信也建议不要画一根双向箭头而是画两条方向相反、语义各自独立的单向箭线。比如“A 发起请求B 返回结果”实际是两个动作。合成一个双向箭头后一旦其中一个动作超时或失败图例上很难标注出差异拆开后则可以把失败、重试、异常放在对应的那条线上。箭头越细粒度图纸越能支撑后续排查。3. “删掉所有箭头再重做”到底在删什么在动手重铺之前首先要意识到删除不是归零而是把“关系”从“位置”中剥离出来。很多图之所以需要把原有箭头全部删掉是因为原来的连线已经污染了阅读者判断。画图的人很容易被旧箭头带偏明明左边有一个节点就把所有出口都拉向左侧标题写着“支付成功回调”线却从“创建订单”的底部穿过去。真正需要保留的不是某条具体折线而是这条折线背后的拓扑关系。节点之间的连接关系可以抽象成一张“边表”它不依赖任何坐标。把旧图清理干净时不要让画布上的节点位置反过来决定流程而要让关系清单决定节点如何摆放。建议按四个阶段推进。第一阶段是盘点。把所有节点和所有应该存在的边写下来先不要打开画布。比如“A 到 B 是同步调用”“B 到 C 是回调”“A 到 D 是失败重试”。只要关系还在删掉多少条线都不伤元气。第二阶段是重置主路径。选择一条能覆盖核心业务的主链路把它横向摆在画布中部。主链路上的节点一次性放完不要中途穿插其他分支。主链路决定了一张图的阅读主轴它应该尽量从左到右或从上到下延续避免回头路。第三阶段是铺设主干线。从主链路第一个节点开始按照调用方向逐个连接。这一步只画主链路涉及的边先不要管异步通知、日志上报、补偿任务等支线。这样做的原因是主链路的走向决定了后续所有支线的锚点错误的锚点会让每条支线都变得扭曲。第四阶段才是补支线。把异步回调、事件通知、异常返回等线放在主链路的下方或两侧尽量让支线与主线形成平行关系避免直接从画面中央斜穿。补线的顺序一般是先同步分支再异步通知最后画失败和回滚路径。这个顺序会让整张图的阅读负担最小化因为最关键的主链路已经提前被固定住了。所以“删掉所有箭头再重做”不是画图效率低下的表现而是一种有意识的重构。真正应该删除的不是“关系”而是旧坐标带来的视觉噪音。只要提前把关系表整理干净重做只是把正确的语义放到正确位置的过程。4. 手工铺箭头通用操作与工具避坑手工铺箭头在不同工具里的叫法不完全一样但底层操作可以归纳成三类选连接方式、定连接点、调折点。先说连接方式。大多数绘图工具允许一条线使用“直线”“折线”“曲线”三种路径。很多新手为了图面柔和一开始就选曲线结果节点密集时曲线会互相缠绕反而更难维护。更稳妥的默认选择是正交折线也就是横平竖直的路径只在需要转弯时出现折点。正交线更符合流程图与架构图的阅读习惯也更容易在后续拖动节点时保持结构稳定。其次是连接点。手工铺线最容易踩的坑是线确实连到了目标节点附近但没有真正吸附到节点的连接端口上。这样的线在静止状态下看起来正常一旦拖动节点就会露出“悬空”或“偏移”的问题。正确做法是从节点边缘的端口拖出连线而不是在节点内部随便点一个位置开始拉线。端口不光是视觉锚点在工具内部它会记录这条边属于哪个节点决定拖动时是否跟随。然后是折点控制。手工铺箭头最灵活的地方在于可以单独移动折点。把一条线段从节点 A 连到节点 B 之后不是只能等它自动生成路径而是可以拖动中间线段增加或删除折点让线从其他节点的空隙中穿过。折点数量不是越多越好。大多数情况下两条正交折线就能跨过一片区域折点太多阅读时视线会在线上打很多个结。如果出现一条线需要五次以上的折弯才能避开其他节点那不是这条线的问题而是布局没有排好。以 draw.io、ProcessOn 等常见工具为例需要掌握的关键动作包括选中连线后拖动虚线中间段可以整体平移该段双击连线可以插入新的折点按删除键可以把折点收回去在“样式”面板里可以统一修改颜色、线宽、虚线样式和箭头端点。不同工具菜单位置不同但这些基础能力都很接近。需要注意的是不要一上来就启用“自动重排路径”一类的功能。它会在节点被拖动时尝试自己重新规划整条线当你希望保留手工铺的路径时它会成为最大的干扰项。手工铺线还有一个需要练习的细节就是入口与出口方向。理想情况是一个节点的主入口放在左侧主出口放在右侧异常返回从下方走出异步通知从上方或右侧的独立端口发出。每一条线在进入下一个节点时应该尽量垂直或水平地“戳”到端口上而不是斜着插入。斜线看起来一时省事但当图上有几十条线时斜向交叉会迅速摧毁可读性。手工铺箭头的核心目标不是“让线更艺术”而是“让线更守规矩”。5. 铺线之前先用一张“边关系表”校准依赖当节点超过十个、连接达到二三十条时单纯靠肉眼判断“该先铺哪根线”很容易出错。更稳妥的方式是在动手之前先维护一张边关系表把图画语义先固定下来。下面的表格示例可以在需求评审和画图前作为草稿使用。每一行代表一条边字段包括起止节点、动作语义、线型、是否属于主链路。这张表比图更适合被 diff因为它只描述依赖关系不包含坐标和样式噪声。顺序起始节点目标节点动作语义线型主链路1订单服务库存服务扣减库存实线箭头是2支付服务订单服务支付结果回调虚线箭头否3订单服务优惠券服务发放优惠券虚线箭头否为了让关系表更容易被程序处理可以把它写成 CSV 或者 JSON。比如 CSV 版本适合在 Excel 里编辑JSON 版本适合作为以后接入流程图引擎的数据源。from,to,action,arrow_type,main_path 订单服务,库存服务,扣减库存,sync,true 支付服务,订单服务,支付结果回调,async,false 订单服务,优惠券服务,发放优惠券,async,falseJSON 版本可以把更多属性带上比如颜色、路由方式、是否需要绕过节点、标签文字等[ { id: e1, from: order, to: stock, action: 扣减库存, type: sync, main: true }, { id: e2, from: pay, to: order, action: 支付结果回调, type: async, main: false }, { id: e3, from: order, to: coupon, action: 发放优惠券, type: async, main: false } ]这样一张表最有价值的地方在于它把“画图”变成“填边”。评审时可以先看这张表确认方向、线型、主链路是否正确再看图里的颜色和坐标。否则评审者很容易被一张布局精致的图带着走而忽略真正重要的语义问题这条回调到底是不是异步的那条失败路径为什么没有出现在图上有了边表之后铺线的顺序也就很清晰了。先把maintrue的同步调用线全部铺完形成主链路再把其他同步分支逐条铺上去最后铺异步虚线。如果边表里出现了环比如 A 依赖 B、B 依赖 A就要在铺线前先讨论清楚这是不是循环依赖。不要在图上直接画一个回路试图表达它因为图上的回路只是视觉结果并不会帮助你判断依赖是否合理。6. 能灵活控制的手工箭头一个直接运行的 SVG 示例流程图的连接线最终都可以抽象成一条带端点的路径。可视化工具里的“自动路由”只是在自动生成这条路径的坐标手工铺箭头就是由人工直接决定这条路径经过哪里、从哪里拐弯、箭头落在哪个方向。为了把这个原理看清楚可以用一段 SVG 代码做一个最小示例。下面这个文件模拟了三条关键路径主链路从“创建订单”到“支付成功”是一条同步实线支付成功后到“异步通知”是一条异步虚线。箭头样式由一个marker统一声明路径本身则用path的d属性指定贝塞尔控制点这就是手工铺线的最小形态。文件路径manual-arrow.html!DOCTYPE html html langzh-CN head meta charsetUTF-8 / title手工铺设箭头示例/title style body { font-family: Microsoft YaHei, Arial, sans-serif; background: #fafbfc; } .node text { font-size: 14px; fill: #1f 
