企业官网建设流程全解析

画架构图这件事，说大不大，说小不小。平时做系统设计、技术方案汇报，总得画几张结构清晰的图把思路讲明白，代码写多了你会发现，所谓“diagram-design”其实不只是把方块和箭头摆在一起，而是如何把一个复杂的结构体系统一、低损耗地可视化出来。市面上的绘图工具要么模板风格跟团队规范对不上，要么数据管控自由度不够，用久了总想自己做一个。身边不少做低代码平台、可视化大屏的技术团队，最后都走上了自研绘图引擎这条路。这篇就拿我做过的一个架构图编辑器项目当样本，从坐标系设计、图形对象建模、拖拽连线到导出高清图片，把从零实现一个Web版图表编辑器的技术路径和踩坑经历完整拆给你看，想自己写绘图工具的同学可以直接拿去当蓝本。

1. 项目定位与核心设计思路

1.1 为什么“画图工具”要自己造

先说说痛点。很多人觉得现成的在线绘图工具已经够用了，但真正用一段时间就会发现几个绕不过去的问题。

第一是风格统一难。你会发现在一个团队里，每个人画出来的架构图风格都不太一样：有人喜欢圆角矩形，有人用六边形表示中间件，有人把数据库画成一摞圆柱。如果用通用工具，就得手动维护一套素材库和规范文档，还挡不住有人偷懒乱画。如果自己做一个编辑器，节点类型、配色、连线样式全部由代码定义，团队导出图的风格天然统一。

第二是数据资产问题。通用绘图工具把图保存成私有格式或者一张图片，图里的节点、连线和业务数据彻底割裂了。而在一个“图即数据”的设计中，画布上的每个模块都会绑定真实的数据，比如服务器IP、服务名称、调用关系、容量信息。这样的图才能从一张静态的“示意图”升级成“可视化管理面板”，甚至可以直接对接监控数据。

第三是可扩展性。通用工具很难做到让用户自定义节点类型、自动布局算法、批量导入数据生成图。而这些恰好是自研编辑器最容易做的事，因为图在底层就是一个JSON结构。

这个项目的定位很明确：做一个面向开发者的、数据驱动的架构图编辑器。不是做另一个PS，而是做一个“能绑定数据结构、能被程序生成和修改”的画布引擎。

1.2 第一版功能边界划定

做这类项目最大的坑就是贪多。一上来又想支持多人协作，又想加自动布局算法，还想做移动端适配，结果做三个月连一个能用的版本都拿不出来。

我第一版只保留了四个核心能力：

• 节点渲染与拖拽：能添加矩形、圆角矩形、圆形等基础节点，能自由拖动位置
• 连线交互：从一个节点边缘拉一条线到另一个节点，支持直线和贝塞尔曲线
• 画布平移与缩放：支持无限画布，鼠标中键拖拽平移，滚轮缩放
• 数据导入导出：图保存为JSON文件，也能导出PNG图片

这个“最小可行版本”可能听起来很朴素，但当你真的把这些功能做出来，会发现它们已经覆盖了日常画架构图的八成需求。剩下的自动布局、AI生成、模版管理，都是在这个地基上长出来的。

值得注意的是，它们之间的依赖关系很严格：数据模型必须在一开始就定好，否则后面所有功能都要返工。数据模型是纲，其余都是目。

1.3 渲染方案对比：Canvas还是SVG还是DOM

说到图表渲染，主流方向无非三种：Canvas、SVG、DOM加CSS。这是个老生常谈的问题，但选错了一样要掉坑。我直接给三者的关键差异做个对比。

我做这个项目选的是Canvas。原因有三：第一，架构图经常代表几十上百台设备，节点数轻松过五百，SVG在这种规模下DOM节点太多，交互会有明显卡顿。第二，Canvas可以做到逐像素控制，在实现高性能的框选、缩放、局部重绘时更灵活。第三，我需要导出高质量图片，Canvas本身就是位图，直接导出即可，省去SVG转图片的中间环节。

代价也很明确：所有鼠标命中检测都得自己算，矩形、圆形、连线都是一个个数学公式。但这反而让我对这个编辑器有了完全的控制权，后面越写越顺手。

2. 核心数据模型与坐标系设计

2.1 “图就是数据”：节点、连线、画布的结构设计

