写这个diagram-design项目的时候我其实是带着这几年画架构图、流程图、ER 图积攒下来的一肚子怨气开始的。市面上不是没有工具Visio、draw.io、Excalidraw 都各有拥趸但真放到团队协作或嵌入到自有产品里要么太重要么太飘逸要么就是私有的数据格式想二次开发几乎是跟别人的代码搏斗。所以这个项目从一开始就没打算做成一个大而全的在线绘图软件而是想打磨一个核心足够稳、扩展足够容易的图表设计基础引擎——说白了就是给那些想在 Web 端拖拽画图、但又不想从零写 canvas 交互的团队提供一个可以抄作业的参考实现。这篇文章想把整个项目的来龙去脉、技术选型、核心实现和踩坑记录都摊开讲清楚。内容会比较长适合三类人看一是准备在项目里集成绘图功能的同学可以拿这里面的架构思路当参照二是对 Canvas 交互、图编辑这类技术有好奇心的前端开发者里面有不少坐标系换算、性能优化、连线路由的细节三是自己正在做类似工具想找一份避坑清单的朋友——我把自己掉进去过的坑都尽量写得直白一点。文章不会讲太多空泛的设计思想更多是实打实的代码路径和决策过程。1. 项目定位它到底解决什么问题1.1 市面工具的共性短板先说结论通用工具软件和嵌入式绘图组件之间存在一条很深的鸿沟。像 draw.io 这种成熟工具功能确实全面但它是个完整的应用不是组件。你要把它嵌入到自己的 SaaS 系统里要么走 iframe 方案要么就得在它的源码基础上二次开发。iframe 方案天真地隔离了样式和脚本但一旦涉及数据互通比如点击图形回传业务数据、从后台动态加载节点交互就会变得非常别扭而且在多文档协同编辑场景下iframe 的通信成本会直接让你怀疑人生。Excalidraw 是另一个极端。它的手绘风格确实有魅力也容易让人上头但它对于技术性图示的支持比如精确的尺寸对齐、严格的端口连接、复杂的正交布线、灵活的样式定制就不够用了。手绘风和工程图本来就是两个方向。还有一个痛点是企业里常见的数据结构和渲染解耦不力。很多工具的图数据模型绑定了 UI 细节节点坐标、颜色、尺寸、层级关系全堆在一起导致迁移数据难、用脚本批量生成图难、做数据驱动场景几乎不可能。而实际业务里用 JSON 生成一张拓扑图或者流程图是很常见的需求。1.2 diagram-design 的差异化路线当时给这个项目定的基调就三条第一数据优先。画布上的所有元素节点、连线、锚点、分组都映射到一个干净的 JSON 数据模型上这个模型不依赖任何 UI 框架也不包含任何 Canvas 渲染状态。这样设计带来的直接好处是你可以从后端接口拿数据直接渲染出图可以做程序化生成可以接入任意状态管理库以后如果要换渲染方案数据层完全不用动。第二交互可定制。拖拽、框选、缩放这些基础交互行为是内置的但每一步都留了事件钩子。比如说节点拖拽结束的时候触发onNodeDrop连线创建过程可以拦截并校验连接合法性——这些钩子才是把一个绘图组件变成业务产品的关键。第三性能有底线。不求支持上万节点同时编辑那是图可视化库的领地但在几千节点、数万条连线的规模下交互必须保持流畅不能出现明显卡顿。为此渲染层选择了 Canvas 而不是 SVG后面会详细讲原因。1.3 适合谁用、不适合谁用我把这个项目定位成可嵌入的图表设计核心不是又一个绘图工具。它适合你用在自己的产品里比如工单流程设计器、网络拓扑编辑器、数据血缘关系图、低代码平台的表单布局器这些场景需要的是可拖拽的画布 图纸数据。但它不适合的场景也很明确如果你需要的是在线白板那种像素级的自由笔迹、多人实时光标、语音批注那就该去看专门的协作白板方案。如果你只是想画一张图然后导出图片发给别人直接用现成软件就完了不需要自己写代码。2. 技术选型与整体架构2.1 渲染方案为什么最终选了 Canvas这是最先要敲定的决策直接决定后面所有代码的写法。当时做了几组简单测试对比 Canvas、SVG 和 DOM 三种方案在图形渲染和交互上的表现结论如下。渲染方案节点数量上限60fps 编辑矢量缩放样式控制能力事件拾取动态数据绑定DOM约 500~800依赖 CSS transform整体缩放文字会模糊强CSS 随便写原生事件最直接容易React/Vue 都能管SVG约 1500~3000天然矢量文字边缘锐利强但样式越多 DOM 节点越多原生事件无需手写捡拾容易但节点数多了 DOM 操作频繁Canvas约 5000~10000取决于图形复杂度需手动处理坐标系逻辑复杂度高需自己维护样式系统需要手动做命中检测偏程序化需要自己实现渲染调度DOM 方案在节点数少、样式复杂的情况下很舒服因为整个前端生态的开发效率就摆在那里。但它撑不了规模一千个节点就是一千多个 DOM 元素再加上连线元素浏览器直接喘不过气。还有缩放问题整体用 CSS 缩放下文字和边框会一起变形这在架构图场景里经常是不能接受的。SVG 是很多人会推荐的选择因为它既保留了矢量放大不失真的特性又能用 DOM API 绑定事件开发心智负担低。但 SVG 在节点密集场景有一个绕不过去的瓶颈每个图形都是 DOM 节点。节点一多创建、销毁、属性更新的开销会线性增长尤其是在拖拽过程中所有相邻连线都要更新路径时浏览器同步布局会卡到你怀疑人生。Canvas 的优缺点非常鲜明。优点就是渲染性能它是自绘的图形数量多、更新频繁对它来说就是重绘一整帧不存在单个元素的操作开销而且可以很方便地配合 requestAnimationFrame 做局部重绘把性能潜力压榨得很充分。缺点也明显所有元素的点击命中都得自己算拖拽过程中要自己维护坐标系文字排版、事件边界、光标样式都要一层层写。说白了Canvas 给了你更大的自由但自由是有代价的。权衡之下我还是选择了 Canvas。核心原因在于图表设计工具的瓶颈永远在交互时的帧率而不是首次渲染。拖拽一个节点时它周围的连线可能需要实时重新计算路径SVG 在不断修改 path 属性时容易触发布局抖动而 Canvas 只需要重绘一个图层帧率稳定得多。后来我们又把整个场景拆分成了四个画布层连线层、节点层、临时交互层、背景网格层这样在不同操作场景下只需重绘对应层性能进一步提升。2.2 模块划分别再只想着画布这个类项目形态是一颗前端的规模不大不小的库模块划分做得太粗会乱太细了会碎。最终按照以下结构进行组织src/ core/ // 数据模型、事件总线、命令栈 canvas/ // 画布引擎分层渲染、坐标变换、调度 render/ // 各图形类型的绘制函数纯函数 interact/ // 拖拽、框选、缩放、连线等交互逻辑 style/ // 样式解析与主题系统 utils/ // 几何计算、路径计算、通用工具 index.ts // 对外入口core层不依赖任何 DOM 或 Canvas 代码它是纯数据层用来管理图和所有历史记录。canvas层负责将数据翻译成画面并处理所有输入事件的坐标系换算。render层其实只是一堆绘图函数你给我节点对象和 Canvas 上下文我给你画出来。interact层是核心业务逻辑处理各种用户操作对数据模型的影响。这个拆分最关键的地方在于把数据和画面之间的依赖做了严格的方向约束数据层不知道有渲染层存在渲染层通过订阅数据变化来驱动重绘。这意味着你可以写单测直接测数据模型和交互逻辑而不需要打开浏览器。2.3 数据模型一张图的骨架数据结构的设计决定了扩展性的上限。我参考了图编辑器的通用做法定义了三类核心元素Node节点、Edge连线、Group分组所有元素共享一个BaseEntity基类包含 id、type、坐标、尺寸、样式引用等基础属性。节点是图的最小单元它不仅是矩形还可能是圆形、菱形、图片、自定义组件。所以在设计上所有节点的数据都收敛到通用的NodeData结构interface NodeData { id: string; geometry: { x: number; y: number; width: number; height: number; }; type: string; // 节点类型对应渲染层的一个绘制函数 attrs: Recordstring, unknown; // 业务属性由具体节点类型解释 style?: NodeStyle; ports?: Port[]; // 连接锚点 data?: Recordstring, unknown; // 用户自定义数据原样保留 }attrs和data的区别很有讲究attrs是几何层需要理解的属性如圆形的半径、菱形的角点比例而data是业务层需要理解的属性如设备名称、IP 地址两者严格分离。连线结构稍微复杂一点因为它不仅要记录从哪个节点到哪个节点还要记录路径本身。interface EdgeData { id: string; // 连接两端既可以是节点端口也可以是绝对坐标锚点 source: { nodeId?: string; portId?: string; x?: number; y?: number }; target: { nodeId?: string; portId?: string; x?: number; y?: number }; type: straight | orthogonal | bezier; routing?: Point[]; // 手动加点用于绕障或强制走线 attrs?: Recordstring, unknown; style?: EdgeStyle; }图本身则是一个GraphData对象包含节点数组、连线数组、分组数组和视口信息。这里有一个值得注意的小设计把视口信息缩放比、平移距离、当前选中项也扔在了数据对象里而不是存在 Canvas 引擎的模块级变量中。这样做的好处是状态可序列化——把整个图保存到后端时连视图状态也一并存下来下次打开还能恢复到用户上次的浏览位置体验非常顺滑。3. 核心功能实现与实操细节3.1 坐标系的秘密屏幕坐标 vs 世界坐标这是所有画布类应用的第一个大坑几乎每个新来的同学都会在这栽一次跟头我得把它讲透。当你在 Canvas 里画一个节点你通常会调用ctx.fillRect(x, y, width, height)这个 x 和 y 是 Canvas 的坐标空间。当用户拖动鼠标时事件回调里的clientX和clientY是浏览器窗口坐标。如果把这两个坐标混在一起用映射关系就会错乱一旦 Canvas 元素在页面中发生了滚动、或者画布做了缩放平移你的拖拽逻辑就崩了。正确的姿势是维护两个坐标系并建立明确的转换关系屏幕坐标Viewport 坐标Canvas 元素左上角为原点单位是 CSS 像素也就是鼠标事件拿到的坐标经过getBoundingClientRect()校正后的结果。世界坐标Model 坐标图纸的坐标空间节点数据里的 x、y 都存放在这个空间。这个坐标不受缩放和平移影响是稳定的表意坐标。两者的转换关系很简单export function screenToWorld(screenPt: Point, viewport: Viewport): Point { return { x: (screenPt.x - viewport.x) / viewport.zoom, y: (screenPt.y - viewport.y) / viewport.zoom, }; } export function worldToScreen(worldPt: Point, viewport: Viewport): Point { return { x: worldPt.x * viewport.zoom viewport.x, y: worldPt.y * viewport.zoom viewport.y, }; }这里的viewport.x和viewport.y表示世界坐标原点对应在 Canvas 像素坐标上的位置。缩放时我们只需要更新viewport.zoom平移时更新viewport.x/y所有节点在世界坐标里一动不动变的只是渲染时的转换参数。实际操作中每次收到鼠标事件第一时间把屏幕坐标转成世界坐标再对数据模型进行操作。等操作结束后渲染层会用当前视口把整个场景画出来。这个流程是单向的事件 - 世界坐标 - 操作数据 - 重绘。中间不经过屏幕坐标能避免大量隐形 bug。3.2 图形的拖拽、框选与对齐吸附逻辑拖拽是图表编辑器最基本的交互但我想说的是它的实现方式。如果你直接监听mousemove然后在回调里修改节点坐标会遇到两个问题一是事件太频繁会导致抖动二是偏移量的计算容易写错尤其是缩放比例不为 1 时。我的做法是按下鼠标时记录起始点世界坐标和所有被拖动节点的初始位置然后在移动时计算总位移再给所有拖拽节点设置新坐标。注意是所有被拖拽的节点共享同一个位移量这样它们的相对位置就不会变。interact(node:drag) function onNodeDragStart(e: DragStartEvent) { const { nodeId, screenPos } e; const worldPos screenToWorld(screenPos, viewport); dragState { startWorld: worldPos, nodes: selectedNodeIds.map(id ({ id, origX: nodeMap.get(id).geometry.x, origY: nodeMap.get(id).geometry.y, })), }; } interact(node:drag) function onNodeDragMove(e: DragMoveEvent) { const worldPos screenToWorld(e.screenPos, viewport); const dx worldPos.x - dragState.startWorld.x; const dy worldPos.y - dragState.startWorld.y; // 对每个拖拽节点设置新坐标 for (const item of dragState.nodes) { updateNodePosition(item.id, item.origX dx, item.origY dy); } computeMagneticGuide(); // 计算磁吸对齐参考线 requestRender(); }这里有个容易被忽略的细节requestRender()并不是立刻重绘而是把重绘任务合并到requestAnimationFrame里。这样一秒钟最多画 60 次而不是鼠标移动多少次就画多少次性能是完全不同的量级。框选是另一个高频交互。实现思路是记录鼠标按下的起始世界坐标和当前世界坐标实时绘制一个半透明矩形同时每一帧检查所有节点与这个矩形是否相交。节点是否被选中不是靠 Canvas 的像素级检测而是直接做 AABB轴对齐包围盒相交测试这非常简单高效。多选时用 Shift 可以切换选中状态也算标配了。对齐吸附这个功能一开始我以为是加分项后来发现它是刚需。画架构图时如果节点之间总是差那么几个像素对不齐视觉上会非常难受。实现方法不复杂在拖拽过程中实时计算其他节点和当前节点的关键边缘左/右/中/上/下/中找出距离小于某个阈值比如 5px的边然后在渲染层绘制一条参考线并把拖拽位置自动吸附到对齐位置。这个功能的关键在于效率。每个节点有 6 条关键边水平和垂直各 3 条n 个节点就是 n×6 条边互相比较是 O(n²) 的复杂度。当画面里有几百个节点时这个计算量会拖慢拖拽帧率。我最后用了一个简单的优化只对当前视口内的可见节点进行计算而且只在拖拽的节流帧里执行不阻塞主流程。对于一般场景这个复杂度完全可以接受。3.3 连线路由从直线到正交避障的进化连线是图表编辑器的另一个硬骨头。一开始只做了直线连线和贝塞尔曲线但这在流程图里够用在架构图里就露怯了——尤其是网络拓扑图、系统架构图这类场景用户几乎默认需要的是横平竖直的正交连线。正交连线的路径计算业界最常用的是曼哈顿路由算法。基本思路是从起点出发先沿水平还是垂直方向中间经过若干转折点最后到达目标节点。如果起点和终点之间没有障碍物可以简单计算出一条先出起点、再入终点的折线。伪代码思路1. 确定起点端口方向例如右侧和终点端口方向例如左侧 2. 计算起点端口坐标 startPt 和终点端口坐标 endPt 3. 初步路径从 startPt 按出口方向延伸一段如 20px 再从该点画水平/垂直线到 endPt 的延伸点再进入 endPt 4. 如果该路径与障碍物其他节点相交则寻找可绕行的中间点我这里实现的是简化版没有做完整的 A* 寻路完整版对 JS 来说性能太吃紧了而是基于优先走中点绕障的启发式。效果是90% 的情况都能给出合理的连线路径剩下少见的情况可以允许用户手动拖动连线中点来增加自定义路由点。在 Canvas 上平滑绘制正交连线还有一个细节不要填满直角。现代 UI 的审美倾向于在转角处加一个小圆角视觉上柔和很多。实现方式是遍历路径点在两个方向改变的位置插入一个二次贝塞尔曲线弧度设置为 4~5px。连线的命中检测也很有意思。因为 Canvas 没有这条 path 是否被点击的 API你只能自己做。我的方案是连接线的路径被拆解为多个线段然后用点在线段上的距离检测来判断。当鼠标光标距离任意线段小于一定阈值时就认为命中。为了防止用户看不见瞄不准我还给每条连线设置了一个 8px 的命中加宽相当于把检测区域扩充到 8px 宽。这在体验上带来的提升非常明显。3.4 节点的端口与连接规则端口Port是表示连线端点在图元上的位置。常见的方案有静态端口4 个固定方向点和动态端口跟随图元边缘自动定位。我做了两种都支持静态端口适合那些有明确接口语义的节点比如数据库、API 网关动态端口适合常规图形。动态端口的计算思路是以节点中心为原点根据目标节点的相对方位选择离目标最近的边缘点作为端口位置。比如目标节点在右下那端口就取当前节点的 bottom-right 边缘附近同时考虑导线的进入方向避免连线穿过节点内部。连接规则的必要性我是在做 ER 图时意识到的。没有连接规则用户想把一个节点的输出端口连到另一个节点的输出端口也拦不住这在某些场景下不算错但在流程图里这就是混乱的源头。所以我在数据模型里内置了portRule配置允许定义端口类型和允许的连接方向。连线创建时会在交互层做校验不满足规则就显示红色禁止光标并且不产生任何数据变更。这个功能把工具的给用户自由和防止用户乱来平衡得比较好。3.5 视口缩放、缩略图与坐标陷阱视口缩放的手势交互很简单监听wheel事件当按住 Ctrl/Command 键时将滚轮滚动转换为缩放操作。缩放的核心逻辑是保持鼠标所在位置为缩放中心——也就是说鼠标下的那个世界坐标点在缩放前后都停留在鼠标下方。这样用户体验最好图形不会因为缩放而滑走。数学变换是function zoomAt(screenCenter: Point, newZoom: number) { const worldCenter screenToWorld(screenCenter, viewport); viewport.zoom clamp(newZoom, 0.1, 4); viewport.x screenCenter.x - worldCenter.x * viewport.zoom; viewport.y screenCenter.y - worldCenter.y * viewport.zoom; }看起来道理很简单但实现过程中我遇到过一个隐蔽的问题缩放值如果取整数倍增量比如从 0.5 到 0.75 到 1 到 1.25在多次缩放平移之后viewport.x/y会积累浮点误差导致图形轻微漂移。解决办法是在缩放结束后对坐标做一次修约同时把浮点数运算尽量集中到一次计算里减少中间态的精度损失。缩略图Minimap是一个容易被低估的功能。画布一大用户常常缩放得很深这时候当前视野在整张图中处在什么位置完全凭感觉。缩略图可以解决这个问题。它的实现没多复杂每一帧将整张图按比例绘制在一个小 canvas 上再绘制一个矩形框表示当前视口范围。要注意的是缩略图矩形框的宽高需要根据 viewport 和画布尺寸做等比换算这个坐标换算是图编辑应用的基本功。4. 性能优化的几个关键坎4.1 图层分层减少每次重绘的体积很多人第一次把图形画上 Canvas 后遇到性能问题就会尝试优化代码逻辑怎么优化都不见效。实际上最大的性能瓶颈往往在于重绘了不该重绘的内容。我把整个 Canvas 分为四个图层分别对应不同的绘制逻辑GridLayer背景层网格线和背景色。只在缩放结束或平移结束的时候重绘平时不动。LinkLayer连线层所有连线路径。拖拽节点时与节点相连的连线才需要更新路径其他连线不动。NodeLayer节点层所有节点图形。拖拽时重绘被拖拽的节点和受影响的部分区域即可。OverlayLayer交互层框选矩形、磁吸参考线、悬停高亮、端口提示等临时图形。交互结束后立即清空。画布引擎维护一个 dirty 标记列表比如DirtyFlag.Links | DirtyFlag.Nodes在渲染循环中只重绘标记为脏的层。这样做的收益立竿见影当你在拖拽一个普通节点时背景层不用动、大量无关连线不用动渲染成本大大降低。对于一个几百甚至上千节点的图拖拽时也能保持满帧。4.2 批量重绘与增量更新的取舍理论上Canvas 支持只重绘某个矩形区域的局部更新能力——调用ctx.clearRect后再把该区域内的图形重新绘制能极大提升性能。但这个能力在实际的图编辑器里很尴尬因为图形之间往往有重叠只重绘一个矩形会破坏其他图形的缓冲内容导致闪烁或残影。所以在实际项目里我选择了**分层 全层重绘**的组合方案。每一层内不做局部重绘而是如果该层被标记为 dirty就整层 clear 后重新绘制。听起来感觉笨但比起上一帧的重绘量这已经少了很多了。对于常见的图编辑场景来说全层重绘一帧的性能消耗在毫秒级别完全可以接受。如果你确实需要超高帧率比如实时协作时可以考虑做脏矩形裁剪但一般项目到这个优化层级已经能解决绝大多数性能问题了。4.3 事件系统的节流与防抖鼠标移动事件触发的频率极高如果在mousemove里直接做节点坐标计算、连线路由重算、磁吸对齐判断、然后触发重绘即使是高性能机器也会出现卡顿。我采取了三层策略第一层是rust 层面的节流鼠标事件回调里只记录最新的鼠标坐标然后统一调度下一次 rAF 帧来处理。如果这一帧已经在队列里了就不再重复排队。第二层是分频处理位置计算和渲染每帧都执行但磁吸吸附这种计算量略高的逻辑只每 2 帧执行一次即帧率减半。反正用户几乎感知不到参考线延迟 16ms 出现但性能上却少了一半的计算负担。第三层是结束时的收尾计算在鼠标释放事件中执行精确的最终对齐和连线路由计算并把修改后的节点坐标、连线路径严格同步到数据模型然后触发一次全量重绘。这样保证最终效果是精确的过程中的误差只是临时的视觉展示而已。4.4 大数据量场景下的事件名命中优化当画布里有几千个节点时光靠简单的遍历来做鼠标命中检测检查坐标是否在节点矩形内就会变成性能瓶颈。这里我用了空间哈希网格把整个画布划分成固定大小的格子比如 64×64 像素每个格子记录落在其中的节点 ID 列表。鼠标移动时只需要检查鼠标所在格子及其相邻格子里的节点不需要遍历全图。这个结构实现起来不复杂但它把节点命中检测从 O(n) 降到了接近于 O(1)。实际效果是即使画布里有 3000 个节点鼠标划过画布时依然没有任何停顿感。这个优化我认为是所有节点数量可能超过几百的图编辑器都必须做的。5. 常见问题与避坑心得5.1 坐标系换算错误症状与排查遇到的第一个常见问题画布在页面中不是从 (0,0) 开始节点头上总有一段偏移鼠标点击后选中不了正确元素。这个大多数时候是坐标系换算里忘了减去元素本身的getBoundingClientRect().left/top。我建议把这段逻辑封装成一个getCanvasPointFromEvent函数所有事件入口统一走它不要在业务代码里到处手动算clientX - canvasLeft。排查时可以先做一个验证在画布正中心画一个 10×10 的测试点然后用鼠标点在测试点正上方看是否精确命中。如果偏了多半是换算中某个步骤忘记除以viewport.zoom。5.2 文字在不同缩放级别下的可读性Canvas 里的文字和 SVG 不同不会自动跟随缩放保持锐利。如果直接按世界坐标绘制文字当viewport.zoom小于 1 时文字会变得很小几乎看不清放大到 2 倍时文字又会变大得离谱。解决方案是绘制文字时把字号除以viewport.zoom然后把画布坐标换算到屏幕坐标再绘制。这样无论缩放多少倍文字始终以固定的屏幕像素字号显示。ctx.font ${18 / viewport.zoom}px Inter, sans-serif; ctx.fillText(node.label, screenPt.x, screenPt.y);但这里还有一个隐藏的坑文字的定位也要随着缩放进行补偿。需要计算文字的实际宽度用ctx.measureText然后根据对齐方式换算偏移量。如果文字水平居中那就得在屏幕坐标基础上减去文字宽度的一半。这些细节不处理好放大缩小之后文字的位置会和节点错位。5.3 连线的更新时机与数据一致性拖拽节点时所有关联连线需要更新路径。如果更新不及时视觉上会出现线头悬空的尴尬。这里的关键是建立节点和连线之间的依赖关系并确保在渲染前调用更新函数。我的做法是维护一个linkMap记录每个节点关联的所有连线。当节点 move 时直接查表获取关联连线更新它们的路径并标记连线层 dirty。这个查询必须是 O(1)不能每次都在所有连线里遍历。还有一个容易踩的坑勾选了手柄拖动连线的中间节点功能时用户手动添加的routing点不能被自动重算逻辑覆盖。所以EdgeData里我加了一个manualPoints数组普通的自动路由计算只会在自动路径部分工作手动指定的点永远保留。否则用户调节好的边线路径一拖动节点就被重置这是一个非常让人抓狂的体验问题。5.4 撤销重做设计命令模式是标配撤销重做如果只是简单地把整张图的快照存下来在节点数量达到几百时内存消耗会非常惊人。我的实现是命令模式每个操作插入节点、删除连线、属性修改、批量移动都是一个Command对象包含execute和undo两个方法。interface Command { name: string; execute(): void; undo(): void; redo(): void; }比如移动节点命令不需要保存整张图只需要保存被移动节点的旧坐标和新坐标。撤销时把坐标改回去重做时再改回来。这样即使执行一百次操作占用的内存也极其有限。这里有一个实际的细节命令栈的容量要设上限默认 100 条就够了。不要在用户连续框选拖动了几十个操作之后让内存跟着爆掉。撤销列表超限时自动丢弃最旧命令这符合用户心智模型。5.5 缩放精度与锚点抖动缩放到某个层级后节点边缘会出现轻微抖动。这是浮点误差在连续变换中累积的表现。解决办法是在做图形绘制时先把世界坐标转换为屏幕坐标并对屏幕坐标做一次四舍五入。对于 1 像素以内的误差人眼几乎感知不到对于交互命中的计算则使用未经取整的精确坐标。绘制和命中分离两边都避免误差干扰。5.6 浏览器兼容性这个项目大量使用了PointerEvent指针事件它在现代浏览器中已经全面支持但要注意的是旧版本 Safari 对部分属性支持不完整尤其是pointerrawupdate这类高级事件。建议在挂载事件时做 capability detection如果环境不支持回退成mousedown/mousemove/mouseup的兼容方案。另外 DPR 适配是必须的Canvas 是按物理像素渲染的需要根据window.devicePixelRatio设置 canvas 的实际宽高否则在 Retina 屏上画出来的图形会发虚。6. 工程化与测试别让代码库变成泥潭6.1 数据层的单元测试这个项目最有测试价值的部分是我之前说的core层——它与 UI 完全解耦非常适合写单元测试。比如坐标转换、AABB 相交检测、连线路由算法、对齐吸附计算全都用纯函数实现直接在 Node 环境里跑测试就行。选 Jest 还是 Vitest 都无所谓能跑通就行。关键是给核心算法保证正确性路由算法尤其需要完善的测试覆盖因为正交连线的分支很多起点和终点的相对位置、是否存在障碍物、端口方向这些组合一多就非常容易出 bug。写测试的时候不要只写 happy path边界情况两个节点完全重叠、起点终点都非常接近、图元尺寸为零都写一下能提前暴露很多实现漏洞。6.2 用 Playwright 做交互回归Canvas 的交互用单元测试是很难覆盖的所以我用了 Playwright 做端到端测试。测试用例可以模拟真实的鼠标拖拽、缩放、连线的完整操作流然后断言画布上生成的 GraphData JSON 是否符合预期。这里有个技巧让画布引擎暴露一个 debug 接口直接在 window 上挂一个getGraphData()方法测试脚本就能快速拿到当前图的数据快照。这个方案比截图比对可靠得多因为数据快照的语义是确定的不受渲染差异影响。等数据层的行为稳定下来再考虑加截图视觉回归测试。6.3 定制化的侵入点这个项目不是终点它更像一个基线版本。我给它留下的扩展点包括registerNodeType(type, drawFn, options)用于注册新的节点类型这样用户能自己实现图形绘制函数而不需要改动核心。registerInteraction(handler)用于注册自定义交互逻辑比如双击编辑文本、右键弹出菜单。事件钩子onNodeMoved、onEdgeConnected、onSelectionChanged等方便外部系统把图编辑器的行为与业务逻辑接在一起。这些扩展点的价值在于当你拿着这个项目去对接真实业务时不需要为了加一个设备节点而改到核心代码。扩展开销被控制在最小范围长期维护的压力也小很多。7. 最后的经验沉淀做这个项目最大的体会是图编辑器表面上看起来是个画板实际上它是数据模型 渲染引擎 交互系统三个系统的合体。任何一个环节只做到 60 分整体体验就会崩掉。数据模型设计得好后面无论是做服务端保存、JSON 导入导出、还是多人协作都会省非常多的力气渲染引擎只要保障足够快的帧率功能做减法可以流畅度不能妥协交互系统是用户每天直接面对的东西一点小的不顺畅都会让用户对产品产生不信任感。我在开发过程中最大的教训是不要过早陷入对酷炫功能的追逐。刚开始我给项目加了十几个动画效果节点出现时弹跳、连线绘制时流光、删除时的缩放消失……当时觉得极大提升体验后来发现这些动画不仅拖慢帧率还在频繁操作时让界面显得飘非常影响专注。后来砍掉了绝大多数非必要动画只保留了两处——框选完成时的高亮闪烁和连线创建成功时的小圆点生长反而整体质感提升明显。如果接下来你想在这个项目上继续迭代我建议优先考虑三个方向一是接入 Web Workers 做连线路由的并行计算这样可以支撑更大的图规模而不阻塞主线程二是把数据模型对齐到常见的可视化标准格式比如导入导出 Graphviz 或 JSON Graph Format互通能力是很多用户愿意迁移的门槛三是做一个小而美的插件系统让第三方开发者可以贡献节点库、图标库和样式主题——只有生态活了一个绘图引擎才能变成一个真正的工具平台。最后再分享一个实操中的小技巧画布初始化时把默认视口设置成刚好居中并完全显示整张图的缩放级别用户进来不会面对一片空白无所适从。这个看似微不足道的细节能在很大程度上降低第一次使用的陌生感。写到这里这个项目的核心路径几乎都摊开在纸面上了。图纸本身也是代码代码本身也是图纸——一个能优雅地在这两者之间来回转换的工具就是我最终想做的事。