手把手实现原生Drag and Drop交互与常见问题解决方案

项目初期的技术选型

去年接了个内部工具项目，要搞一个「可视化流程编排器」——拖拽节点、连线、配置参数，最后导出 JSON 发给后端。UI 框架用的是 Vue 3 + Pinia，UI 库是自研的一套组件（没上 Ant Design 或 Element Plus，怕重、怕定制难）。一开始我真没想自己写 drag and drop，琢磨着直接上 vue-draggable-next 或 interact.js，省事。

结果试了两天，全卡在「连线交互」上：拖拽节点时，连线要实时吸附、预览连接点、松手后触发逻辑……这些库要么得大改源码，要么和我们的画布缩放、平移（transform: scale + translate）冲突严重。最后我一拍大腿：算了，原生 dragstart/dragover 搞起。不是炫技，是真没法绕。

最大的坑：性能问题

你以为拖拽就是绑几个事件？错。我们画布支持 100+ 节点，缩放 0.5~2.0，还带网格吸附。刚写完第一版，鼠标一拖，帧率直接掉到 15fps。Chrome DevTools 里一看，dragover 每秒触发 60+ 次，每次都在做：遍历所有连接点、计算距离、判断是否吸附、更新预览线坐标……全是同步操作。

最搞笑的是，用户只是轻轻滑动鼠标，dragover 就疯狂触发，但真正需要“精确吸附”的其实就那么几个关键位置。我折腾了半天才发现：浏览器对 dragover 的节流机制极其不可靠，尤其在高 DPI 屏或 macOS 触控板上，根本拦不住高频调用。

后来砍掉了所有“每帧都算”的逻辑，改成只在 dragmove（自定义的 throttle 化事件）里做核心计算，再配合 requestIdleCallback 做低优先级渲染更新。效果立竿见影——帧率稳在 55+，但代价是吸附响应有约 80ms 延迟。权衡之后，团队说“可接受”，毕竟没人会拿毫秒级精度去连流程图。

又踩坑了：touchmove 滚动失效

上线前测试移动端，发现 iOS Safari 上一拖节点，整个页面就跟着上下滚动……因为默认的 touchmove 行为没被阻止。我加了 event.preventDefault()，结果画布不能拖动平移了 —— 我们的画布平移是靠 touchmove 实现的。

最终方案是：只在节点处于“拖拽态”（即已触发 touchstart 并进入拖拽逻辑）时才 preventDefault，且必须加 { passive: false }。代码长这样：

let isDraggingNode = false;

nodeElement.addEventListener('touchstart', (e) => {
  if (e.touches.length === 1) {
    isDraggingNode = true;
  }
});

nodeElement.addEventListener('touchmove', (e) => {
  if (isDraggingNode) {
    e.preventDefault(); // 必须加，否则 iOS 滚动抢事件
  }
}, { passive: false });

// 松手清状态
nodeElement.addEventListener('touchend', () => {
  isDraggingNode = false;
});

这里注意我踩过好几次坑：passive: false 必须显式声明，不然 Safari 会忽略 preventDefault；另外，不能全局监听 touchmove，否则会影响画布平移，得精准控制作用域。

核心代码就这几行

不整虚的，下面是我们最终稳定跑在线上的拖拽主逻辑（简化版，去掉了状态管理部分）：

// 节点元素上绑定
nodeElement.draggable = true;

nodeElement.addEventListener('dragstart', (e) => {
  e.dataTransfer.setData('text/plain', node.id);
  e.dataTransfer.effectAllowed = 'move';
  // 记录初始位置，用于后续计算偏移
  const rect = nodeElement.getBoundingClientRect();
  e.dataTransfer.setDragImage(new Image(), 0, 0); // 隐藏原生拖拽影子
  // 存到全局状态，方便 dragover 时读取
  draggingNode = { id: node.id, offsetX: e.clientX - rect.left, offsetY: e.clientY - rect.top };
});

// 画布容器上监听
canvasElement.addEventListener('dragover', (e) => {
  e.preventDefault(); // 必须！否则 drop 不触发
  e.dataTransfer.dropEffect = 'move';
});

canvasElement.addEventListener('drop', (e) => {
  e.preventDefault();
  const nodeId = e.dataTransfer.getData('text/plain');
  const x = e.clientX - canvasRect.left - draggingNode.offsetX;
  const y = e.clientY - canvasRect.top - draggingNode.offsetY;
  
  // 这里 dispatch 到 store，更新节点 position
  updateNodePosition(nodeId, { x, y });
  draggingNode = null;
});

重点来了：千万别信 e.clientX / e.clientY 是绝对坐标就完事。我们画布做了 transform: scale(1.5) translate(100px, 50px)，所以真实坐标得手动反算。我一开始直接用了 clientX，结果节点狂飞，调试了三小时才想起来查 transform matrix……

回顾与反思

现在回头看，这套方案优点很实在：轻量（没引入任何第三方 drag 库）、可控（所有行为自己掌控）、和现有缩放/平移逻辑兼容性好。缺点也很明显：没做键盘辅助（比如按住 Shift 拖拽复制），无障碍支持基本为零，Drop 区域的 hover 效果在密集节点下偶发错位（查了好久，发现是 CSS pointer-events: none 在某些嵌套场景下失效，暂时用 z-index 强制覆盖，没根治）。

还有个现实问题：IE11 兼容？不做了。团队明确支持 Chrome/Firefox/Safari 最新两版 + iOS 15+，IE 用户反馈过一次，我回了句“请换浏览器”，然后他真换了 😅

如果你也在做类似可视化编排，我的建议是：别一上来就啃 d3-force 或 jointjs，先用原生 API 把核心交互跑通。很多“看似复杂”的需求，其实只是 event loop 里的几行计算。真正的难点从来不在 drag 和 drop 这两个单词，而在你如何让它和你的业务逻辑、动画系统、缩放逻辑和平共处。

以上是我踩坑后的总结，希望对你有帮助。这个技巧的拓展用法还有很多（比如多选拖拽、跨画布拖拽、拖拽中实时校验权限），后续会继续分享这类博客。有更优的实现方式欢迎评论区交流。