这一步是整个项目的灵魂。你要是数据结构设计得好，后面所有功能（拖拽、缩放、存储、协同）都水到渠成；设计不好，后面每加一个功能都得重构一次。

核心对象只有三个：Node、Edge、Graph，外加一个View对象描述画布视角。

interface Node { id: string type: string // 'rect' | 'roundRect' | 'circle' x: number // 节点中心点x坐标（世界坐标系） y: number // 节点中心点y坐标（世界坐标系） width: number height: number style: { fillColor: string strokeColor: string text: string fontSize: number } data?: Record<string, any> // 关联的业务数据，比如服务名、IP } interface Edge { id: string sourceId: string // 起点节点id targetId: string // 终点节点id sourceAnchor: 'top' | 'bottom' | 'left' | 'right' targetAnchor: 'top' | 'bottom' | 'left' | 'right' style: { lineColor: string lineWidth: number curveType: 'bezier' | 'straight' } label?: string // 连线上的文字标记 } interface Graph { nodes: Map<string, Node> edges: Edge[] } interface View { scale: number // 缩放比例，默认1 offsetX: number // 画布平移偏移量（世界坐标） offsetY: number }

用Map存储节点而不是数组，是因为在拖拽、命中检测时频繁要通过id找节点，Map的查找是O(1)，在节点多时差距很明显。连线用数组，因为连线的数量通常远小于节点，遍历成本可以接受。

你可能注意到节点的x、y坐标存的是“中心点”而不是左上角。这个小决策影响深远。中心点坐标让节点在缩放、旋转、锚点计算时的公式都变得简单对称，也不会出现“拖动时节点突然跳一下”的问题。

2.2 世界坐标与屏幕坐标的换算公式

这是所有Canvas编辑器最容易搞混的部分。你要时刻分清楚两套坐标系：

• 世界坐标：图的“真实”坐标，节点位置、连线锚点都存这套坐标，和用户缩放多少无关
• 屏幕坐标：鼠标点击、画布绘制时用的坐标，是经过缩放和平移之后的值

因画出完整流程：

世界坐标 -> 乘以scale，加上offsetX/offsetY -> 屏幕坐标 屏幕坐标 -> 减去offsetX/offsetY，除以scale -> 世界坐标

对应到代码：

function worldToScreen(point: {x: number, y: number}, view: View) { return { x: point.x * view.scale + view.offsetX, y: point.y * view.scale + view.offsetY } } function screenToWorld(point: {x: number, y: number}, view: View) { return { x: (point.x - view.offsetX) / view.scale, y: (point.y - view.offsetY) / view.scale } }

这里有个新手爱犯的错误：把世界坐标直接当成屏幕坐标使用，结果节点一缩放位置就漂移。任何涉及鼠标交互的地方，第一步一定是先把鼠标的屏幕坐标转成世界坐标，再用世界坐标去检测命中了哪个节点。

2.3 以鼠标为中心缩放：一个反直觉的数学细节

先跑一个测试：当你滚轮缩放时，期望看到的效果是什么？应该是“鼠标指着的那个点，缩放后还在鼠标指着的那个位置”。这就是“以鼠标为中心缩放”。

这个转换看上去反直觉，但数学很简单：缩放本身是相对于原点(0,0)的，所有点会向原点（左上角方向）聚拢或散开。为了保持鼠标位置下的点不动，需要先计算出鼠标在世界坐标上的位置，然后在缩放之后，把偏移量补回去，让该点重新“回到”鼠标所在屏幕位置。

关键代码实现：

function zoomAtPoint(centerScreenPoint: {x:number,y:number}, newScale: number, view: View) { const worldPoint = screenToWorld(centerScreenPoint, view) view.scale = newScale // 缩放后，让worldPoint再次回到centerScreenPoint位置 view.offsetX = centerScreenPoint.x - worldPoint.x * view.scale view.offsetY = centerScreenPoint.y - worldPoint.y * view.scale }

很多图上缩放后会“漂移”而不是“聚焦”，就是少了这个步骤：忘了先算出鼠标位置对应的世界坐标，缩放后本该固定的点跑掉，再用偏移量补回来。

2.4 渲染循环设计：不是每个操作都立刻重绘

接下来聊渲染。在Canvas里有两种重绘策略：

1. 外力驱动重绘：一旦数据变化，立刻调用render()全量重画。
2. 帧循环重绘：始终保持一个requestAnimationFrame循环，每帧都检查数据是否有变化，有变化才重绘。

对于交互频繁的画面编辑器，我建议选第二种，但不是每帧都无脑重绘，而是引入一个“脏标记”：

let dirty = false function markDirty() { dirty = true } function renderLoop() { if (dirty) { draw() dirty = false } requestAnimationFrame(renderLoop) }

所有修改数据的操作，比如拖动节点、改变连线、平移画布，都只调用markDirty()，真正的绘制集中到draw()里。这么做有两个好处：一次交互中被拖拽触发的几十次鼠标移动事件不会每次都触发重绘，只有等到下一帧才画一次；多个数据变更在同一次事件循环里发生，最后只重绘一次，性能好很多。

draw()方法的核心流程如下：

function draw() { ctx.clearRect(0, 0, cssWidth, cssHeight) // 注意：这里是CSS尺寸，不是物理尺寸 ctx.save() ctx.translate(view.offsetX, view.offsetY) ctx.scale(view.scale, view.scale) // 先把所有边画上（在节点下面，让连线被节点压住，视觉更清爽） for (const edge of graph.edges) { drawEdge(edge) } // 再画所有节点 for (const node of graph.nodes.values()) { drawNode(node) } ctx.restore() }

注意要先画边再画节点，不然连线叠在节点上面，看起来像断了一样。这个顺序不对，后期改起来特别痛苦。

3. 实操：搭建画布、节点拖拽与连线交互

3.1 画布初始化与高分屏适配

工程搭建方面，我不建议一上来就上重型框架或现成图形库。用原生TypeScript加Canvas API写核心渲染逻辑，方便你理解和控制每一个细节，将来想集成到任何框架都很简单。先把一个干净的页面搭好：

<canvas id="canvas"></canvas>

然后是初始化代码：

const canvas = document.getElementById('canvas') as HTMLCanvasElement const ctx = canvas.getContext('2d')! function resizeCanvas() { const dpr = window.devicePixelRatio || 1 const cssWidth = canvas.clientWidth const cssHeight = canvas.clientHeight canvas.width = cssWidth * dpr canvas.height = cssHeight * dpr ctx.setTransform(dpr, 0, 0, dpr, 0, 0) markDirty() } window.addEventListener('resize', resizeCanvas) resizeCanvas()

这段代码如果你直接照抄本地跑，会发现画出来的图形很清晰，不模糊。核心原理是：Canvas的物理像素需要和屏幕的物理像素一一对应，但实际开发中我们仍用CSS像素来写绘制逻辑，所以先通过ctx.setTransform(dpr,0,0,dpr,0,0)做一次全局缩放。没有这一步，高分屏下所有图形都会发虚，像隔着一层毛玻璃。

3.2 节点拖拽：从鼠标命中检测到位置更新

节点拖拽是编辑器最基础的交互，但拆开看有四个关键环节：鼠标按下时命中检测、记录拖拽偏移量、鼠标移动时更新位置、鼠标松开结束拖拽。

命中检测的公式很简单：算鼠标世界坐标是否落在节点的矩形包围盒里。我这里提示一下，之所以用“包围盒”而不是“完美的图形边缘”，是因为矩形端点附近的命中宽容度更高，用户点击时不容易“点空”，体验更好。

function hitTestNode(worldPoint: {x,y}, graph: Graph): Node | null { for (const node of graph.nodes.values()) { const left = node.x - node.width / 2 const right = node.x + node.width / 2 const top = node.y - node.height / 2 const bottom = node.y + node.height / 2 if (worldPoint.x >= left && worldPoint.x <= right && worldPoint.y >= top && worldPoint.y <= bottom) { return node } } return null }

接着是拖拽交互的核心流程。我用Pointer Events而不是Mouse Events，因为前者统一处理了鼠标、触控笔和触摸屏，省得为移动端再写一套逻辑。

canvas.addEventListener('pointerdown', (e) => { const screenPoint = { x: e.clientX, y: e.clientY } const worldPoint = screenToWorld(screenPoint, view) // 优先判断是否命中了节点 const node = hitTestNode(worldPoint, graph) if (node) { dragState = { nodeId: node.id, startWorldPoint: worldPoint, startNodeX: node.x, startNodeY: node.y } canvas.setPointerCapture(e.pointerId) return } // 如果没命中节点，进入画布平移模式 panState = { startScreenPoint: screenPoint, startOffsetX: view.offsetX, startOffsetY: view.offsetY } }) canvas.addEventListener('pointermove', (e) => { const screenPoint = { x: e.clientX, y: e.clientY } if (dragState) { const worldPoint = screenToWorld(screenPoint, view) const node = graph.nodes.get(dragState.nodeId) if (node) { node.x = dragState.startNodeX + (worldPoint.x - dragState.startWorldPoint.x) node.y = dragState.startNodeY + (worldPoint.y - dragState.startWorldPoint.y) markDirty() } } if (panState) { view.offsetX = panState.startOffsetX + (screenPoint.x - panState.startScreenPoint.x) view.offsetY = panState.startOffsetY + (screenPoint.y - panState.startScreenPoint.y) markDirty() } }) canvas.addEventListener('pointerup', () => { dragState = null panState = null })

注意拖拽时用“增量偏移”计算新坐标：记录按下时鼠标的世界坐标和节点的起点坐标，每次移动时算出鼠标相对起点的偏移，把这个偏移加到节点的起点坐标上。这样做的好处是：不管拖到哪，节点和鼠标的相对位置始终保持不变，不会出现节点“跳到”鼠标位置的情况。

3.3 连线：从锚点拖出、命中终点与曲线绘制

连线交互是编辑器的另一个门面工程。我把它拆成两部分：连线的拖拽创建过程，和连线的绘制算法。

拖拽创建连线的流程：

1. 鼠标按下时，先检测是否命中了节点。如果命中，同时检测是否按在了某个锚点附近。

锚点是节点四周的中点（上、下、左、右）。命中检测就是在节点矩形边上找离鼠标最近的那个锚点，如果距离小于一定阈值（比如10px），就认为用户准备从这里拉线。

function getNearestAnchor(node: Node, worldPoint: {x,y}) { const anchors = [ { position: 'top', x: node.x, y: node.y - node.height / 2 }, { position: 'bottom', x: node.x, y: node.y + node.height / 2 }, { position: 'left', x: node.x - node.width / 2, y: node.y }, { position: 'right', x: node.x + node.width / 2, y: node.y } ] let nearest = null let minDist = Infinity for (const anchor of anchors) { const dist = Math.hypot(anchor.x - worldPoint.x, anchor.y - worldPoint.y) if (dist < minDist) { minDist = dist nearest = anchor } } return minDist < 10 ? nearest : null }

2. 如果按到了锚点，进入“连线预览模式”：画一条从锚点到当前鼠标位置的临时线。
3. 鼠标松开时，再检测鼠标是否落在了某个节点的锚点上。如果命中了并且和起点不是同一个节点，就创建这条边；否则取消。

连线的绘制算法，我用的是贝塞尔曲线。节点之间用曲线连接，视觉上比直线柔和，尤其是在节点密集的架构图上，不会出现一堆直线横七竖八交叉的杂乱感。

贝塞尔曲线的控制点计算逻辑是：从sourceAnchor方向延伸一段距离作为起始控制点，从targetAnchor的反方向延伸一段距离作为终止控制点。

function drawEdge(edge: Edge, graph: Graph) { const source = graph.nodes.get(edge.sourceId) const target = graph.nodes.get(edge.targetId) if (!source || !target) return const start = getAnchorPosition(source, edge.sourceAnchor) const end = getAnchorPosition(target, edge.targetAnchor) const distance = Math.hypot(end.x - start.x, end.y - start.y) const offset = Math.max(40, distance * 0.4) // 曲线高度 = 距离的40%，至少40px const cp1 = extendFromAnchor(start, edge.sourceAnchor, offset) const cp2 = extendFromAnchor(end, edge.targetAnchor, offset * 0.8) ctx.beginPath() ctx.moveTo(start.x, start.y) ctx.bezierCurveTo(cp1.x, cp1.y, cp2.x, cp2.y, end.x, end.y) ctx.stroke() }

这里extendFromAnchor要按锚点方向把点往“外面”推。比如sourceAnchor是right，控制点就在起点右侧偏移；sourceAnchor是top，控制点就在起点上方偏移。

function extendFromAnchor(point: {x,y}, anchor: string, dist: number) { switch (anchor) { case 'top': return { x: point.x, y: point.y - dist } case 'bottom': return { x: point.x, y: point.y + dist } case 'left': return { x: point.x - dist, y: point.y } case 'right': return { x: point.x + dist, y: point.y } } }

如果你体验过架构图工具里的“橡皮筋连线”，你大概就是这种感觉。提前说一嘴：上面这段代码画出来的连线虽然够用，但如果你的图很“扁”、水平方向长，你要调整curveType参数甚至改用正交走线（先横后竖再横），否则看起来会觉得很“飘”。这是后面打磨的重点，但第一版先求能跑通。

3.4 画布平移与缩放联动

平移和缩放这两个操作，代码实现单独看都很简单，麻烦的是它们和节点拖拽、连线锚点什么组合在一起的时候。我给你的原则是：先判定操作优先级，这个优先级是固定的，能省掉很多bug。

操作判定优先级示例：

1. 是否在连线创建模式（按下时落在锚点）
2. 是否在节点拖拽模式（按下时命中节点）
3. 是否在框选模式（按下时命中了空白区域且按住shift）
4. 是否在画布平移模式（按下时命中空白区域）
5. 是否在缩放模式（滚轮）

滚动缩放时，除了更新view.scale，还需要做两件事：限制缩放范围（比如0.2到3.0，否则用户会滚到找不到图），以及按2.3节的方法以鼠标为焦点缩放。

canvas.addEventListener('wheel', (e) => { e.preventDefault() const delta = e.deltaY > 0 ? 0.9 : 1.1 const newScale = clamp(view.scale * delta, 0.2, 3.0) if (newScale === view.scale) return zoomAtPoint({ x: e.clientX, y: e.clientY }, newScale, view) markDirty() }, { passive: false })

这里注意必须给wheel事件监听加上{ passive: false }，否则浏览器会默认先执行页面滚动，你的缩放就没反应了。这个坑我在实际使用中踩过，排查了很久才找到原因。

3.5 导出高清PNG与JSON格式保存

最后一步，也是让这个工具真正“落地可用”的功能：把图导出成图片，或者保存成可复用的JSON文件。

导出PNG最偷懒的写法是直接canvas.toDataURL('image/png')。但有个问题：用户期望导出的图片尺寸和画布一致，而不只是当前视口截屏。如果你的图很大，还滚动过，直接导出只是导出了当前视口。更合理的做法是：先算出所有节点和连线的包围盒，然后新建一个临时Canvas，把包围盒范围渲染上去，再导出。

function exportPNG() { const bounds = getGraphBounds(graph) const padding = 40 const exportCanvas = document.createElement('canvas') exportCanvas.width = (bounds.width + padding * 2) * 2 // 两倍分辨率，保证印刷/缩放清晰 exportCanvas.height = (bounds.height + padding * 2) * 2 const exportCtx = exportCanvas.getContext('2d')! // 在导出画布上重新应用2倍缩放，然后平移和缩放 exportCtx.scale(2, 2) exportCtx.translate(-bounds.minX + padding, -bounds.minY + padding) // 在exportCtx上进行同样的绘制逻辑（drawEdges + drawNodes） drawGraph(exportCtx) const link = document.createElement('a') link.download = 'architecture-diagram.png' link.href = exportCanvas.toDataURL('image/png') link.click() }

这里我用2倍分辨率导出，这样图片即使被投在大屏幕上，边缘依然锐利。当然你的绘制函数要支持传入任意ctx实例，而不是写死在全局ctx上。这是很多初写编辑器的人容易忽视的设计：把绘制逻辑抽象成“传入ctx就画”的纯函数，不论是预览渲染、导出图片还是后续做缩略图，都能复用。

导出JSON相对简单，但也要注意几个点。Graph里的Map需要序列化成普通数组：

function serializeGraph(graph: Graph) { return JSON.stringify({ nodes: Array.from(graph.nodes.values()), edges: graph.edges, view: view }, null, 2) }

导入时反向恢复成Map即可。这里我建议在JSON里额外保存一个version字段，后续数据结构变动时可以写迁移脚本，不会出现“老文件打不开”的惨剧。

4. 踩坑实录与性能优化

4.1 高分屏下图形发虚的根源和修复

这个问题在3.1节已经提到过修复方案，我再展开说说根因。浏览器里Canvas实际由两套尺寸控制：

• CSS尺寸：决定Canvas在页面上占据多大区域
• 绘图缓冲区尺寸（canvas.width/canvas.height）：决定Canvas实际像素矩阵的大小

当你把Canvas的CSS尺寸设置成960px，但没有显式设置canvas.width = 960，那么画布的绘图缓冲区仍然默认是300x150。浏览器会把这个小图放大到CSS的尺寸，表现就是文字虚、线条糊。

正确的做法永远是：把canvas.width和canvas.height设置成CSS尺寸乘以devicePixelRatio，然后通过ctx.setTransform(dpr,0,0,dpr,0,0)让绘制时仍然使用CSS像素单位。这样物理像素和逻辑像素对齐，图就锐利了。

4.2 拖拽卡顿：避开“每次移动都全量更新”的坑

第一版写拖拽时我没有经验，直接在pointermove里调用render()全量重画。节点少的时候还好，一旦节点数超过300，拖一个节点就明显掉帧，整个画布都在闪。

能优化的方向其实很明确：把“改动数据”和“重绘画布”解耦。pointermove里只做一件事：修改节点坐标、标记dirty。到了下一次requestAnimationFrame回调，才统一执行绘制。

这样即使一秒钟触发60次pointermove（鼠标移动事件频率可能更高），实际重绘次数最多还是60帧。更进一步，我观察到拖动一个节点时，其他节点根本没变，理论上只重绘节点周围的一小片区域就够。但Canvas没有原生“脏矩形”接口，自己实现又很容易踩边界问题，所以第一版用全量重绘加帧循环已经是性价比最高的方案了。实测在1000个节点左右仍然流畅，已经很够用。

4.3 连线曲线参数调优：为什么曲线“飘”起来了

贝塞尔曲线看着很美好，控制点一调不好就会出现连线越过节点、路径诡异的大圆弧。我踩过最深的坑是在做分层架构图时，上下层节点之间的连线如果都用动态高度的贝塞尔曲线，就会出现“绕远路”的感觉。

解决思路是：连线样式必须跟随图的布局方向。如果你的架构图是自顶向下的分层图，连线就应该是“先垂直、再水平、再垂直”的正交走线；如果是自由布局的拓扑图，用贝塞尔曲线更合适。第一版我在Edge的样式里加了一个curveType字段，'bezier'或'orthogonal'，两种走线算法都保留。实测一个架构图工具，绝大多数情况用带一定弧度的贝塞尔曲线就足够，但分层结构图中“正交走线”观感会专业很多。

4.4 状态管理的取舍：撤销重做到底怎么做

写编辑器绕不开撤销重做。但你可以先规划，不用第一版就做。我只给一个建议：不要用深拷贝全量快照来记录历史。

很多初写者会把整个Graph对象在每次操作前JSON.parse(JSON.stringify(...))存进历史栈。结果就是每次操作要拷贝成千上万个节点，内存爆炸、操作卡顿、撤销慢得让人崩溃。

更稳的方案是命令模式：把一次操作（添加节点、移动节点、删除连线）封装成一个Command，包含undo和redo两个方法。历史栈里存的是命令，撤销时调用对应命令的undo方法恢复原状，重做时再执行一遍redo。这样既不需要拷贝数据，代码结构还特别清晰。

但我的第一版连命令模式也没做，只是记录了一些轻量的快照：由于我们只关心用户交互的结果，可以用“操作前的节点坐标数组”暂存一份，操作结束后如果点击撤销就恢复坐标，这种“轻量快照”在节点不是特别多时也能撑住。如果你的目标是把编辑器做成产品，建议直接上命令模式，越早越好。

4.5 命中检测的补充规则：连线的命中不能只看像素

连线的命中检测比节点麻烦。用户想点一条连线然后删除它，但连线那么细，鼠标放在某个像素上不一定正好压中。我建议的规则是：计算鼠标到每个线段的距离（点到线段的距离公式），如果距离小于6到8像素，就认为命中。这样用户比较容易选中连线。

function distancePointToSegment(p: {x,y}, a: {x,y}, b: {x,y}) { const dx = b.x - a.x const dy = b.y - a.y const lenSq = dx * dx + dy * dy if (lenSq === 0) return Math.hypot(p.x - a.x, p.y - a.y) let t = ((p.x - a.x) * dx + (p.y - a.y) * dy) / lenSq t = Math.max(0, Math.min(1, t)) const projX = a.x + t * dx const projY = a.y + t * dy return Math.hypot(p.x - projX, p.y - projY) }

这段代码是“点到线段距离”的标准解法，核心是利用向量投影找到直线上离目标点最近的点，再求欧氏距离。如果你直接拿点到直线的距离公式，会把线段范围外的也当成命中，体验很差。

4.6 常见问题速查表

5. 后续可以继续扩展的方向

核心编辑器跑通以后，它能做的其实远超“画架构图”这三个字。简单说几个我后来实际用到的扩展方向，每个都值得单独写一篇。

5.1 从自然语言到架构图：AI辅助生成

当你把图变成结构化JSON之后，就打开了一个非常关键的可能性：让AI生成架构图。流程很简单：

1. 用户输入一段话：比如“前端用Nginx做反向代理，后端有三个服务，分别是用户服务、订单服务和支付服务，订单服务依赖用户服务和支付服务”
2. 程序用大模型把这段话解析成结构化数据：提取实体、关系、类型
3. 生成Graph对象，通过自动布局算法排列节点位置
4. 渲染到画布上，交给用户继续手工调整

其实可以做一个懒人版：不用大模型，直接定义一套关键字匹配规则，例如“依赖”“调用”“对接”等连接词，也能解析出最简单的图。想做得效果惊艳，还是得接大模型，把非结构化描述转成结构化JSON。

5.2 自动布局算法：别让节点叠成一团

手工拖拽布局的图，当节点数量到几百个时就很难看了。这时需要有自动布局。最常用的三类：

• 分层布局（如自顶向下、从左到右）：适合架构分层图、调用链图
• 圆形布局：适合环状依赖、服务拓扑展示
• 力导向布局：物理模拟，节点自动排斥、连线相互吸引，适合复杂关系图

力导向布局的实现其实很有意思，核心逻辑是每帧对每个节点计算受力（连线拉力、节点间斥力、中心引力），更新位置，循环几百次后就收敛成一张相对美观的图。这就是为什么我说数据模型要一开始就设计好，因为布局算法就是调整节点坐标，和数据结构完全耦合。布局算法一加，图就从“手绘感”升级成“专业感”。

5.3 多人实时协作的连带影响

如果团队想多人同时编辑一张架构图，数据模型还得再升级。核心问题有两个：

• 节点ID必须在全局唯一，方案用UUID
• 协同同步用“操作日志”而不是全量数据：每个人把保存好的操作命令广播出去（比如“移动节点A到新坐标”），其他人应用相同的命令，就把图同步了

具体来说可以基于WebSocket实现一个小的广播协议。消息体类似：

{ "type": "moveNode", "payload": { "nodeId": "uuid-xxx", "x": 123, "y": 456 } }

接收方收到消息后直接应用到本地数据结构，再标记脏数据重绘即可。冲突情况（两个人同时拖动同一个节点）可以不做太复杂的处理，因为最后执行的那次操作会覆盖前一次，这在实时协作文档编辑器里被广泛接受。这种改动只有在数据模型和操作逻辑足够解耦时才能优雅落地，否则一加协同，代码就乱成一锅粥。

写在最后的几个经验

这个项目做下来，我最深的体会是：绘图编辑器的核心不是“画”，而是“算”。把一个复杂系统变成一套清晰的几何模型、一套坐标变换规则、一套事件优先级判断，是它和普通UI组件的根本区别。节点和连线只是表象，背后是数学模型。

另外有个小经验值得分享：开发过程中，我经常需要拿一张真正复杂的架构图来测试编辑器。不要只用三五个节点“演示一下”，那样很多问题根本暴露不出来。我当时造了一张模拟线上环境的图，300多个节点、400多条连线，缩放、拖拽、导出全部在这个规模下跑过一轮，才发现一大堆在小样本下看起来“没问题”的性能隐患。画图工具的自我验证，就是拿真实复杂度来虐它，虐得越狠，它越可靠。

如果你打算做类似的项目，建议第一版不用追求炫酷，把数据模型、坐标转换、渲染循环、命中检测这几根柱子立稳，后面加什么功能都是水到渠成的事。