2026年ai搭建网站哪家可靠，这些你都认识吗？
2026/9/3 19:59:50
简介：资源为JSPlumb与JSPlumbToolkit的实例合集，面向需要在前端页面中实现流程图、关系图与交互式连线的开发者，重点解决节点拖拽、动态连线、数据绑定及复杂布局等可视化需求。压缩包共1099个文件，以HTML演示页面、PNG效果图、CSS样式和JS脚本为主，同时包含Bootstrap、jQuery UI等配套资源，便于本地直接打开运行和二次修改。包体约4.04MB，整体轻量，涵盖从基础connect用法到端点自定义、连接样式、Toolkit数据模型与布局算法的完整示例。目前已有1093人学习下载，适合前端初学者参考入门，也可供有经验开发者快速提取代码片段、理解两个库的API差异，并在此基础上构建自己的流程编辑工具。 我去年接到一个可视化流程编排的需求时，第一件事就是选连线库。产品形态不复杂：左侧物料区，中间画布，用户把节点拖进去，拖拽连线，最后生成一份JSON交给后端存储，下次再回填渲染。市面上做连线图的方案不少，但真到落地就会发现，jsPlumb 和 jsPlumb Toolkit 之间的选择、社区版 API 怎么组合、动态节点和回显怎么不出错，这些才是让团队卡壳的地方。这篇文章我就围绕 jsplumb 实例和 jsplumbtoolkit 的实际使用经验，把选型思路、核心概念、可运行的完整示例，以及我在真实项目里踩过的坑一起写完，希望能帮你少走点弯路。
1. 从流程图选型开始：为什么我没有用G6和mxGraph
1.1 候选方案的定位差异
市面上面向连线图的可视化方案，主流大概有四类。第一类是蚂蚁的 G6 和 X6，数据驱动、内置布局算法、文档丰富，能力很全，但引入之后你会发现它更偏 canvas 渲染和图形建模，节点内部如果要放复杂的表单控件，就得用自定义 DOM/React 节点方案，学习成本不低。第二类是 mxGraph 以及基于它的 draw.io，强在图元编辑能力和默认交互，但 API 风格比较老，代码风格偏 Java 移植，前端项目里维护起来有点别扭。第三类是 D3，自由度最高，但从零手写拖拽、连线命中、端点吸附这些交互，开发周期直接拉满。第四类是今天的主角 jsPlumb，它的设计思路跟前面几种完全不同，是直接在真实 DOM 元素上做端点和连线。
我最终选 jsPlumb，核心原因是这个项目里的节点非常"重"：每个节点包含图标、名称、配置表格、状态灯，未来还要支持内嵌表单。用 jsPlumb 的话，节点本身就是普通的 HTML 元素，样式用 CSS 随便控制，节点内部的业务逻辑完全不侵入连线框架。而 G6/X6 这类方案，节点渲染要走它们的自定义节点机制，把一套复杂表单塞进去，后续维护的成本会高不少。
1.2 jsPlumb的价值边界
jsPlumb 真正擅长的是"手工摆放 + 自由连线"的场景。比如服务编排图、网络拓扑、泳道图、审批流程编辑器，用户把节点放在任何位置，然后从一个端点拖到另一个端点，连线用贝塞尔曲线或者折线连接。这类需求 jsPlumb 基本上开箱即用，你不需要自己算连线路径，不需要处理命中检测，也不需要管端点吸附。
但它也有很明确的短板。第一，自动布局能力基本为零，你要布局得自己去接 dagre 或者自研规则；第二，超大规模节点渲染性能一般，几千个节点时靠 DOM 渲染还是有点吃力；第三，框选、撤销重做、缩略图这类编辑器级能力，社区版要自己实现。所以如果产品从一开始就确定了是"数据自动布局 + 只读展示型"图谱，比如知识图谱、组织架构图，用 G6 会舒服得多；但如果产品是"用户自由拖拽 + 编辑连接关系"的编辑器形态，jsPlumb 的路径是最直接的。
2. 先看清楚：jsPlumb与jsPlumb Toolkit是两个东西
2.1 社区版jsPlumb：开源、免费、敢上生产
很多人会混淆两件事：npm 上的jsplumb包，和官网卖 license 的 jsPlumb Toolkit，其实是两个不同层级的项目。社区版 jsPlumb 的开源协议对商业项目友好，可以用在生产环境里，这也是我敢放心用的基础。
社区版提供的核心能力包括：端点（endpoint）、连接线（connection）、锚点（anchor）、覆盖物（overlay）、节点拖拽、监听连接事件、导出连接数据等。这些能力已经能覆盖大部分"拖拽连线画布"的需求。你要做的无非是把节点 DOM 建好，调用addEndpoint挂载端点，然后交给用户去拖。社区版的定位就是"连线引擎"，它不替你做节点面板、不替你做数据模型、不替你做撤销栈，但好处是轻、灵活，你完全按自己的业务来组织。
从我实际经验看，只要不是要做成一个多人在线协同的图编辑产品，社区版完全够用。我们第一版流程编排工具就是用社区版做的，节点拖拽、连线、删除、JSON 导出和回显，3000 多行代码全部搞定，后续也没在这套画布上返过工。
2.2 Toolkit：商业化产品，强在哪里
jsPlumb Toolkit 是同一家公司出的商业化产品，它跟社区版的关系，可以理解为一个"内置了大量交互能力的增强版"。Toolkit 把节点、连线、端口、分组抽象成了完整的数据模型，你只需要喂数据，它会自动创建对应的 DOM 或 SVG 元素，并完成渲染。它内置了Surface 画布组件，提供了滚动、缩放、小地图，还有框选、多选、撤销重做、复制粘贴、键盘操作、分组嵌套、对齐参考线这些编辑器级功能。
Toolkit 还内置了拖拽到画布创建节点的交互模板，以及一套自动布局扩展。这意味着如果你从零做一个商业化流程设计器，用 Toolkit 可以省掉至少三到四个月的交互开发量。代价是它需要购买商业授权，而且安装包需要从官方渠道获取，npm 等公共仓库里搜不到合法安装包，这一点在选型时要先确认预算和采购流程。
2.3 一句话决策建议
我自己的判断标准很简单：如果项目就是一个内部工具，或者产品只需要"能拖、能连、能存、能回显"，社区版足够；如果你们要做一个对外销售的通用图编辑产品，并且交互要求很完整，比如框选、撤销、缩略图全都要，那建议直接评估 Toolkit，自己造这些轮子的成本大概率比 license 贵。别一边用社区版一边硬造框选和撤销，造到一半再换 Toolkit，迁移成本会更难受。
3. 把5个核心概念彻底讲明白
3.1 instance、节点与连接线
jsPlumb 的所有操作都围绕一个实例对象展开。你可以用jsPlumb.getInstance()创建独立实例，也可以直接用全局的jsPlumb对象。大部分真实项目都建议用getInstance()创建独立实例，避免跟页面里其他组件冲突，也方便销毁。
节点是普通的 DOM 元素，比如一个<div>。jsPlumb 不做节点的渲染，它只负责在节点上挂端点、画连接线、监听位置变化。连接线是一个独立的对象，默认用 SVG 渲染，线的起点和终点分别绑定到两个端点上。这里要注意：连接线关联的是端点，不是节点DOM本身，节点只是端点所在位置的坐标参考。
3.2 endpoint、anchor、source/target的关系
这几者太容易搞混了。可以拿网线来类比：节点是一台电脑，endpoint 是电脑上的网口，anchor 是网口在机箱上的位置，source 和 target 表示这个网口是出线端还是进线端。同一个 endpoint 可以既是 source 又是 target，相当于一个网口既能接外网也能接内网。
- endpoint：挂载在节点上，作为连线的端点。类型有圆点、方块、空白等。
- anchor：定义连线末端贴到节点的哪个坐标位置。可以写死为
"Left"、"Right"、"Top"、"Bottom"，也可以用数组坐标，比如[0.5, 0.5]表示水平垂直都居中。如果希望连线自动寻找节点边缘最近的位置，就用动态锚点。 - source/target：在
addEndpoint的参数里，isSource为true表示这个端点能拉出线，target为true表示这个端点能接收线。
理解 anchor 是理解 jsPlumb 的关键。之前有个同学问我，为什么连线不是从节点中心出来的，而是从边缘出来的——因为他把 anchor 写成了字符串"Center"，这倒也行，但视觉上节点中心伸出一条线会很丑。常规做法是 source 端锚点在右边，target 端锚点在左边，这样节点从左到右的流向很清晰。
3.3 overlay、connector与Group
overlay 是附着在连线或端点上的一些小元素，常见的有箭头、标签、删除按钮。比如在连线中间放一个叉号按钮，双击或点击就能删线，这个在数据回显的场景里特别实用。connector 决定连接线的外观样式，默认是贝塞尔曲线，也有流程图风格的折线、直线等。Group 是 Toolkit 里更上层的概念，可以把一组节点折叠成一个组，社区版没有内置，但如果你只是简单分组，可以自己用父子 DOM 模拟。
4. 完整实例：搭一个可拖拽的服务编排画布
4.1 初始化实例和容器
下面这段代码是完整的可运行骨架，基于社区版 2.x/5.x 的 API 风格编写。首先要有一个画布容器，节点的直接父容器必须定位明确，否则 jsPlumb 找不到坐标基准。我建议给画布容器设置position: relative，然后通过Container参数告诉实例，连接线应该渲染到这个容器下，而不是默认的body，否则画布一旦滚动，线就会跟节点错位。
<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8" /> <title>jsPlumb 服务编排画布示例</title> <style> #canvas-wrap { position: relative; width: 100%; height: 600px; border: 1px solid #d0d0d0; overflow: auto; background: #f8f9fa; } .flow-node { position: absolute; width: 140px; padding: 10px; background: #fff; border: 1px solid #98c1ff; border-radius: 6px; box-shadow: 0 2px 6px rgba(0, 0, 0, 0.08); cursor: move; text-align: center; z-index: 1; } .flow-node .node-label { font-size: 14px; color: #333; } .node-delete { position: absolute; top: -8px; right: -8px; width: 20px; height: 20px; border-radius: 50%; background: #f56c6c; color: #fff; line-height: 20px; text-align: center; font-size: 12px; cursor: pointer; display: none; } .flow-node:hover .node-delete { display: block; } </style> </head> <body> <div id="canvas-wrap"> <!-- 动态添加的节点都会放到这里 --> <div id="node-start-1" class="flow-node"> <div class="node-label">开始</div> <div class="node-delete">// 物料区元素的 dragstart document.querySelectorAll('.material-item').forEach(el => { el.setAttribute('draggable', 'true'); el.addEventListener('dragstart', (e) => { e.dataTransfer.setData('text/plain', e.target.dataset.type); }); }); const canvasWrap = document.getElementById('canvas-wrap'); canvasWrap.addEventListener('dragover', (e) => e.preventDefault()); canvasWrap.addEventListener('drop', (e) => { e.preventDefault(); const type = e.dataTransfer.getData('text/plain') || 'default'; const rect = canvasWrap.getBoundingClientRect(); const x = e.clientX - rect.left - 70; const y = e.clientY - rect.top - 20; const id = 'node-' + type + '-' + Date.now(); const node = document.createElement('div'); node.className = 'flow-node'; node.id = id; node.innerHTML = ` <div class="node-label">${type}</div> <div class="node-delete">function addConnDeleteOverlay(conn) { conn.addOverlay([ 'Label', { label: 'x', cssClass: 'conn-delete-btn', location: 0.5, events: { click: () => instance.deleteConnection(conn) } } ]); } instance.bind('connection', (info) => { addConnDeleteOverlay(info.connection); });导出数据时，我会把节点坐标、节点类型、节点 ID 以及全部连线信息一起序列化成 JSON。连线信息从instance.getAllConnections()拿，它返回的每个连接对象都带sourceId和targetId。坐标直接用 DOM 的offsetLeft和offsetTop，注意不要用getBoundingClientRect()，因为后者拿到的是视口坐标，回显时没法直接用。
function exportGraph() { const nodes = []; document.querySelectorAll('#canvas-wrap .flow-node').forEach(node => { nodes.push({ id: node.id, type: node.querySelector('.node-label').textContent, left: node.offsetLeft, top: node.offsetTop }); }); const connections = instance.getAllConnections().map(conn => ({ sourceId: conn.sourceId, targetId: conn.targetId })); return JSON.stringify({ nodes, connections }, null, 2); }4.4 JSON回显与状态还原
回显比导出更容易出错。我的做法是，先把原来的画布清理干净，再重建节点 DOM，全部建完后一起连线。这里要加一个isRestoring标志位，因为在回显过程中创建的连接也会触发connection事件，如果不做隔离，事件处理里可能会重复叠加 overlay 或者把回显数据又记录一次，导致回显后数据翻倍。
let isRestoring = false; function loadGraph(jsonStr) { const data = JSON.parse(jsonStr); isRestoring = true; instance.reset(); // 清掉所有端点和连线 canvasWrap.querySelectorAll('.flow-node').forEach(el => el.remove()); data.nodes.forEach(node => { const el = document.createElement('div'); el.className = 'flow-node'; el.id = node.id; el.innerHTML = ` <div class="node-label">${node.type}</div> <div class="node-delete">function deleteNode(nodeEl) { const id = nodeEl.id; instance.getAllConnections().forEach(conn => { if (conn.sourceId === id || conn.targetId === id) { instance.deleteConnection(conn); } }); instance.removeAllEndpoints(nodeEl); nodeEl.remove(); }注意不能用instance.detachAllConnections(nodeEl)直接替代上面的遍历，因为 detach 是摘除端点上的连接，但如果你后续还要复用节点 DOM，detach 后端点还挂在上面，逻辑容易混乱。我的习惯是删除节点就彻底清理。
5.4 坑四：回显时连线重复或消失
回显后发现原本一条线变成了两条，或者第二次打开时线全没了。先说重复问题，这几乎都是回显过程中connection事件被触发，而你在事件里做了"记录/添加 overlay"操作，又没有isRestoring隔离，导致回显的线被重复处理。解决办法就是上面代码里的标志位。
至于线消失，最常见的原因是回显时先连线后建节点，或者connect传入了 undefined 的 source/target。jsPlumb 的connect要求 source 和 target 元素已经注册了端点，如果你在节点 DOM 尚未加入画布时就连线，肯定会失败。所以回显顺序永远是：先建节点、再连节点、最后做渲染收尾。
5.5 坑五：节点多了之后明显卡顿
我压测过大概 200 个节点、400 条连线时，拖节点的流畅度就会下降。因为每一次拖动，jsPlumb 都要重算相关连线的路径，DOM 上的 SVG 节点也会实时更新。优化思路是减少不必要的重绘。添加节点时用一个setSuspendDrawing批处理，避免每个节点触发一次全量重绘。
instance.setSuspendDrawing(true); // 批量添加节点、批量连线 instance.setSuspendDrawing(false); instance.repaintEverything();这个 API 在批量导入、清空重绘、回显场景下尤其有用。另外，如果只是展示型图谱、不允许编辑，建议用instance.draggable禁用，或者直接评估换成 canvas 渲染方案，硬上 DOM 会在 1000+ 节点时明显吃力。
个人体会
jsPlumb 社区版是一套非常务实的技术选型。它不像自研连线引擎那样炫技，但把复杂方案拆成 endpoint、anchor、connection 这些小概念之后，套到业务里很快就能出活儿。我通常会在项目初期就约定好节点 id 的生成规则、连接线的语义方向（source 右进 target 左出）、以及 JSON 数据的格式，这些约定比任何代码优化都更能减少后续返工。如果后续你们需要自动布局，可以接 dagre 算法把节点坐标算好再喂给 jsPlumb；如果产品规模变大，也有 jsPlumb Toolkit 作为更完整的图编辑底座可以迁移。总之，先把上面这套实例跑通，大部分连线场景都不会太难。
本文还有配套的精品资源，点击获取